Live data from Hacker News

The Rise of Worse Is Better (1991)

dreamsongs.com

41–50 of 351 posts

Re: The Rise of Worse Is Better (1991)

#41

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.

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.

Re: The Rise of Worse Is Better (1991)

#42
post #37

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.

> 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 –…

> 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).

Re: The Rise of Worse Is Better (1991)

#43
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

Re: The Rise of Worse Is Better (1991)

#44

Earlier quoted context omitted.

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

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 o…

I'll go further. Even if users' requirements and your goals don't change, you don't adequately understand them. You don't know what your users need perfectly. It's better to fire rapidly and adjust your aim than it is to try to have your first attempt be perfect. (Yes, people take this too far the other way...)

Get something out there and start getting feedback. You won't actually know until you do.

Re: The Rise of Worse Is Better (1991)

#45
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.

Re: The Rise of Worse Is Better (1991)

#46

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.

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.

Re: The Rise of Worse Is Better (1991)

#47

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.

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…

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

Re: The Rise of Worse Is Better (1991)

#48

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.

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

Re: The Rise of Worse Is Better (1991)

#49

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"

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?

Re: The Rise of Worse Is Better (1991)

#50
post #13

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.

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.

Post reply on HN