Live data from Hacker News

The Rise of Worse Is Better (1991)

dreamsongs.com

181–190 of 351 posts

Re: The Rise of Worse Is Better (1991)

#181

Earlier quoted context omitted.

I think Toyota would have gotten your point across better. Tesla is most certainly not expedient. It is a luxury purchase.

It's definitely in a class above Toyota, but once you account for gas savings, the LR RWD costs about as much as the cheapest Corolla you can buy. People bagged on Tesla being too expensive when their $35K car was only available over the phone. Now, adjusted for inflation, the LR RWD is $28K and comes with 100mi additional range to boot. On top of that, it's $13K below the average car purchase price. IMO, it destroys…

“In a class above Toyota” in what sense? Certainly not in reliability or interior quality or CarPlay compatibility…

Re: The Rise of Worse Is Better (1991)

#182

Earlier quoted context omitted.

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

Javascript is the only language which straddled the Client Server Gap. If it weren't for Node, Javascript would not have been as popular.

It's still absolutely baffling to me that anyone is willing to run JS server side. There are so many options which are much better suited, why are people willing to jam that square peg into the round hole?

Re: The Rise of Worse Is Better (1991)

#183

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…

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

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

Re: The Rise of Worse Is Better (1991)

#184
post #160
post #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…

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

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)

Re: The Rise of Worse Is Better (1991)

#185

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.

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

Re: The Rise of Worse Is Better (1991)

#186
post #85

Earlier quoted context omitted.

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

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

The technical solution is the only practical solution. People aren't gonna give up a large percentage of their lifestyle for the sake of some greater 'good', especially not if their leaders and influencers seem to have zero interest in doing the same.

And anyone trying otherwise will struggle significantly at the polls. Mass carbon removal, renewable energy, recycling and maybe some technological solutions to limit the effects of atmospheric carbon seem like the more practical way to go.

Re: The Rise of Worse Is Better (1991)

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

Re: The Rise of Worse Is Better (1991)

#188

Earlier quoted context omitted.

Javascript is the only language which straddled the Client Server Gap. If it weren't for Node, Javascript would not have been as popular.

It's still absolutely baffling to me that anyone is willing to run JS server side. There are so many options which are much better suited, why are people willing to jam that square peg into the round hole?

Because they don't know and don't want to know anything else. Not a single polyglot developer I personally know have ever chosen JS for server side, not once.

Re: The Rise of Worse Is Better (1991)

#189
post #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…

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)

Re: The Rise of Worse Is Better (1991)

#190

Earlier quoted context omitted.

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

Why not? Really, why not? If we had a profitable way to extract CO2 from the atmosphere at scale, to deacidify the oceans, clean up toxic waste, etc., what would be left? How would that not solve the problem?

No technology has been invented that doesn't have costs and tradeoffs. Technology that deacidifies the oceans will have other costs, other externalities that we cannot predict now. Determining how we want to deal with those costs/tradeoffs is a social problem, not a technical problem. Technical know-how can only inform us about the what tradeoffs are available, it can't tell us what we prefer.
Post reply on HN