<i>>The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed.</i><p>It's a horrible moniker for the concept and most people who use it don't really mean piecemeal growth at all. What they do talk about is usually design where some shortcut allows you to quickly accomplish a short-term goal while completely ignoring long-term consequences. <i>This</i> is the mentality that I see everywhere in the software industry today.<p>Go is mentioned here in comments as an example of "worse is better". It fits nicely. The main "feature" of the language is that it doesn't have any constructs that would require an average college grad or a disgruntled Java shitcoder out there to apply <i>effort</i> in order to understand the feature. Thus, people grab the language and mindlessly run with it. By the time the codebase grows where you need more advanced features, it's too late to switch.<p>My prediction is that in a few years when an average Go codebase switches ownership at least once, it will become widely hated, and language developers will start cramming in features that they originally said aren't needed there at all. You've already seen a preview of thing when they replaced cutesey (and obviously broken) dependency management with modules.
I think it's possible to take the cult of simplicity too far. As is the case with over engineering.<p>There is always the risk of over-simplifying and dumbing down the inherent complexity of problems. Instead of representing the problem space with a good data model, programmers who love to brag about their love of "simplicity" sometimes end up with many extra "simple" layers than are necessary.<p>It's not a binary because there are a lot of factors that go into simplicity and some matter more than others in different contexts. One person's simplicity is another's tedious verbosity. And another's use of specialized programming techniques is someone else's scary learning curve.<p>Much easier to just label My Preferred Solution as The Most Simple and Parsimonious because clearly I am the smartest and most scientific thinker in the group. Other approaches are Too Complex, therefore I don't need to understand them. It's just projection of insecurity about knowledge gaps by hiding under the appearance of being an iconoclast.<p>That said, there are definitely some castle-in-the-sky and nonsense-on-stilts implementations out there :) Some would say ORMs, others would point to the actor model, and others would even say anything higher level than pointers and for-loops. For what purpose though?
> The concept known as "worse is better" holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed.<p>Or in other words, try to avoid Feature Creep[0] or Overengineering[1]<p>[0] <a href="https://en.wikipedia.org/wiki/Feature_creep" rel="nofollow">https://en.wikipedia.org/wiki/Feature_creep</a><p>[1] <a href="https://en.wikipedia.org/wiki/Overengineering" rel="nofollow">https://en.wikipedia.org/wiki/Overengineering</a>
Many newer programming languages have focused on reducing hidden control flow and ugly text macros in favor of more transparent metaprogramming, which may help to illustrate one of the bigger issues with Lisp. Lisp itself is simple and elegant, but that doesn't mean it's easy to write simple and elegant Lisp code. Imperative programming is maybe less elegant and beautiful than functional programming, but imperative programming is easy to understand by humans. Sure, C code may not literally execute line by line, but this is how C programmers mentally model execution, to the point where sometimes people are befuddled to learn it’s not the case. It's such an effective approach that CPUs <i>also</i> provide an as-if illusion of in-order execution. And sure, Lisp macros are powerful, but it feels like nobody ever stopped to consider if maybe there's an upper limit to how powerful you really want a programming language to be. Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Simple, easy to understand, perhaps even "stupid" code <i>works</i>.<p>I could be wrong—perhaps the Lisp renaissance is just around the bend. But realistically, I'm not running into any problems where I wish to deal with more clever and elegant code. In fact, I'm running into problems where I wish to deal with dumber and more obvious code. That these ideals often conflict is probably a great source of debate and strife.
So we're presented with one design philosophy and one design Gabriel admits is a strawman. This was written before steelmanning was common and he was open about it, so the strawman is forgivable.<p>Then again, maybe they're both stickmen of those design approaches. All of the important context is stripped from both. What is the goal of the designed thing? How will it be used? What are the costs?<p>The "better" "MIT/Stanford style" was designing things to be as perfect as possible when considered in a vacuum. The "worse" "NJ style" was intended for use in industry. I still see That jarring difference between the academic and industry approaches today. And I'd rather make a difference in the world with running software, but I can see value in academics, too.
Worse is better is definitely better. I have no doubts about it.<p>Natural organisms seem to follow that pattern - Pauling showed the cells produce sub-optimum concentrations of substances by genetic machinery probably because keeping it at optimum takes up more resources to maintain cellular machinery. Sounds totally like worse is better to me. Life is full of examples .
Why is there never much discussion about the actual technical issue presented in the text, which is how to design a syscall API with respect to interrupt handling?<p>I never thought of the EINTR errno as a hack. It strikes me as very pragmatic and actually the right choice. Am I missing something? Why would one want to save the state of the system call routine when an interrupt occurs and the interrupt handler is executed in user code?<p>The point of interrupts is precisely that they can interrupt a call that otherwise could potentially block forever. When an interrupt occurs, the user code has the chance to completely cancel any attempts to complete the original call. Otherwise, just re-try. The complexity added to the syscall API is small, the practical benefit is very real.<p>So why would I want a general mechanism in the kernel that automatically continues the blocking call after running the interrupt handler?<p>To me the lesson from "Worse is Better" has always been "Don't design before you actually know what you need. You'll probably end up with something that does not do what you want and that you can't fix".
The notion that a minimal first version is the ideal starting point is mirrored in this quote from John Gall:<p>> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
Worse is better and excellence are not at odds. Worse is better applies at one side of a shearing layer, and excellence on the other.<p>In software, a worse is better API imposes designing for modularity upon the applications that depend on you. An excellent implementation means your internals are clean and efficient.
Read the original [0] Lisp: the good news, the bad news, and how to win big. (Spoiler: they didn’t.)<p>[0] <a href="https://www.dreamsongs.com/WIB.html" rel="nofollow">https://www.dreamsongs.com/WIB.html</a>