The Rise of Worse Is Better (1991)

Post by ezekiel68 » Mon, Oct 07, 2024, 7:37 PM UTC

AnimalMuppet wrote: post #40

Der_Einzige wrote: post #16

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.

Post by dokyun » Mon, Oct 07, 2024, 7:40 PM UTC

api wrote: 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.

Post by bee_rider » Mon, Oct 07, 2024, 7:42 PM UTC

chuckadams wrote: post #135

rwmj wrote: post #127

Earlier quoted context omitted.

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

> "How do you scare a Bellhead?" he begins. "First, show them something like RealAudio or IPhone. Then tell them that right now performance is bandwidth-limited, but that additional infrastructure is being deployed." You'd scare anyone like an amazed rural tribesman if you showed them an iPhone in 1996. I know, IPhone was a Cisco thing, but my mind went there for a beat ;)

Post by lizknope » Mon, Oct 07, 2024, 7:49 PM UTC

kragen wrote: post #78

pjc50 wrote: post #49

Earlier quoted context omitted.

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?

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.

Post by dokyun » Mon, Oct 07, 2024, 7:52 PM UTC

steveklabnik wrote: post #148

dokyun wrote: post #143

Earlier quoted context omitted.

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

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