I agree. I once attempted this on a javascript project (a personal project, not at work), after reading about APL/J/K people and their philosophy. My constraint was: I should never have to scroll. I also aimed to have as few files as possible.
The result was surprisingly pleasant, and it changed how I feel about this sort of thing. I think the Clean Code approach makes a lot of sense when you are working on a big project that contains lots of code that other people wrote, and you rely on IDE features like jumping to definition, etc. But if you can write code that fits on one screen without scrolling, something special happens. It's like all the negative aspects of terse code suddenly vanish and you get something way simpler and overall easier to work with and understand. But you really have to work to get it to that point. A middle ground (terse code but still spread out over lots of files, lots of scrolling) would be the worst of both worlds.
"john ousterhout's book is the only book on how to write software that has any actual evidence behind it."
This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example.
There are lots of other architecture/design books that use real world systems as examples. "Evidence" is definitely lacking in our field, but you can find it if you try.
> People have been building complex software for over sixty years, but until recently, only a handful of researchers had studied how it was actually done. Many people had opinions—often very strong ones—but most of these were based on personal anecdotes or the kind of "it's obvious" reasoning that led Aristotle to conclude that heavy objects fall faster than light ones.
in the 2024 retrospective:
> Conclusion
> The comedian W.C. Fields once said, “If at first you
don’t succeed, try, try again. Then quit. There’s no
point in being a damn fool about it.” Thirteen years
after our first post, it is clear that our attempts to
bridge the gulf between research and practice haven’t
worked. We look forward to hearing what actionable
plans others have that will find real support from both
communities.
I'm not aware of any RCT showing long-term improvement of Alzheimer's symptoms from any treatment. I am aware of 1) long-term slowing of worsening (not improvement) from anti-amyloid therapy, 2) short-term benefits but no change in long-term trajectory from other therapies, and 3) sensational claims without an RCT behind them.
I see that kind of thing all the time. Usually it is about static types. People think that dynamic languages aren't "serious", or something. It is laughable that these people still make up a significant amount of comments, here in 2024.
There's something about it where it doesn't feel quite right when using the mouse as a GUI app. Compare it to something like Sublime Text. I can't quite describe it exactly. It just feels off. It feels like you are supposed to use the keyboard shortcuts to navigate around, and the mouse is sort of bolted on secondarily or something. So I would try to make it feel more like a modern GUI app, where using the mouse feels right.
It's a valid concern. But I just want to point out that shelling out to other things is part of the "paradigm" when using a shell-like language. If you embrace this paradigm, you will better understand the style.
Think of it like learning functional programming. You have to "embrace the paradigm" instead of just mutating things all the time like you might be used to in an imperative language.
