Yeah, the author of the article sounds like a teenager/young adult who seems unable to evaluate objects along multiple dimensions.
2,803 karma · joined March 11, 2010
In general, I'm really enjoying the rise of high-quality packages that work with Emacs rather than providing their own thing. For instance I switched from Ivy to Vertico and it's nice that there's nothing to configure: any time Emacs prompts for input, Vertico is there. With Ivy, I had to do a few configurations to enable Ivy completion everywhere.
Quoting and bolding. I think this is the thing that I need to change most about my own style of programming.
A common approach to programming is to model the problem, almost to anthropomorphize the components of a system. In this style of programming, the organization of data structures isn't about how to lay out bytes in memory, but about a role needed in the resolution of a problem. I almost think of it as having a bunch of little actors that we want to arrange in a certain way in a scene, shout `.action()`, and have the work be done.
This is a style of programming that I was really into just a few years ago, but when I compared myself to other programmers that I really looked up too, I realized that they didn't engage in this type of programming theater. Their code _did_ have types, but it was to group data together, not to tell a story; it was very concrete and practical. And time and time again they produced better programs than I did, often in less time than me, and they avoided questions that would plague me for days (e.g., whose responsibility is it to do X?)
So what I understood from the article is to avoid creating types upon types upon types to model the conceptual problem, and rather write code (which certainly includes data structures) that handles the data of the problem.
FYI, as a non-native English speaker, I have no idea what a "garden path sentence" means.
Short version: good writing is not about rules, it's about the function of the text, the readers, and what they value.
The number one piece of advice: your writing can be clear and structured, but if it's not valuable it's useless and people will stop reading. If you want to write well, figure out who your readers are, figure out what they value, and give it to them.
It's also a problematic quote, because it gives people the impression that they can just ignore that there's an actual computer running their code.
Go and Rust are two languages whose compilers produce statically-linked executables and they are growing in popularity, so you should expect to see more and more of these kinds of programs. And as these programs become more spread, I expect that other languages (either existing or new) will make it easier for developers to distribute their projects as single files.
The compiler is a tool, you can set the field to help it do its job, but it's no magic wand, it cannot think and understand your application: only you can do that.
This is part of the argument of the article, that although nothing forces you to, there is a culture that strongly suggests a way of doing things.
> Performance is a feature
The software world is full of examples of programs that were dislodged by a faster competitor. Back in the hey-days of bittorrent, µtorrent quickly became the most popular client; git quickly established itself as the most dominant VCS in part thanks to its greater performance on common operations (git branch, git log, git commit) than the competition at the time; ack, silversurfer and ripgrep are the grepping tools of choice nowadays; Chrome's speed compared to Firefox and Internet Explorer made it explode in popularity and it's now the de facto standard for anything web-related.
> Performance changes how users use software
This one is really important. An example, from the list above, is git: with Subversion, I would rarely do branches, because that required a complete copy which could take minutes. Git takes less than a millisecond to create a new branch, and now everybody has switched to a model where any new code is written in a branch to be reviewed and merged when ready.
The tools ripgrep and fd-find (replacements for grep(1) and find(1)) are fast enough that I don't organize my directories very diligently. I put my PDFs in ~/Documents, my code in ~/Code, etc. and I use those tools to find the content I need without having to use a fine-grained directory structure.
> There’s a general observation here: attempts to add performance to a slow system often add complexity, in the form of complex caching, distributed systems, or additional bookkeeping for fine-grained incremental recomputation. These features add complexity and new classes of bugs, and also add overhead and make straight-line performance even worse, further increasing the problem.
This is something that has been bothering me for a while: if a program is slow, it's rare that we look at whether it's making reasonable use of the machine's resources (NB: not optimal use; reasonable use). Instead, we spin up three more EC2 instances, configure a load balancer, add a bunch of shell scripts to split the data, and hope that the new thing is fast enough. It usually isn't and as the article says, it's more complex and more fragile.
Great point! I've been using Rust for 4–5 years now and putting objects in Vecs and using integers as "pointers" felt a lot like cheating (i.e., "I'm doing the wrong™ thing!"), but every time I tried to "fix" things to use references my code ended up uglier, harder to understand, and sometimes slower.
In time, I've learned that it's perfectly fine way to structure data. And as you point out, it makes it easier to work on a large structure structure itself rather than having to go through its individual components (e.g., you can manipulate all the nodes in a graph with a simple for loop rather than having to do a DFS/BFS traversal).
Code telling a story is a fallacy that programmers keep telling themselves and which fails to die. Code doesn't tell stories, programmers do. Code can't explain why it exists; it can't tell you about the buggy API it relies on and which makes its implementation weird and not straight-forward; it can't say when it's no longer needed.
Good names are important, but it's false that having well-chosen function and arguments names will tell a programmer everything they need to know.
https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...