gcassie

I've been working on this with Seb and it's crazy how many bugs we flushed out. He didn't mention in the article but we were also super inspired by the Tigerbeetle team's writing on deterministic simulation testing.

I'd really like my cursor to kind of glow but my graphics programming skills are not at that level yet.

For editing, a block has more potential than a vertical bar because you always have context of a selected character to perform operations on (e.g. `x` to delete current char in vim). You can also do operations before and after that character (e.g. `i` vs `a` in vim).

I actually used this pattern as well and I really like it. I store another property called `mark_idx`. When `cursor_idx` and `mark_idx` are the same then it's just a cursor. When they differ, the range between them is the selection.

Implicit in this article is the idea that security posturing is a zero-sum game for many companies on the dimensions of both software complexity and time.

Adding full disk encryption takes time from other projects and makes the system more complex. That equation needs to pay out. In all likelihood, the reason your data is going to get stolen is a privilege escalation in your app code or a bad actor on your team. Rogue AWS employee swiping your particular hard drive in us-east-1 is way down the list. Full disk encryption does nothing for the first two vectors.

I think compliance programs are oriented around pushing companies into complex/expensive system designs thinking that is a proxy for a secure system.

Yeah there are a lot of definitions out there that are along these lines and they do hollow out my argument.

But why call it "Don't Repeat Yourself" if it actually means something somewhat more subtle than that. I firmly believe many junior developers don't grasp the nuance and based on the comments I'm not the only one who thinks this. So if DRY is widely understood by developers to mean literally "don't repeat yourself" and nothing more, does it really matter how the formal definition phrases it?

In any event, if SPOT / SST and DRY do mean the exact same thing, I like SPOT / SST better because the names encode the essential concepts of the principle.

I can relate to this. I think Casey Muratori coined the maxim "write usable code first". I often mutter that to myself when I'm trying to design some crazy system rather than just solving the problem at hand.

I have to agree with you there - I'm just a random guy who wrote a blog post.

Thanks - I fixed this mistake. I originally was "solving" the problem by checking if the arg passed was a list of lists or a list of strings but I thought I'd get flamed even more for being a terrible developer with that solution.

When you go read proper definitions of DRY they have lots of nuance that speak to many of my criticisms. But the reality is most developers are not encoding that nuance and using it as a fairly blunt instrument. I can't really prove it but at least some people in the comments seem to agree. So I guess I could say "DRY is misunderstood" - but if it's so easily misunderstood then maybe that's a shortcoming in and of itself?

Thanks for having my back. #3 is an overwhelming real world phenomenon. In fact, I posted my article on reddit and someone wrote back a comment with a huge OOP solution that would mitigate all my problems. Not sure that reader got to point #3.

100% agree and I just wrote this response and then saw you said it better!

That's fair. But maybe someone wants to reuse this in another place so they do this:

``` def make_string_filename(s, style="new"): # 2 lines of shared magic if style == "old" # 2 lines of original magic elif style == "new": # different 2 lines of magic ```

When you get here, two totally separate `make_string_filenames()`, each private to the area of code they're relevant to, would be better.

Thanks - I like this point. I think it's probably a better illustration of what I'm trying to say in my third point. Devs are biased towards adapting existing shared code so we end up with shared libraries picking up little implementation details from each of their consumers and ultimately becoming very messy.

Partially agree. I think SPOT (I'd always heard it called single source of truth) is a more universally applicable paradigm than DRY. Having said that, the cost of creating dependency chains is often underestimated. Overly dogmatic adherence to SPOT/SST can lead you to make the wrong tradeoff on coupling two unrelated areas of your codebase to unify some trivial truth.

I'd also say there is a lot of nuance about what "truth" is (i.e. is a pizza crust/sauce/cheese an essential truth that should have a single source).

Some DRY definitions I read actually tie in SST but I think many devs don't bring that nuance to it.

If it works like the OSX subl command, it integrates with git nicely so it can pause git commands to allow you edit commit messages in sublime and resume the command once you save. If you try to do this with standard exe in windows, the git command will run start to finish and you will not be able to edit the commit messages in sublime.