Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

> Richard Gabriel was trolling readers with the word "worse" for comical effect. His essay is: "simpler with less features" wins in the marketplace of ideas more than "complex". His observation isn't about "quality".

I have to say that reading the thing again I don't really think that's accurate, since he also talks about sacrificing correctness for the sake of ease of implementation.



>I don't really think that's accurate, since he also talks about sacrificing correctness

RG's use of "correct" doesn't mean that it's ok for a program to return "2+2=5" which is "better" than "2+2=4".

To refer back to the original essay[1], RG's use of words like "correct" and the "Right Thing" requires careful reading because he's deliberately abusing those terms to burnish the opposing side's philosophy. He's playing with the adjectives "worse/correct/right" to present both sides of the New Jersey vs MIT philosophy.

RG says that MIT approach of "backing out of the system routine" is the "correct" way for argument's purposes. It doesn't mean it's The Universally True Correct Way. RG doesn't state it explicitly but the The New Jersey approach of adding user code to test for a failure is also "correct". There are 2 competing semantics of "correct". His observation is that the one with the simpler implementation will spread.

Maybe another analogous example would be clearer. Suppose a C++ programmer would label the "~destructors()" as the "correct" approach to clean up code. No extra user code has to be written to do housekeeping after each object goes out of scope.

However, a C programmer disagrees and "destructors/constructors" are complicated with "spooky action at a distance". They'd rather write explicit wrapper functions called "cleanup()".

Both the C and C++ camps are disagreeing about which "correctness" is better. In this case, RG would award the "correct" label to the C++ philosophy for the sake of a creating a provocative essay.

(It's not an exact analogy because the more complicated C++ programming has survived along side the simpler C for decades.)

Whether one prefers MIT over New Jersey, it doesn't change the fact that RG is not saying that "low quality is better than high quality".

[1] https://www.dreamsongs.com/RiseOfWorseIsBetter.html


> RG's use of "correct" doesn't mean that it's ok for a program to return "2+2=5" which is "better" than "2+2=4".

But it means it's ok to occasionally return Null, instead of of a guaranteed 4.


I doubt even the most "get it out the door" shop in the world would want code that flubs the arithmetic, so I'm having a hard time seeing the distinction you want to argue for.


>I doubt even the most "get it out the door" shop in the world would want code that flubs the arithmetic,

You're interpreting my example literally instead of just seeing it as one example of "correctness" that is a binary TRUE or FALSE. My point is that RG is not writing about "correctness" in that binary sense.

>, so I'm having a hard time seeing the distinction"

The NJ approach of writing user code to check for an error is also correct. It's just a different approach to "correctness."

If you only see "correctness" in binary terms instead of competing abstraction levels of simplicity-vs-complexity, then yes, you will not see RG's distinction.


Let me get straight to the point I mean to make -- what is it that Facebook has done that is literally "incorrect" in the same way flawed math is?


>what is it that Facebook has done that is literally "incorrect"

I don't understand where the confusion in conversation happened. If I'm trying to dismiss literal "correctness" as a binary interpretation, why would I think it applies to Facebook?

To make it more explicit: I don't think OP (paganel) link from RG's "worse is better" to Facebook is relevant. He interpreted RG incorrectly or he misremembered what that essay was actually about since it's been 12 years.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: