The Rise of Worse Is Better (1991)

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

by t14n • 2 years ago

265 334 2 years ago

dreamsongs.com

Dansvidania• 2 years ago

looking at how it played out with javascript one can't but agree.

(edit: I mean it unironically)

TacticalCoder• 2 years ago

Yup first thing I thought. That pathetic piece of crap conceived in basically 15 days (not kidding)... BUT it is what we have on the front-end for web apps so there's that. JavaScript is the mediocre turd I love to hate.

karel-3d3• 2 years ago

And it keeps being polished and improved to the point it's almost not a turd, and now has types sort of, and much better engines, and now there are ARM machines that are literally designed to run it faster, and now most of your actual PC applications are written in it.

But honestly it's kind of refreshing to see the original node.js presentation, where using javascript is sort of a side-note. He wanted to use callback-heavy language and JS fit the bill

https://youtu.be/EeYvFl7li9E

Johanx64• 2 years ago

Problem with Javascript is that it is not confined to webbrowsers and webapps, but it and it's associated business models (SaaS) finds it's way everywhere, at first desktop apps got enshitified by it, then all sorts of smart devices, and all the way to embedded systems in cars with their laggy sloppy UIs everywhere.

It probably is the most severe case of "worse is better" I've experienced so far.

api4• 2 years ago

JavaScript really illustrates the ultimate path-dependence of evolution. It got widely deployed during a boom time and therefore we are stuck with it forever.

Der_Einzige2• 2 years ago

But I feel like other languages that we were de-facto "stuck with" in certain domains boomed and then busted - i.e. Lua, Pearl, etc

GiorgioG2• 2 years ago

We don’t have to be stuck with it forever. Start pushing WASM instead of React, etc. We can get there, but as technologists we have to make a concerted effort to do so.

aredox• 2 years ago

And then we wonder why everything gets worse and worse.

ta988• 2 years ago

what is getting worse and how?

st_goliath• 2 years ago

... everything gets worse and worse ...

    They're coming to take me a away haha
    they're coming to take me a away hoho hihi haha
    to the funny farm where code is beautiful all the time ...

-- Napoleon XIV, more or less...

Via: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

dkasper• 2 years ago

1991 tag. An all time classic.

orwin2• 2 years ago

This... Honestly the first lines seemed I thought this was an arrogant take, but he made _really_ good point and now I tend to agree with him.

Still I am a bit bothered, does a counterargument exist?

gpderetta6• 2 years ago

Empirically, it seems Worse is Better appear to have been correct many many times.

kayo_20211030• 2 years ago

The New Jersey approach has the benefit of dealing with time in a sensible way.

The time to market for the MIT approach is just too long if your revenue relies on actually shipping a product that covers the cost of the next iteration that will move you from 80% to 90%, or even 60% to 70%. It's an old joke, but in the long run we're all dead; and waiting for the production of an ivory tower implementation won't work out well. If it's all academic, and there's no commercial pressure, well, have at it. There's not much at stake except reputations.

Furthermore, in the real world, your users' requirements and your internal goals, theoretically covered by "the" design, will change. Not everything can be reasonably anticipated. The original design is now deficient, and its implementation, which is taking too long anyway, will be a perfect reflection of its deficiency; and, not fit for its new purpose.

ezekiel686• 2 years ago

Yes and it almost serves as more of a coping mechanism (a thought framework that helps us accept what may not seem to be 'the better') than an airtight philosophical position.

ripap• 2 years ago

Worse is Better is Worse: https://www.dreamsongs.com/Files/worse-is-worse.pdf

Same author (name is an anagram).

gpderetta6• 2 years ago

A pseudonym you mean?

jes51993• 2 years ago

the name also seems to be a reference to another pseudonym, https://en.wikipedia.org/wiki/Nicolas_Bourbaki

orwin2• 2 years ago

I wish i could upvote you more than once. This is a very good counterargument.

samatman2• 2 years ago

May as well complete the set: Is Worse Really Better? https://dreamsongs.com/Files/IsWorseReallyBetter.pdf

Also: Nickieben Bourbaki might be an anagram of something, but it is definitely not an anagram of Richard Gabriel, with or without the P. There's no G, there's no h, there's an N and a k, it isn't even particularly close.

That claim is my best interpretation of this sentence:

Same author (name is an anagram).

Although perhaps it was not your intention to connect the clauses in that way.

NAHWheatCracker3• 2 years ago

One counterargument is that people who claim "worse is better" are often making excuses for why their preferred technology didn't win.

Often in these arguments, worse means "shortcut" and better means "won". The difficulty is proving that not taking the shortcut had some other advantages that are assumed, like in the article.

tialaramex• 2 years ago

Winning is temporary. In 1900 Britain has an empire for example. Colonialism won right? The battleship, answering machines, VHS, the compact disk, steam engines.

This "victory" is fleeting. When people people tell you C++, a language which didn't even exist when I was born, is "forever" they are merely betraying the same lack of perspective as when Britain thought its Empire would last forever.

kqr2• 2 years ago

It is going to come down to context. For the most part, you never know quite what it is you are designing, so an iterative approach to design with fast feedback cycles will get you there quicker. Give people something to play with, see how they use it, and continue from there.

But sometimes you need to know what is you are designing before giving it to people, because there are large risks associated with improvising. In those cases, making The Right Thing is still expensive, but it may reduce the risk of catastrophe.

I think, however, that the latter cases are rarer than most people think. There are ways of safely experimenting even in high-risk domains, and I believe doing so ultimately lowers the risk even more than doing The Right Thing from the start. Because even if we think we can spend years nailing the requirements for something down, there are always things we didn't think of but which operational experience can tell us quickly.

Feathercrown• 2 years ago

I think the counterargument is that something being easy to proliferate doesn't mean that it's good.

gpderetta6• 2 years ago

The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

And 30 years later they show few signs of letting go.

ezekiel686• 2 years ago

Yep. And nary a tear is shed these days over the death of the so-called superior Lisp machines.

rwmj2• 2 years ago

Maybe not in any position to do anything about it, but I'm quite sad :-/

gpderetta6• 2 years ago

The Spirit of the Machine still lives in some form in emacs.

OhMeadhbh9• 2 years ago

Meh. Lisp machines still exist. They're just simulated in various Lisp's runtime environments. It turns out that a RISC machine running a Lisp interpreter or an executable compiled from Lisp source tends to perform better than a tagged/cdr Lisp Machine w/ hardware GC.

That being said... I've wanted to implement an old Explorer using an FPGA for a while. Maybe if I just mention it here, someone will get inspired and do it before I can get to it.

Jach4• 2 years ago

At a certain level, sure, but C++ at least has definitely lost out. In the 90s it seemed like it might really take over all sorts of application domains, it was incredibly popular. Now and for probably the last couple decades it and C have only kept around 10% of the global job market.

worstspotgain2• 2 years ago

It's not C++ that has been replaced, it's VB.

OhMeadhbh9• 2 years ago

My gut feeling is there are still the same number of jobs for C++ today as there were in the 90s. It's just that they're hard to find because the total number of programming jobs has exploded. The reason you can't see the C++ jobs is because the newer, non-C++ jobs are crowding them out on job boards. [This is a hypothesis, one I haven't (dis)proven.]

For fun a few weeks ago I went looking for COBOL on VMS jobs. They're definitely still out there, but you do have to look for them. No one's going to send you an email asking if you're interested and if you don't hang out with COBOL/VMS people, you may not know they exist.

I think my point is the total number of C/C++ jobs today are probably the same or slightly higher than 1994. But the total number of Java and C# jobs (or Ruby or Elixr or JavaScript jobs) is dramatically higher than in 1994, if for no other reason than the fact these languages didn't exist in 1994.

[As an aside... if you're looking for a COBOL / VMS programmer/analyst... I spent much of the 80s as a VMS System Manager, coding custom dev tools in Bliss and some of the 90s working on the MicroFocus COBOL compiler for AIX. And while you would be crazy to ignore my 30+ years of POSIX/Unix(tm) experience, I think it would be fun to sling COBOL on VMS.]

pjmlp9• 2 years ago

Depends on the market, even the C++ wannabe replacements are implemented in compiler toolchains written in C++.

It gets a bit hard to replace something that your compiler depends on to exist in first place.

i_s• 2 years ago

I've read this a few times over the years and I think the argument is sound. But I wonder if it is sound in the same way this statement is:

"It is better to go picking blueberries before they are fully ripe, that way you won't have much competition."

NAHWheatCracker3• 2 years ago

I'll never understand the obsession with LISP. My guess is it just appeals to a certain type of person, sort of academic in my view. I'm not convinced that LISP was ever the-right-thing. The author didn't express anything about LISP vs C except to assert that C was a 50% solution and LISP was better.

I agree though that for practical purposes, practical solutions are just going to be more successful.

adamnemecek• 2 years ago

It’s a signaling mechanism to say “I went to MIT” or at the very least to say “I could have gone to MIT”.

djha-skin3• 2 years ago

I learned Racket at Brigham Young University in Utah, and Clojure, then Common Lisp on my own. I don't think it's just an MIT thing. It's in the ethos now. Lots of people know about SICP, for example.

Blackthorn3• 2 years ago

How do you know someone knows lisp? They'll tell you. And tell you. And tell you...

I like lisp for the most part, but holy shit is the enduring dialog surrounding it the absolute worst part of the whole family of languages by far. No, it doesn't have or give you superpowers. Please grow up.

anthk7• 2 years ago

Do either the book on Symbolic Computation + PAIP and/or SICP, and you'll understand.

yoyohello13• 2 years ago

I like LISP, but I wouldn't say I'm an evangelist. Here's my 2 cents for why LISP has such a following.

1. LISP is easy to start with if you're not a programmer. There is very little syntax to get to grips with, and once you understand "everything is a list" it's super easy to expand out from there.

2. LISP really makes it easy to hack your way to a solution. With the REPL and the transparency of "code is data" model you can just start writing code and eventually get to a solution. You don't need to plan, or think about types, or deal with syntax errors. You just write your code and see it executed right there in the REPL.

For my part, I love LISP when it's just me doing the coding, but once you start adding other peoples custom DSL macros or whatever the heck it becomes unwieldy. Basically, I love my LISP and hate other peoples LISP.

turtleyacht2• 2 years ago

Once you get far enough to need external dependencies, do you use your work as a library in another language or rewrite it?

http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

kqr2• 2 years ago

I'm not convinced that LISP was ever the-right-thing.

Remember that this has to be read in historical context. At the time C was invented, things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do (even judged in the harsh light of hindsight), but also quite complicated to implement – so much so that the New Jersey people skipped right past most of it.

Today these things are par for the course. At the time, they were the The Right Thing that made the system correct but complex, and had adoption penalties. As time passes, the bar for The Right Thing shifts, and today, it would probably not be embodied by Lisp, but maybe by something like Haskell or Rust?

pjc504• 2 years ago

things like garbage collection, message-passing object-orientation, generics, rich sets of conditionals, first-class functions, etc. were brand spanking new. They were The Right Thing to do

I quite like this view, because these things have clearly been copied everywhere such as my language of choice C#, but the one thing that nobody copied is the one that Lisp programmers rave about most: homoiconicity (brackets everywhere).

pjmlp9• 2 years ago

Also Lisp came out in 1958, and ESPOL/NEWP in 1961, PL/I and its derivates, predating C by a decade.

Had AT&T been allowed to charge real money for UNIX, and the Worse is Better would never happened.

kragen24• 2 years ago

This paper was written in 01991. Garbage collection is from 01959. Message-passing (aka object-orientation) is from 01972. C is from 01973. If by "generics" you mean parametric polymorphism, those were added to Ada and C++ in the mid-80s, after having been invented in ML in 01973; in a sense they're an attempt to bring the virtues of dynamically-typed languages like Lisp to statically-typed languages. Even today, I don't think there's a Common Lisp implementation with any kind of parametrically-polymorphic static type system, not even as an optimization. First-class functions are also from 01959, or, arguably from 01936, in the untyped λ-calculus, or 01920, in combinatory logic.

Some of these things were brand spanking new in 01973, but none were in 01991.

There were Lisp systems for minicomputers like the PDP-11; BSD included one (which I think was ancestral to Franz Lisp) and XLISP ran on CP/M. And of course Smalltalk was developed almost entirely on PDP-11-sized minicomputers. But to my recollection virtually all "serious" software for microcomputers and minicomputers was written in low-level languages like assembly or C into the late 80s, not even PL/M—though Pascal did start to win in the late 80s, in significant part by adopting C's low-level features. Nowadays, microcomputers are big enough and fast enough that Lisp, Haskell, or even Rust is viable.

I don't think "the right thing" is mostly about what features your system has. I think it has more to do with designing those features to work predictably and compose effectively.

pjc504• 2 years ago

Over the years I've developed what I call the "lefthanded scissors" analogy: people assume that everyone's mind is wired the same way and that all good programmers are good in the same way and think in the same way, but what if that's not true? What if different people have a predisposition (like lefthandedness) to prefer different tools?

Then a righthanded person picks up the lefthanded scissors and deems them weird and uncomfortable. Which they are .. for the right hand of a right-handed person.

Other popular examples of such taste controversy are Python's semantic whitespace, the idioyncracies of Perl, the very unusual shape of J/APL, and anyone using FORTH for non-trivial purposes.

edit: https://news.ycombinator.com/item?id=41766753 comment about "other people's Lisp" reminds me, that working as a solo genius dev on your own from-scratch code and working in a team inside a large organization on legacy code are very different experiences, and the "inflexibility" of some languages can be a benefit to the latter.

arethuza• 2 years ago

I've seen Common Lisp source code that I didn't even recognise as Common Lisp because of over-enthusiastic use of reader macros...

Edit: I should also mention that once I worked out how reader macros worked I went on to enthusiastically (ab)use them for my own ends...

sceptic1232• 2 years ago

I would say the analogy fails because it's not about discomfort or weirdness (or taste); left-handed scissors just don't work if you try to use them right-handed. But right-handed scissors don't work if you try to use them left-handed either.

So it's not about taste or preference, left handed people learn how to use right-handed scissors, but they can also use left handed scissors in a way that a right-handed person would struggle to.

All that said, the analogy still works because most people don't understand why it doesn't work.

kayodelycaon• 2 years ago

What if that's not true?

It is definitely not true. The existence of neurodivergence is proof enough.

I can visualize an entire application in my head like it is a forest. I can fly around and see various parts and how they fit together. I am unable to juggle the tokens necessary to do logic and basic math in my head but I have no trouble reading a graph in understanding the relationships between numbers.

No matter how many times I try to read it, Lisp is completely inscrutable to me. It requires the same token juggling math does.

eikenberry• 2 years ago

I've always preferred to use classical "fine" artists as an metaphor for development language preferences. Artists don't just pick up any medium at a whim, most have specific mediums that they excel in and ignore the others. For example Van Gogh produced his most famous works in oil paints. He had worked in other mediums but his talent definitely seemed to shine when working in oils and when he first found oils he took to them quickly and adopted them as his primary medium.

Most people definitely seem to have specific preferences built into their talents. I don't see why programming or programming languages would be any different from any other medium or art form.

Jach4• 2 years ago

In baseball and other sports, pros and cons of different styles are readily and honestly talked about, even when coaches have a bias. See e.g. https://blog.paddlepalace.com/2014/01/coaching-tip-playing-t... for table tennis. Few comparable articles in programming exist; either people can't conceive of other styles or contexts, or just want to talk about the superiority of their bias regardless of context. If downsides are mentioned at all it's often not about the preferred thing, but some deficiency of something else.

A commonly made up deficiency attributed to Lisp is that it's particularly bad at large scale, either in teams or program size. That would surely be surprising news to the teams doing stuff today or in the past, some responsible for multi-million lines of code systems (some still in operation). Or to use an old example, the documentation for Symbolics Computers, pictured here in book form: https://www.thejach.com/public/symbolics-books-EugyAAEXUAUG_... Such a set of books doesn't come from a "lone wolves only" ecosystem and heritage. Not to mention doc and so on not shown for applications they made for 3D graphics or document editing (https://youtube.com/watch?v=ud0HhzAK30w)

djha-skin3• 2 years ago

In the words of "Programmers Are Also Human" YouTube channel, it's just more comfortable. REPL development, ease of refactoring, dynamic typing, good CFFI, all just adds up to a developer experience that I find to be, in a word, chill.

mattgreenrocks• 2 years ago

Such a weird take on HN. Lisp should be experimented with if only to appreciate the profound beauty of a small, powerful, cohesive design. It is a wholly different feeling from industry standard languages which are constantly changing.

In Lisp, almost all of the language’s power is in “user space.”

The ramifications for that are deep and your beliefs as to whether that is good are largely shaped by whether you believe computation is better handled by large groups of people (thus, languages should restrict users) or smaller groups of people (thus, languages should empower users).

See this for more discussion: https://softwareengineering.stackexchange.com/a/237523

pif• 2 years ago

languages which are constantly changing

They change because they are used.

Blackthorn3• 2 years ago

Nothing about Common Lisp is small or cohesive. Some schemes, maybe.

linguae2• 2 years ago

Keep in mind that this essay was written in the early 1990s. Today there are many programming languages available that offer features that are unavailable in C but have long been available in Lisp. This was not the case in the 1980s during the AI boom of that era. There was a large chasm between classic procedural languages (C, Fortran, Pascal, Simula) and dynamic languages (Smalltalk and Lisp). Prolog was a popular alternative to Lisp in AI circles, especially in Japan back when it was pursuing the Fifth Generation Computing Project. When looking at the language landscape in the 1980s in the context of AI, it makes sense that practitioners would gravitate toward Lisp and Prolog.

Today we benefit from having a variety of languages, each with tradeoffs regarding how their expressiveness matches the problem at hand and also the strength of its ecosystem (e.g., tools, libraries, community resources, etc.). I still think Lisp has advantages, particularly when it comes to its malleability through its syntax, its macro support, and the metaobject protocol.

As a Lisp fan who codes occasionally in Scheme and Common Lisp, I don’t always grab a Lisp when it’s time to code. Sometimes my language choices are predetermined by the ecosystem I’m using or by my team. I also think strongly-typed functional programming languages like Standard ML and Haskell are quite useful in some situations. I think the strength of Lisp is best seen in situations where flexibility and have malleable infrastructure is highly desirable.

kragen24• 2 years ago

The paper was written for an audience of Lisp programmers, so the things you're talking about were sort of out of scope. I'm not going to try to convince you that Lisp and ITS really did aim at "the right thing" in a way that C and Unix didn't; you'll see that it's true if you investigate.

Lisp definitely does depend on personality type. Quoting Steve Yegge's "Notes from the Mystery Machine Bus" (https://gist.github.com/cornchz/3313150):

Software engineering has its own political axis, ranging from conservative to liberal. (...) We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear. (...) Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised.

Lisp, like Perl and Forth, is an extremist "liberal" language, or family of languages. Its value system is centered on making it possible to write programs you couldn't write otherwise, rather than reducing the risk you'll screw it up. It aims at expressiveness and malleability, not safety.

The "right thing" design philosophy is somewhat orthogonal to that, but it also does pervade Lisp (especially Scheme) and, for example, Haskell. As you'd expect, the New Jersey philosophy pervades C, Unix shells, and Golang. Those are also fairly liberal languages, Golang less so. But a C compiler had to fit within the confines of the PDP-11 and produce fast enough code that Ken would be willing to use it for the Unix kernel, and it was being funded as part of a word processing project, so things had to work; debuggability and performance were priorities. (And both C and Unix were guided by bad experiences with Multics and, I infer, M6 and QED.) MACLISP and Interlisp were running on much more generous hardware and expected to produce novel research, not reliable production systems. So they had strong incentives to both be "liberal" and to seek after the "right thing" instead of preferring expediency.

bbor2• 2 years ago

It’s for the dreamers. The crazy ones among us that do not think of themselves as experts in programming machines to solve business problems, but rather novices in cajoling machines to think like humans do.

hcarvalhoalves• 2 years ago

See these demos for the kinds of interactive systems LISP enabled back in the day:

https://www.youtube.com/watch?v=o4-YnLpLgtk

https://www.youtube.com/watch?v=gV5obrYaogU

It makes working on VSCode today look like banging rocks together, let alone 30 years ago.

anthk7• 2 years ago

And today with Lem/Emacs+slime+sbcl

taeric• 2 years ago

LISP remains one of the only languages where manipulating the code looks exactly the same as executing it. This is often illustrated by pointing out that "eval" in lisp doesn't take in a string of characters. (https://taeric.github.io/CodeAsData.html is a blog I wrote on the idea a bit more.)

What this often meant was that getting a feature into your LISP program was something you could do without having to hack at the compiler.

Used to, people balked at how macros and such would break people's ability to step debug code. Which is still largely true, but step debugging is also sadly dead in a lot of other popular languages already.

buescher• 2 years ago

It's not really about lisp or even about vague reverse-snobbish ideas of "practicality" but about very specific categories of design compromises.

Jach4• 2 years ago

It's not a perfectly reliable tell, but people who write LISP instead of Lisp generally give themselves away as knowing nothing about the language. Why not kick the tires with Common Lisp, or even Clojure, and see if you can then understand for yourself why it sparks joy in people? I'm not saying it'll spark joy in you, just that you might understand. (Do you understand Haskell's draw to certain people? Rust's?) At the very least, perhaps you'll lose your notion that it primarily appeals to academic types. Common Lisp is and always has been an industrial language.

"Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." --Kent Pitman

NAHWheatCracker3• 2 years ago

My only personal experience writing with Lisp was Scheme, which I wrote for two weeks back in college 18 years ago, so I truly know nothing about the language.

In retrospect, saying I don't understand was hyperbolic. Of course I understand that people have their preferred languages. The handful of languages I've used in my career each have their draw.

My comment was meant more to question the assertion that Lisp is the-right-thing, which sounds like asserting the-right-religion.

api4• 2 years ago

I feel like we're seeing a bit of push-back today against worse-is-better in the area of languages. Rust in particular feels more like the MIT approach, albeit with an escape hatch via the explicit keyword "unsafe." Its type system is very thoroughly specified and correct as opposed to C's YOLO typing.

djha-skin3• 2 years ago

I actually take this as evidence that Rust will always remain niche. It's just a very complicated language. Go or Zig is much easier to learn and reason about.

In Go you can immediately tell what the fields are in a config yaml file just by looking at struct annotations. Try doing that with Rust's Serde. Super opaque in my opinion.

busterarm3• 2 years ago

Exactly!

Rust will only protect me from things my customers don't care about and don't understand.

By not using Rust and just dealing with it, I'm making more money faster than if I started with Rust.

Rust only matters in environments where that calculus comes out the other way.

busterarm3• 2 years ago

Disagree.

I think this is a self-delusion experienced by Rustaceans because they overvalue a certain type of software correctness and because Rust gets that right, the rest of its warts are invisible.

dokyun3• 2 years ago

Rust is not the MIT approach, because an important aspect of that approach is that it's conceptually simple. Rust is a leviathan of complexity both in interface and implementation. Common Lisp is an MIT approach language, and approaches the same problems like memory and type safety by doing "the right thing" by default and offering more advanced options like type annotations and optimization levels in a "take it or leave it" manner. Rust will force you to program the way the compiler wants in the name of safety, while Common Lisp will allow you to program safely and freely, and decide which parts are important. An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, while Common Lisp compilers are very fast because they do most type-checking at runtime.

steveklabnik3• 2 years ago

An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything,

Rust's typechecking passes are not the reason why the compiler is slow. Code generation dominates compile times. Type checking is pretty quick, and Rust makes some decisions that enable it to do so, like no global inference.

api4• 2 years ago

That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. Maybe it's an attempt at a synthesis of the two -- Unix's gnarly pragmatism but with correctness.

My heart loves the clean sparse MIT approach, but I'm kinda forced to work in the other world because that approach has so far decisively failed.

I have my own thoughts as to why, and they're different from the typical ones:

(1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else.

(2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness.

Der_Einzige2• 2 years ago

I know this is an article about Lisp and the specific usage of this term in the context of software acceptance, but when you use a title that provocative I want to speak specifically about the idea of "Worse is Better" with respect to a more literal idea of "sometimes things get worse overtime but you are told they have improved"

For example, why is it that central vacuums are more rare in 2024 than they were in the 1980s, despite them being superior in every way compared to regular ones?

"Worse" vacuums are "better" for the economy? (because Dyson makes jobs and consumes resources?)

AnimalMuppet5• 2 years ago

Central vacuums are worse in at least one specific way: Cost of fixing or replacing them when they break.

ezekiel686• 2 years ago

True; but my family and neighbors had them and they seemed to last forever. Maybe they were made so well that the company couldn't gain repeat sales often enough.

floren• 2 years ago

Also, I can take my regular vacuum out into the garage and clean the car.

pjc504• 2 years ago

What the heck is a central vaccum? One plumbed into the house? Isn't that spectacularly expensive?

stonemetal122• 2 years ago

A main disadvantage of central vacuums is the higher initial cost. In the United States, the average central vacuum system has an installed cost of around $1,000.

https://en.wikipedia.org/wiki/Central_vacuum_cleaner

Considering the price of a house it isn't "spectacularly expensive". On the other hand vs the price of a hoover yeah a bit. Since it sits in a closet or garage and doesn't move, weight becomes a non issue so it can be a real behemoth of a vacuum.

kragen24• 2 years ago

Yes, one plumbed into the house.

sophacles• 2 years ago

Isn't that spectacularly expensive?

Not spectacularly expensive when installed as the house is built. It's another run of pvc pipe in the walls before you close them up. Approx a day of labor and some pipe are the added expense - not much in terms of house building cost at all. Hardwood floors are much more expensive - and still need to be swept or vacuumed.

bee_rider3• 2 years ago

I don’t get the name New Jersey approach, is it just the general association of New Jersey and poor quality? When I think of New Jersey and CS, I think of Princeton, which has a pretty good program IIRC.

—

Anyway, I wouldn’t put simplicity on the same level as the other things. Simplicity isn’t a virtue in and of itself, simplicity is valuable because it helps all of the other things.

Simplicity helps a bit with consistency, in the sense that you have more trouble doing really bizarre and inconsistent things in a simple design.

Simplicity helps massively with correctness. You can check things that you don’t understand. Personally, that means there’s a complexity prove after which I can’t guarantee correctness. This is the main one I object to. Simplicity and correctness simply don’t belong in different bullet-points.

Simplicity could be seen as providing completeness. The two ways to produce completeness are to either work for a really long time and make something huge, or reduce scope and make a little complete thing.

It’s all simplicity.

dmansen• 2 years ago

New Jersey: https://en.wikipedia.org/wiki/Bell_Labs

bee_rider3• 2 years ago

Oh. Ok, that makes sense.

ezekiel686• 2 years ago

I made the same error when I first read it years ago. It certainly felt like an academic reference.

karel-3d3• 2 years ago

(1991)

shagie• 2 years ago

For another discussion on this https://wiki.c2.com/?WorseIsBetter which starts out with:

    RichardGabriel makes this observation on the survival value of software in the paper Lisp: Good News, Bad News, How to Win Big. See http://www.jwz.org/doc/worse-is-better.html for the section on WorseIsBetter.

    For those seeking the first node, see http://web.archive.org/web/19990210084721/http://www.ai.mit.edu/docs/articles/good-news/good-news.html.

    For even more context on WorseIsBetter see http://www.dreamsongs.com/WorseIsBetter.html. My favorite part is RichardGabriel arguing with himself.

karel-3d3• 2 years ago

I remember when I had a lesson about OSI layers, where the teacher has carefully described all the layers in detail

and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"

pjc504• 2 years ago

Oh, there's an entirely different feature-length article to be written/found about how packet switching beat circuit switching and the "Internet approach" beat the telco approach. The great innovation of being able to deploy devices at the edges without needing clearance from the center.

I don't think very many people even remember X25. The one survivor from all the X standards seems to be X509?

kragen24• 2 years ago

The OSI stack was also designed using the packet-switching approach. Rob Graham's "OSI Deprogrammer" is a book-length article about how TCP/IP beat OSI, and how the OSI model is entirely worthless: https://docs.google.com/document/d/1iL0fYmMmariFoSvLd9U5nPVH...

I'm not sure he's right, but I do think his point of view is important to understand.

fanf23• 2 years ago

LDAP is “lightweight” compared to the X.500 directory access protocol. LDAP DNs are basically the same as X.500 DNs.

SNMP is “simple” compared to X.711 CMIP. But SNMP also uses ASN.1 and X.660 OIDs.

rwmj2• 2 years ago

https://www.wired.com/1996/10/atm-3/ Netheads vs Bellheads

hiatus• 2 years ago

X.25 is still used in ham radio with AX.25

scroot• 2 years ago

This might be fiery take, but I think the X.400 standards for naming and messaging would have been a lot better than the chaotic email situation, and probably would have made more sense from a commercial/legal perspective than making DNS "the" global naming system

PhilipRoman• 2 years ago

IMO the OSI layer system (even though using TCP/IP suite) has some merit in education. To most of us, the concept of layering protocols may seem obvious, but I've talked to people who are just learning this stuff, and they have a lot of trouble understanding it. Emphasizing that each layer is (in theory) cleanly separated and doesn't know about layers above and below, is a very useful step towards understanding abstractions.

ahoka• 2 years ago

The problem is that this is not true. There are no such clean strictly hierarchical layers in most of the protocols that make up the internet.

supportengineer• 2 years ago

I've never done any kernel programming but I assumed the OSI model corresponded to Linux kernel modules or a similar division internally.

jll292• 2 years ago

I enjoyed how we got taught the two models in the 1990s, and why one has the four layers you need and the "standard" has seven layers instead.

The professor asked "How many layers do you count?" - "Seven." - "How many members do you think the ISO/OSI committee had that designed it between them?" - [laughter] - "Seven.".

hammock4• 2 years ago

There was an article posted on here[1] a while back that I only just found again, introducing the term "expedience." The idea was that we think we live in a world where people have to have "the best" sweater, be on "the best" social network, drive "the best" car, etc. But when you look at what really WINS, it's not the best, it's the most "expedient" - i.e. sufficiently good, with built-in social proof, inoculated of buyer's remorse, etc.

Is Amazon "the best" place to go shopping? No, you might find better prices on individual items if you put a little more work into it, but it's the most expedient. Is Facebook/Instagram/Tiktok/insert here "the best" social network? No, but it is the most accessible, easy-to-use, useful one. Is a Tesla (perhaps outdated example since X) "the best" car - no, but it is the most expedient.

There is a tangent here that intersects with refinement culture as well. Among the group of society that (subconsciously) care about these "expedient" choices, you see everyone and everything start to look the same

[1]https://tinaja.computer/2017/10/13/expedience.html

onlyrealcuzzo• 2 years ago

Is a Tesla (perhaps outdated example since X) "the best" car - no, but it is the most expedient.

The most expedient car? Or BEV in the US?

hammock4• 2 years ago

Fair point... it was a coastal California-centric point but there is plenty of nuance or adjustment to be made. At some point in the 90's we'd probably have said "Silver E class Mercedes" is the most expedient luxury sedan, if you wanted a different example.

KerrAvon3• 2 years ago

Neither. Going by the parent poster's gauge, the most "expedient" is probably Lucid; better engineering, better range, and better service.

jprete• 2 years ago

Related - thinking takes a lot of energy, so people prefer options that are cheap to evaluate. This definitely contributes to the preference for expedient options.

AnimalMuppet5• 2 years ago

If you include the cost of gathering information, the expedient solution may in fact be the best.

dkarl3• 2 years ago

"Expedient" is a common (or at least not rare) English word that means something like "practical and effective even if not directly attending to higher or deeper considerations."

For example, if two students in a class are having frequent confrontations that bring learning in the class to a halt, and attempts by teachers and counselors to address their conflict directly haven't been effective, the expedient solution might be to place them in separate classes. The "right thing" would be to address the problem on the social and emotional level, but if continued efforts to do so is likely to result in continued disruption to the students' education, it might be better to separate them. "Expedient" acknowledges the trade-off, while emphasizing the positive outcome.

Often a course of action is described as "expedient" when it seems to dodge an issue of morality or virtue. For example, if we solve climate change with geoengineering instead of by addressing thoughtless consumerism, corporate impunity, and lack of international accountability, many people would feel frustrated or let down by the solution because it would solve the problem without addressing the moral shortcomings that led to the problem. The word expedient stresses the positive side of this, the effectiveness and practicality of the solution, while acknowledging that it leaves other, perhaps deeper issues unaddressed.

circlefavshape• 2 years ago

For example, if we solve climate change with geoengineering instead of by addressing thoughtless consumerism, corporate impunity, and lack of international accountability, many people would feel frustrated or let down by the solution because it would solve the problem without addressing the moral shortcomings that led to the problem.

Oof. Now I understand something I didn't before

hinkley• 2 years ago

See also: war crimes

KerrAvon3• 2 years ago

I think this is misleading -- geoengineering + social change will be necessary. You're not going to Scotty your way out of climate change.

raincole• 2 years ago

if we solve climate change with geoengineering instead of by addressing thoughtless consumerism, corporate impunity, and lack of international accountability, many people would feel frustrated or let down

If some people feel frustrated or let down because we achieve a literal miracle (by today's technology standards) that saves millions of lives I'm willing to call them mentally unhinged.

hnben• 2 years ago

non-native speaker here

"Expedient" is a common (or at least not rare) English word that means something like "practical and effective even if not directly attending to higher or deeper considerations."

I was not aware of the word "Expedient" before. From your example I conclude, that it has the same meaning as "pragmatic", i.e. if I sed i/expedient/pragmatic/g then your comment still makes perfect sense to me. A quick google search also seems to support this conclusion.

--> is there a nuance of the word "expedient", that I am missing here?

lisper• 2 years ago

Is Amazon "the best" place to go shopping? No, you might find better prices on individual items if you put a little more work into it, but it's the most expedient.

It's not just that. Every time you do business with a new web site you assume additional risk. Amazon is a known quantity. You can be pretty sure that they are not going to outright scam you, and they aren't going to be hacked by script kiddies. There is a significant risk of getting a counterfeit item, but they have a very liberal return policy, so the real cost to you in this case is a minute or two to get a return code and possibly a trip to the nearest Whole Foods to drop it off.

Amazon sucks in many ways, but at least their suckage is a known quantity. Predictability has significant value.

katbyte• 2 years ago

Yep it’s the return policy that allowed me to gamble on items that may or may not be real/functional vs spending a ton of time to find one elsewhere that maybe is, but if it’s not it’ll be hard to return

WalterBright3• 2 years ago

you might find better prices on individual items if you put a little more work into it

That extra work costs you money, too. Calculate how much your job pays you per hour, then you can deduce the $cost of spending more time to get a better deal.

contagiousflow• 2 years ago

Are you removing paid working time in doing the extra work? If not it is just an opportunity cost

Gigachad• 2 years ago

This is a fairly crappy methodology though because the vast majority of people are not substituting paid working time with researching buying things online. So it hasn't "cost" them anything other than their free time which is far more complex than an hourly rate. Maybe they enjoy researching products and in that situation, it wasn't a waste of time at all.

d0mine• 2 years ago

There is also "satisficing" (vs. maximizing).

Your model of the world is not perfect so instead of trying to find a globally optimal solution, you are satisfied with a local optimum that exceeds some threshold that has to suffices. https://en.wikipedia.org/wiki/Satisficing

hammock4• 2 years ago

Love that. Well-done marketing* can orient a consumer into a preferred "local optimum territory" , leading to satisfiction(?) and sales

* For example, the limited selection of candy at the checkout aisle. All you have to do is get your brand in there. (Placement on the 4P's)

* Or, "best credit card for travelers." By offering travel rewards, you can acquire a group of cardmembers even if, e.g. a more valuable cashback card could have gotten them even greater benefits (Promotion on the 4P's)

RcouF1uZ4gsC• 2 years ago

Is Amazon "the best" place to go shopping?

The number one reason I use Amazon, is not for the best prices, but because of their return policy. Amazon returns are actually often more painless than physical store returns.

Being able to return something predictably and easily outweighs a small difference in price.

b3ing• 2 years ago

I might argue it’s the one most known by the most people, the “best” takes time to get there, Google was better than yahoo but it took years to become #1 in terms of hits

aulin• 2 years ago

inoculated of buyer's remorse

Non native here. What's the meaning of inoculated here?

It's not the first time that I struggle to parse this word. In italian it keeps the original latin meaning and can be translated with "injected with". You could inoculate a vaccine but you could also inoculate a poison, so it does not carry the immunity meaning by default. English (US?) as far as I can tell use it as a synonym of "immune", is that so?

avidiax• 2 years ago

I think the author means "vaccinated". They mean that they've been made resistant to buyer's remorse.

pmg101• 2 years ago

It should be "inoculated against" but the meaning is clear.

A vaccine inoculates you against a disease by a physical mechanism: that is, it prevents you from getting that disease (to a greater or lesser degree).

Metaphorically being inoculated against something means it can no longer hurt you. For instance, maybe by not owning a car you're inoculated against vehicle depreciation. Or by wearing the same simple but quality outfit every day you're inoculated against the vagaries of fashion.

rpastuszak• 2 years ago

Reminds me of this quote by Bauman: https://untested.sonnet.io/notes/proteus-uncertainty-is-the-...

clarkevans• 2 years ago

I think the worse-is-better philosophy is not well encapsulated with the 4 priorities given. Perhaps it is 4 completely different priorities. Here's a strawman.

1. Minimal -- the design and implementation must be the smallest as possible, especially the scope (which should be deliberately "incomplete")

2. Timely -- the implementation must be delivered as soon as feasible, even if it comes before the design (get it working first, then figure out why)

3. Relevant -- the design and implementation must address important, unmet need, eschewing needs that are not urgent at the time (you can iterate or supplement)

4. Usable -- the implementation must be integrated with the existing, working and stable infrastructure (even if that integration causes design compromises)

The other dimensions, simplicity, correctness, consistency, and completeness are very nice to have, but they are not the primary drivers of this philosophy.

AnimalMuppet5• 2 years ago

That seems like a fairly solid strawman.

I would say that Timely and Relevant drive Minimal. I would also say that Minimal and Usable are in tension with each other.

jes51993• 2 years ago

what's the old saw about "unix design prioritizes simplicity over correctness, and on modern hardware simplicity is also no longer considered necessary"

marcosdumay• 2 years ago

There's a really important detail in that simplicity tends to lead to correctness.

Anyway, worse is better is about simplicity of implementation versus conceptual simplicity. By principle, that's a much harder choice.

mseepgood• 2 years ago

Maybe don't call it "worse", maybe it's just you who has a skewed perception of "good"/"right".

hammock4• 2 years ago

The distinction between the set of five "right" principles and the five "worse is better" principles is known as compromise in design.

It's the opposite of what marketers want you to think of when they say "uncompromising design."

stonemetal122• 2 years ago

Isn't "Worse is better" just a restatement of "Perfect is the enemy of Good", only slanted to make better\Perfect sound more enticing?

The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors.

A deer is only 80% of a unicorn, but waiting for unicorns to exist is folly.

OhMeadhbh9• 2 years ago

Yes and no. "Worse is Better" also implies you allow someone outside your problem domain to define abstractions you use to decompose the problem domain (and construct the solution domain.) So... I mean... that's probably not TOO bad if they're well-understood and well-supported. Until it isn't and you have to waste a lot of time emulating a system that allows you to model abstractions you want/need to use.

But at the end of the day everyone knows never to assume STD I/O will write an entire buffer to disk and YOU need to check for EINTR and C++ allows you to wrap arbitrary code in try...catch blocks so if you're using a poorly designed 3rd party library you can limit the blast radius. And it's common now to disclaim responsibility for damages from using a particular piece of software so there's no reason to spend extra time trying to get the design right (just ship it and when it kills someone you'll know it's time to revisit the bug list. (Looking at YOU, Boeing.))

I do sort of wonder what happens when someone successfully makes the argument that C++ Exceptions are a solution often mis-applied to the problem at hand and someone convinces a judge that Erlang-like supervisory trees constitute the "right" way to do things and using legacy language features is considered "negligence" by the courts. We're a long way off from that and the punch line here is a decent lawyer can nail you on gross negligence even if you convinced your customer to sign a liability waiver (at least in most (all?) of the US.)

Which is to say... I've always thought there is an interplay between the "worse is better" concept and the evolution of tech law in the US. Tort is the water in which we swim; it defines the context for the code we write.

JohnFen• 2 years ago

"Worse is better" has become like "move fast and break things". They're both sayings that reveal an often-overlooked truth, but they have both been taken far too far and result in worse things for everybody.

ezekiel686• 2 years ago

I see what you mean. Yet I feel like the first one (at least, as outlined in the article) is more about accepting an inevitability that you probably have little control over, while the second is more often adopted as a cultural process guideline for things you can control. But that's just my impression.

sesm• 2 years ago

And then it transformed into "move things and break fast".

dang2• 2 years ago

These look to be the interesting threads on Gabriel's worse-is-better essays:

Lisp: Good News, Bad News, How to Win Big (1990) [pdf] - https://news.ycombinator.com/item?id=30045836 - Jan 2022 (32 comments)

Worse Is Better (2001) - https://news.ycombinator.com/item?id=27916370 - July 2021 (43 comments)

Lisp: Good News, Bad News, How to Win Big (1991) - https://news.ycombinator.com/item?id=22585733 - March 2020 (21 comments)

The Rise of Worse Is Better (1991) - https://news.ycombinator.com/item?id=21405780 - Oct 2019 (37 comments)

The Rise of Worse Is Better (1991) - https://news.ycombinator.com/item?id=16716275 - March 2018 (44 comments)

Worse is Better - https://news.ycombinator.com/item?id=16339932 - Feb 2018 (1 comment)

The Rise of Worse is Better - https://news.ycombinator.com/item?id=7202728 - Feb 2014 (21 comments)

The Rise of "Worse is Better" - https://news.ycombinator.com/item?id=2725100 - July 2011 (32 comments)

Lisp: Good News, Bad News, How to Win Big [1991] - https://news.ycombinator.com/item?id=2628170 - June 2011 (2 comments)

Worse is Better - https://news.ycombinator.com/item?id=2019328 - Dec 2010 (3 comments)

Worse Is Better - https://news.ycombinator.com/item?id=1905081 - Nov 2010 (1 comment)

Worse is better - https://news.ycombinator.com/item?id=1265510 - April 2010 (3 comments)

Worse Is Better - https://news.ycombinator.com/item?id=1112379 - Feb 2010 (5 comments)

Lisp: Worse is Better, Originally published in 1991 - https://news.ycombinator.com/item?id=1110539 - Feb 2010 (1 comment)

Lisp: Good News, Bad News, How to Win Big - https://news.ycombinator.com/item?id=552497 - April 2009 (2 comments)

dang2• 2 years ago

... and these are the some of the threads discussing it or aspects of it. Others welcome!

Worse Is Better - https://news.ycombinator.com/item?id=36024819 - May 2023 (1 comment)

My story on “worse is better” (2018) - https://news.ycombinator.com/item?id=31339826 - May 2022 (100 comments)

When Worse Is Better (2011) - https://news.ycombinator.com/item?id=20606065 - Aug 2019 (13 comments)

EINTR and PC Loser-Ing: The “Worse Is Better” Case Study (2011) - https://news.ycombinator.com/item?id=20218924 - June 2019 (72 comments)

Worse is worse - https://news.ycombinator.com/item?id=17491066 - July 2018 (1 comment)

“Worse is Better” philosophy - https://news.ycombinator.com/item?id=17307940 - June 2018 (1 comment)

What “Worse is Better vs. The Right Thing” is really about (2012) - https://news.ycombinator.com/item?id=11097710 - Feb 2016 (35 comments)

The problematic culture of “Worse is Better” - https://news.ycombinator.com/item?id=8449680 - Oct 2014 (116 comments)

"Worse is Better" in the Google Play Store - https://news.ycombinator.com/item?id=6922127 - Dec 2013 (10 comments)

What “Worse is Better vs The Right Thing” is really about - https://news.ycombinator.com/item?id=4372301 - Aug 2012 (46 comments)

Worse is worse - https://news.ycombinator.com/item?id=437966 - Jan 2009 (3 comments)

ezekiel686• 2 years ago

I'm always happy whenever this old article goes viral. For two reasons: First, learning to accept the fact that the better solutions doesn't always win has helped me keep may sanity over more than two decades in the tech industry. And second, I'm old enough to have a pretty good idea what the guy meant when he replied, "It takes a tough man to make a tender chicken."

bbor2• 2 years ago

I’m glad to know a new article that “everyone knows”! Thanks for pointing out the age.

And, at the risk of intentionally missing the metaphor: they do in fact make automated tenderizers, now ;) https://a.co/d/hybzu2U

hyggetrold• 2 years ago

It's a funny expression and it is rooted in advertising: https://en.wikipedia.org/wiki/Frank_Perdue

sebastianconcpt• 2 years ago

To Worse is Better I'd say, careful with what you wish.

agumonkey• 2 years ago

I assume that 'worse' often means find adequation with average and mass. This ensures a longer existence, later you may absorb the "better" you didn't have early on. Look how dynamic languages started to have better data types, various traits (generators, closures..), jit .. all things they could pluck out of old "glorious" languages that were .. somehow too advanced for the mainstream. It's a strange schizophrenic situation.

bccdee7• 2 years ago

Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language.
Unix and C are the ultimate computer viruses.

The key argument behind worse-is-better is that an OS which is easy to implement will dominate the market in an ecosystem with many competing hardware standards. Operating systems, programming languages, and software in general have not worked this way in a long time.

Rust is not worse-is-better, but it's become very popular anyway, because LLVM can cross-compile for anything. Kubernetes is not worse-is-better, but nobody needs to reimplement the k8s control plane. React is not worse-is-better, but it only needs to run on the one web platform, so it's fine.

Worse-is-better only applies to things that require an ecosystem of independent implementers providing compatible front-ends for diverging back-ends, and we've mostly standardized beyond that now.

xiphias2• 2 years ago

There are some differences between your examples in my opinion:

Rust started as an experiment of Mozilla team replacing C++ with something that helps them compete with Chrome in developing safe multi-threaded code more efficiently. It took a lot of experiments to get to the current type system, most of which gives real advantages by using affine types, but the compiler is at this point clearly over-engineered for the desired type system (and there are already ideas on how to improve on it). It's still too late to restart, as it looks like it takes 20 years to productionize something like Rust.

As for React I believe it's I believe an over-engineered architecture from the start for most web programming tasks (and for companies / programmers that don't have separate frontend and backend teams), but the low interest rates + AWS/Vercel pushed them on all newcomers (and most programmers are new programmers, as the number of programmers grew exponentially).

HTMX and Rails 8 are experiments in the opposite direction (moving back to the servers, nobuild, noSAAS), but I believe there's lot of space to further simplify the web programming stack.

psychoslave• 2 years ago

Unix and C are still there, and while on shallow level this can be more or less ignored, all abstractions end up to leak sooner than later.

Could the industry get rid of C and ridiculous esoteric abbreviation in identifiers, it could almost be a sane world to wander.

tightbookkeeper3• 2 years ago

Rust is not very popular in terms of number of users. It’s just over represented in online discussion.

mplewis• 2 years ago

Rust isn’t popular in web dev. It’s very popular in embedded.

bccdee7• 2 years ago

It made it into the Linux kernel, and it's still a relatively young language. I don't think any language has made such a large impact since Java or Javascript, both of which are nearly 30 years old now.

worstspotgain2• 2 years ago

EINTR's design is one of computing's absolute classics. To MIT and New Jersey, we should add the McDougals approach: "I cannot work under these conditions." When faced with the PC loser-ing issue, just don't implement the code in question.

McDougals resolves the apparent conflict between the other two. It blames the interrupt hardware as the root cause. It produces non-working, incomplete software. It's kind of a modest proposal.

However, it also produces no ripples in the design fabric. With MIT, the OS source is a maintenance nightmare. With NJ, modern software still has to deal with archaic idiosyncrasies like EINTR. With McDougals, all the "conflict-free" portions of the software advance, those that write themselves.

The result is likely immediately shelved, perhaps as an open source PoC. Over time, someone might write some inelegant glue that makes interrupts appear to behave nicely. Alternatively, the world might become perfect to match the software.

If nothing else, the software will have mimicked the way we learn. We use imperfect examples to draw the idealized conclusion. Even if it never gets to run, it will be more readable and more inspiring than either MIT or NJ.

th43o2i42342342• 2 years ago

The critical point of the article holds true of everything in human social networks (be it religion/culture/philosophy/apps/industry...).

If you don't achieve virality, you're as good as dead. Once a episteme/meme spreads like wild-fire there's very little chance for a reassessment based on value/function - because the scope is now the big axis of valuation.

It's actually worse because humanity is now a single big borg. Even 30-40 years back, there were sparsely connected pools where different species of fish could exist - not any more. The elites of every single country is a part of the Anglosphere, and their populations mimic them (eventually).

This tumbling towards widespread mono-memetism in every single sphere of life is deeply dissatisfying about the modern human life, not just for PL/OS/... but also for culture etc.

Anthropocene of humanity itself.

esafak• 2 years ago

If you don't achieve virality, you're as good as dead.

Are you? Maybe the worse solution peaks faster, but can be supplanted by a better solution in the future, like how Rust is displacing C/C++ in new projects. The better solution may never be popular yet persist.

th43o2i42342342• 2 years ago

Rust is nowhere near displacing C++.

There's typically a "exhaustion" phase with mono-memetism/theories where everyone gets sick and tired of the "one and only way" and it becomes fashionable to try out new things (eg. Xtianity in Europe). We're not at this point where the olds can be toppled.

pjmlp9• 2 years ago

For Rust to fully displace C++, it needs to eventually bootstrap itself, until then, C++ will be around.

Additionally there are no significant new projects being done in Rust for the games industry, AI/ML, HPC, HFT, compiler backends, hardware design,....

Taniwha• 2 years ago

Of course the opposite is often stated as "Perfect is the enemy of Good"

enugu• 2 years ago

Ironically, the main feature that separates LISP from other modern languages is homoiconicity/macros(now that features like garbage collection are mainstream).

And this leads to an easier implementation - parsing is easier(which is why code transformation via macros becomes easy).

kazinator2• 2 years ago

A language which has that feature tends to get classified as a member of the Lisp family, even if it is horribly "unlispy" under the hood in its semantics.

Arch-TK3• 2 years ago

I have a theory that the worse is better approach begets an environment where the worse is better approach is better.

At least hypothetically, I think there's an approach which is not "the right thing" or "worse is better" but rather more like "the right foundations".

Most interface complexity in my experience seems to be inherited from underlying interface complexity, and it takes a lot of work to fix that underlying interface complexity. This, I think is where "worse is better" shines. If you try to apply a "the right thing" approach to a system where you're dealing with shitty underlying interfaces (i.e. every popular operating system out there including every unix, and NT system) you end up with endless complexity and performance loss. So obviously nobody will want to do "the right thing" and everyone who takes the "worse is better" approach will end up way ahead of you in terms of delivering something. People will be happy (because people are almost always happy regardless of how crap your product is).

On the other hand, designing something with "the right foundations" means that "the right thing" no longer needs to involve "sacrifice implementation simplicity in favour of interface simplicity" to anywhere near the same extent because your implementation can focus on implementing whatever interface you want rather than first paving over a crappy underlying interface.

But the difficulty of "the right foundations" is that nobody knows what the right foundations are the first 10 times they implement them. This approach requires being able to rip the foundations up a few times. And nobody wants that, so "worse is better" wins again.

wismi• 2 years ago

I think there's a lot of truth to this. It reminds me of an idea in economics about the "second-best". From the wikipedia page:

"In welfare economics, the theory of the second best concerns the situation when one or more optimality conditions cannot be satisfied. The economists Richard Lipsey and Kelvin Lancaster showed in 1956 that if one optimality condition in an economic model cannot be satisfied, it is possible that the next-best solution involves changing other variables away from the values that would otherwise be optimal. Politically, the theory implies that if it is infeasible to remove a particular market distortion, introducing one or more additional market distortions in an interdependent market may partially counteract the first, and lead to a more efficient outcome."

https://en.wikipedia.org/wiki/Theory_of_the_second_best

germandiago2• 2 years ago

I hate intervention but I like analysis. Good insights there, I did not know about this theory.

jpc0• 2 years ago

I have a question for this premise.

How would you design a network interface using your right foundations model? I'm not talking about HTML or whatnot.

I have some sort of medium, copper, fiber whatever and I would like to send 10 bytes to the other side of it. What is the right foundations that would lead to an implementation which isn't overly complex.

me_again• 2 years ago

Not a direct answer, but Ethernet is sometimes brought up as a successful example of Worse is Better. At one point Token Ring was a serious competitor - it had careful designs to avoid collisions when the network was busy, prioritize traffic, etc. But it was comparatively slow and expensive. Ethernet just says "eh, retry on collision.". And that simplistic foundation has carried on to where we have a standard for 800 Gigabit Ethernet.

Arch-TK3• 2 years ago

Unfortunately, I am not a network engineer. So I don't know how I would approach this problem other than to try to make sure that the resulting hardware is easy to deal with from firmware and software.

I have worked with hardware directly and there is something inherently simple about some hardware APIs versus others.

What's more, the complexity doesn't entirely relate to the underlying hardware or protocol complexity.

The issue is, though, that reality is complicated. This is where the right foundations are important. It's not necessarily that the right foundations themselves have simple internals, but that the right foundations successfully tame the complexity of reality.

The best place to work on developing the right foundations is therefore precisely at such interfaces between the real world and the software world.

shuntress2• 2 years ago

I have some sort of medium, copper, fiber whatever and I would like to send 10 bytes to the other side of it. What is the right foundations that would lead to an implementation which isn't overly complex.

The bane of every project is understanding what you actually need to do

For example, it is entirely possible that the "right foundation" for your proposed scenario is: Hook one end up to a lightswitch, the other to a light bulb, hire two operators trained in morse code. Then once the 10 bytes are sent write them their cheques and shut it down.

musicale• 2 years ago

Telegraph/morse code would probably work fine.

For this application I might also consider classic serial/RS-232 (c. 1969), which can be implemented with one signal wire (tx) and can connect to modern USB.

I'm not entirely sure whether they qualify as "right foundation" but they've worked well in practice.

tightbookkeeper3• 2 years ago

good comment. But I question how much you can package up inherent complexity in a simple interface, due to leaky abstraction.

The biggest benefit of simplicity in design is when the whole system is simple, so it’s easy to hack on and reason about.

Arch-TK3• 2 years ago

Abstraction leaks are usually a result of a worse is better approach. But yes, as I think I said in my original comment, its very difficult to successfully completely pave over a poor base.

And yes, I agree that simplicity needs to start quite low down the stack (ideally at the hardware, or the firmware, or the drivers, or the kernel as a last resort) for the complexity not to explode as you keep adding layers.

gpderetta6• 2 years ago

But the difficulty of "the right foundations" is that nobody knows what the right foundations are the first 10 times they implement them

Yes and it worse than that. The right foundations might change with time and changing requirements.

kagevf• 2 years ago

the worse is better approach is better.

I think this ties back to the idea of "get it working, then once it's working go back and make it fast | preformant | better for whatever meaning of better".

I think much of the consternation towards "worse is better" comes from re-inventing things to achieve the "make it better" improvements from scratch instead of leveraging existing knowledge. Re-inventing might be fine, but we shouldn't throw away knowledge and establshed techniques if we can avoid it.

zombot• 2 years ago

That may be one failure mode, but another one is more prominent: Half-assing the next feature is more interesting than going back and making the last feature that you half-implemented actually work. That goes for both commercial and open-source software.

pron• 2 years ago

That worse-is-better is self-reinforcing and that it's the only stable strategy in an environment with less-than-perfect cooperation (i.e. it's the only Nash equilibrium) may both be true at the same time. In fact, if the latter is true then the former is alsmost certainly true.

The real question is, then, whether doing "the right thing" is a stable and winning strategy at all, i.e. viable and affordable. As you yourself suspect, the answer may well be no. Not only because it takes a few tries to figure out the right foundations, but also because what foundation is right is likely to change over time as conditions change (e.g. hardware architecture changes, programming practices -- such as the use of AI assistants -- change etc.).

germandiago2• 2 years ago

For me this is just utopia vs real world.

What is better, a perfect design or one that exists?

Our mind tries to trick us into thinking that the choice is between perfect and not so perfect.

No, in real-life it is common that aiming for the perfect ruins everything else, even the existence of that idea in real form due to other constraints.

pulse7• 2 years ago

"worse is better" is "the right thing"

The Rise of Worse Is Better (1991)

Related Stories