71–80 of 351 posts
what's the old saw about "unix design prioritizes simplicity over correctness, and on modern hardware simplicity is also no longer considered necessary"
Anyway, worse is better is about simplicity of implementation versus conceptual simplicity. By principle, that's a much harder choice.
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.
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.
>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.
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 –…
Had AT&T been allowed to charge real money for UNIX, and the Worse is Better would never happened.
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…
Earlier quoted context omitted.
> 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 ev…
Are all homoiconic without being full of parenthesis all over the place, the actual meaning is code and data being interchangeable.
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?
I'm not sure he's right, but I do think his point of view is important to understand.
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.
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.
Earlier quoted context omitted.
> 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 –…
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.
It’s likely that Unix might not had spread if AT&T didn’t give it relatively liberal licensing in the pre-divestiture era. But it’s also likely that something else that was cheap and readily adaptable would’ve taken over instead, even if it wasn’t technically superior to its competitors.