Live data from Hacker News

The Rise of Worse Is Better (1991)

dreamsongs.com

201–210 of 351 posts

Re: The Rise of Worse Is Better (1991)

#201
post #190

Earlier quoted context omitted.

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.

The ion pumps enabled by the technology we are working on won’t have external effects. They basically just filter out certain small molecules from the ocean into crystal storage.

Re: The Rise of Worse Is Better (1991)

#202
EINTR's design is one of computing's absolute classics. To MIT and New Jersey, we should add the McDougals approach: "I cannot work under these conditions." When faced with the PC loser-ing issue, just don't implement the code in question.

McDougals resolves the apparent conflict between the other two. It blames the interrupt hardware as the root cause. It produces non-working, incomplete software. It's kind of a modest proposal.

However, it also produces no ripples in the design fabric. With MIT, the OS source is a maintenance nightmare. With NJ, modern software still has to deal with archaic idiosyncrasies like EINTR. With McDougals, all the "conflict-free" portions of the software advance, those that write themselves.

The result is likely immediately shelved, perhaps as an open source PoC. Over time, someone might write some inelegant glue that makes interrupts appear to behave nicely. Alternatively, the world might become perfect to match the software.

If nothing else, the software will have mimicked the way we learn. We use imperfect examples to draw the idealized conclusion. Even if it never gets to run, it will be more readable and more inspiring than either MIT or NJ.

Re: The Rise of Worse Is Better (1991)

#203
post #194
post #82

Earlier quoted context omitted.

This paper was written in 01991. Garbage collection is from 01959. Message-passing (aka object-orientation) is from 01972. C is from 01973. If by "generics" you mean parametric polymorphism, those were added to Ada and C++ in the mid-80s, after having been invented in ML in 01973; in a sense they're an attempt to bring the virtues of dynamically-typed languages like Lisp to statically-typed languages. Even today, I d…

What do you think of Coalton?

I've never tried it! It does look like it might be the thing I was saying doesn't exist, though :-)

Re: The Rise of Worse Is Better (1991)

#204

> The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. And 30 years later they show few signs of letting go.

Yep. And nary a tear is shed these days over the death of the so-called superior Lisp machines.

Meh. Lisp machines still exist. They're just simulated in various Lisp's runtime environments. It turns out that a RISC machine running a Lisp interpreter or an executable compiled from Lisp source tends to perform better than a tagged/cdr Lisp Machine w/ hardware GC.

That being said... I've wanted to implement an old Explorer using an FPGA for a while. Maybe if I just mention it here, someone will get inspired and do it before I can get to it.

Re: The Rise of Worse Is Better (1991)

#205
post #190

Earlier quoted context omitted.

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.

The ion pumps enabled by the technology we are working on won’t have external effects. They basically just filter out certain small molecules from the ocean into crystal storage.

What kind of flow rate would be necessary to pull CO2 out of the ocean faster than it dissolves from the air, and is that achievable without affecting the surroundings?

Re: The Rise of Worse Is Better (1991)

#206
post #175

> The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. And 30 years later they show few signs of letting go.

At a certain level, sure, but C++ at least has definitely lost out. In the 90s it seemed like it might really take over all sorts of application domains, it was incredibly popular. Now and for probably the last couple decades it and C have only kept around 10% of the global job market.

My gut feeling is there are still the same number of jobs for C++ today as there were in the 90s. It's just that they're hard to find because the total number of programming jobs has exploded. The reason you can't see the C++ jobs is because the newer, non-C++ jobs are crowding them out on job boards. [This is a hypothesis, one I haven't (dis)proven.]

For fun a few weeks ago I went looking for COBOL on VMS jobs. They're definitely still out there, but you do have to look for them. No one's going to send you an email asking if you're interested and if you don't hang out with COBOL/VMS people, you may not know they exist.

I think my point is the total number of C/C++ jobs today are probably the same or slightly higher than 1994. But the total number of Java and C# jobs (or Ruby or Elixr or JavaScript jobs) is dramatically higher than in 1994, if for no other reason than the fact these languages didn't exist in 1994.

[As an aside... if you're looking for a COBOL / VMS programmer/analyst... I spent much of the 80s as a VMS System Manager, coding custom dev tools in Bliss and some of the 90s working on the MicroFocus COBOL compiler for AIX. And while you would be crazy to ignore my 30+ years of POSIX/Unix(tm) experience, I think it would be fun to sling COBOL on VMS.]

Re: The Rise of Worse Is Better (1991)

#207
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…

I might argue it’s the one most known by the most people, the “best” takes time to get there, Google was better than yahoo but it took years to become #1 in terms of hits

Re: The Rise of Worse Is Better (1991)

#208
post #173

Earlier quoted context omitted.

Wow. That is awesome, I skimmed through it and it looks like something I will enjoy. I've still got my Tanenbaum Computer Networks book from 1996 and the first chapter starts with OSI, then TCP/IP, and explains the differences and why OSI failed.

I'm interested to hear what you think! I haven't finished reading it yet. It's a bit repetititive.

It doesn't seem like a "take down" as much as a re-iteration of all the things IBM, DEC, GE and various Telcos did wrong when implementing OSI. I could reduce it to one sentence: "Everyone was so intent on monetizing their own networking implementation they never thought enough about interoperability."

Re: The Rise of Worse Is Better (1991)

#209
post #197
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…

That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic. Maybe it's an attempt at a synthesis of the two -- Unix's gnarly pragmatism but with correctness. My heart loves the clean sparse MIT approach, but I'm kinda forced to work in the other world because…

> That's an interesting counter-take and it makes me wonder if Rust isn't a third thing... not the clean sparse MIT approach but also not the wild YOLO slop of C and Unix. Something correct but also complex and pragmatic.

I had supposed this in a previous thread, and I agree it is another thing entirely, however whether Rust is 'correct' or 'pragmatic', I think is a matter of contention.

> (1) Worse is free -- the "worse" stuff tended to be less encumbered by patents and closed source / copyrights. This is particularly true after GNU, BSD, and Linux. Free stuff is viral. It spreads fast and overtakes everything else.

At the time it seems that the "worse" stuff was actually more encumbered--GNU started to exist as a consequence of Unix both becoming an industry standard and solidifying the position of nonfree software in industry, and it didn't get that way by being free--they simply licensed it away en masse to universities. The free software movement was born out of the MIT hacker ethic of sharing software freely (GNU brought the design philosophy of MIT to Unix systems, and largely stands opposed to the "worse is better" approach. It originally sought to replace parts of Unix with superior alternatives, such as Info over man pages). BSD didn't become free until much, much later, at which point Linux had already become relevant.

> (2) Programmers like to show off, and "worse" provides more opportunities to revel in complexity and cleverness.

I think maybe C or C++ lets you show off by hacking around the compiler to do certain things that look impressive like preprocessor hacks or obfuscated code, but I think many would agree that this kind of style isn't "correct": languages like Go were developed as a consequence of this in order to suck any and all fun you might get out of hacking C, in order to force you to write more "correct" programs. Lisp, on the contrary doesn't tell you what a correct or incorrect program is, and gives you every facility to write programs that are infinitely complex and clever.

To me, Rust looks like the result of trying to break the rules of industry languages, by trying to incorporate things like real macros and type systems into something that resembles a real-world language. But it's biggest flaw to me is that it doesn't break enough of them, rather it makes more in the process.

Re: The Rise of Worse Is Better (1991)

#210
post #174
post #115

Earlier quoted context omitted.

OSI was was two network stacks fighting with each other, the circuit-switched telco X.25 successor and the packet-switched DEC / Xerox anti-Internet. See also https://computer.rip/2021-03-27-the-actual-osi-model.html and https://dotat.at/@/2024-03-26-iso-osi-usw.html

This is great, thanks! crawford's post pulls no punches: > Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle. It's nonsensical to the point of farce. The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain…

That's sort of like saying "TCP" is a failure because everyone now uses SSH instead of TELNET. TCP/IP still has to do all of the things the OSI stack does, it just does it in a different manner and there are (thankfully) plenty of well defined wire-formats and processing expectations so interoperability is pretty straight-forward. But I still think IPSec would have been MUCH easier to deploy had TCP/IP maintained a rational distinction between presentation and session layers. I guess what we learned is that SSL/TLS and FreeSWAN's assumptions about routing encrypted payloads were "good enough."

Also, if you're going to compare TCP/IP to various OSI implementations, you should compare the full stack including PEM, MOSS, SMIME, SSL/TLS, SSH. Each muddies the difference between presentation and application layers, but as in the previous paragraph, no one seems to care. Talking SMTP over SSH (or SSL/TLS) is totally fine; you don't need to have a sub-protocol to define how a presentation layer on top of a secure session layer works if you can make certain assumptions about the behaviour of the code on the other side of the network connection.

Post reply on HN