Live data from Hacker News

The Rise of Worse Is Better (1991)

dreamsongs.com

321–330 of 351 posts

Re: The Rise of Worse Is Better (1991)

#321
post #192

Earlier quoted context omitted.

QuickLisp solves most of the issues. Quiop and closer-mop if you want a universal CLOS. Scheme is not Common Lisp, it's kinda the opposite. It comes with batteries included and MCClim is the defacto GUI for it. >Stuck with Emacs [from the URL] Well, Lem tries to be Emacs for Common Lisp, but without having to think on two Lisp languages (albeit closely related) at once. Once you have a REPL, autocomplete and some doc…

Good point. I neglected to consider standard libraries (stdlib) at the time. If those are allowed, then a lot more can be done with one's code without reaching much farther. Thank-you.

The 'stdlib' in CL is huge.

Scheme is the minimal one. Almost like comparing sh with zsh.

Re: The Rise of Worse Is Better (1991)

#322
post #267

Earlier quoted context omitted.

Yes, but the book also has enough inaccuracies as to make it... I don't know what. For example, in the first chapter the author says "no one knows what a session is," which is patently false. I myself implemented control logic in telco equipment to respond to X.225 compliant messages to change the state of an abstract state machine used on either side of the connection. And while I'm sure it's possible to use CONS or…

I think he means to be saying that, in the context of TCP/IP, nobody knows what a “session” in the OSI sense would correspond to—not that nobody has ever implemented X.225. Presumably Graham knows that people have written X.225 implementations and isn't trying to convince his readers otherwise? I don't know enough to judge his assertion that the session layer exists to solve problems created by half-duplex terminals.…

From page 11: "OSI was designed primarily around the dumb terminal connected to a mainframe."

Also from page 11: "'session' meant something related to attaching videotex terminals to mainframes."

And yes, all Ceefax terminals were Videotex terminals, but not all Videotex terminals were Ceefax terminals.

I might recommend that instead of guessing what the session layer is, you (or more appropriately, Mr. Graham) go and look at what the specs say it is and what it's used for. The X.225 spec is available for download at https://www.itu.int/rec/T-REC-X.225-199511-I/en. X.215 is available at https://www.itu.int/rec/T-REC-X.215-199511-I/en.

The OSI session layer is not related to HTTP session cookies as the original author proposes.

Re: The Rise of Worse Is Better (1991)

#323

Earlier quoted context omitted.

Because it's a distraction. Global warming and other environmental crises are unfolding right now. While exploring possible future technological advances which would make coping with it easier is certainly a positive and useful pursuit - it cannot be the _main_ pursuit when facing those crises and challenges. That is: 1. We should not divert the discussion from present to possible fortuitous futures. 2. We must not c…

There are plenty of examples of technological advances that in one fell swoop entirely eliminate a class of societal problems. Haber-Bosch, for example, completely eliminated famine as a barrier to world populations growth. Penicillin and vaccines eliminated entire categories of terminal disease. We don’t NEED to reduce emissions. So long as we clean up as much or more than we pollute, what’s the problem?

Those are poor, poor examples; but before examining them - I can simply refer you to my previous comment. You are doing exactly the three things I caution against: Attempting to divert the discussion, confusing prospective futures with reality, and reinforcing a supposed dichotomy.

As for the examples:

* For every example of a technological advance that eliminated a class of societal problems, there are five examples of advances which didn't, and untold examples of advances which just never happened (or never happened the way they were expected to). Where is our transmutation of led to gold? Airships? Or Dennard scaling for that matter? No use writing efficient software, our computers will just get faster and it'll be fine.

> Haber-Bosch, for example, completely eliminated famine as a barrier to world populations growth.

And we (= humans) now have to work hard, and suffer through all sorts of problems, to establish barriers to population growth, and to cope with the resource use pressure of the huge population on the Earth.

Not to mention -

* Famines are alive as well.

* Massive energy requirement; and once the population is up - you can't just give this agriculture-industrial choice and let people starve.

* More industrialized economies able to produce a lot more than less-industrialized/poorer economies and areas, exacerbating all sorts of power dynamics, e.g. agricultural "dumping" and mass destitution of peasants who become unable to compete, without a transition having been planned.

* Some detrimental environmental effects.

That's not to say this process shouldn't be used - it's just that it's not a panacea.

> Penicillin and vaccines eliminated entire categories of terminal disease.

They did not. They reduced the fatality rates significantly, for a long period of time - which, apparently, may be drawing to an end over the next few decades:

https://www.wired.com/story/antibiotics-resistance-useless-p...

but even if that doesn't quite happen - antibiotics have absolutely _not_ :

* Reduced the need to Keep medical environments clean, carefully sterilize tools, wear gloves and "scrubs" etc. when treating patients.

* Made it uninteresting or unimportant to avoid mass infections - even those amenable to treatment with Penicillin or vaccines

* Reduce interest or prevalence of other forms of treatment of germs and viruses which are amenable to Penicillin or vaccines.

Re: The Rise of Worse Is Better (1991)

#324

Earlier quoted context omitted.

There are plenty of examples of technological advances that in one fell swoop entirely eliminate a class of societal problems. Haber-Bosch, for example, completely eliminated famine as a barrier to world populations growth. Penicillin and vaccines eliminated entire categories of terminal disease. We don’t NEED to reduce emissions. So long as we clean up as much or more than we pollute, what’s the problem?

Those are poor, poor examples; but before examining them - I can simply refer you to my previous comment. You are doing exactly the three things I caution against: Attempting to divert the discussion, confusing prospective futures with reality, and reinforcing a supposed dichotomy. As for the examples: * For every example of a technological advance that eliminated a class of societal problems, there are five examples…

You want there to be fewer people? Why?

I don’t think I can continue this conversation in good faith. I hope someday you can see the intrinsic evil of the world view in which more people = bad.

Re: The Rise of Worse Is Better (1991)

#325

Earlier quoted context omitted.

Haber-Bosch predates the world wars.

But was only usefull with free trade guarantees by a sea empire. In colonial empire times it might aswell have been alchemy to make free cheese on the moon.

I am confused. Haber-Bosch was developed to work around the need for free trade guarantees. There was enough nitrates in Chile for the foreseeable future in 1911, but Germany wanted a local source of fertilizer to remove their foreign dependency.

Re: The Rise of Worse Is Better (1991)

#327
post #128

Earlier quoted context omitted.

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

Maybe not in any position to do anything about it, but I'm quite sad :-/

I was gonna say, I do shed a tear now and then dreaming of Lisp machines and the future that could have been.

Re: The Rise of Worse Is Better (1991)

#328
post #288

I have a theory that the worse is better approach begets an environment where the worse is better approach is better. At least hypothetically, I think there's an approach which is not "the right thing" or "worse is better" but rather more like "the right foundations". Most interface complexity in my experience seems to be inherited from underlying interface complexity, and it takes a lot of work to fix that underlyin…

I have a question for this premise. How would you design a network interface using your right foundations model? I'm not talking about HTML or whatnot. I have some sort of medium, copper, fiber whatever and I would like to send 10 bytes to the other side of it. What is the right foundations that would lead to an implementation which isn't overly complex.

Telegraph/morse code would probably work fine.

For this application I might also consider classic serial/RS-232 (c. 1969), which can be implemented with one signal wire (tx) and can connect to modern USB.

I'm not entirely sure whether they qualify as "right foundation" but they've worked well in practice.

Re: The Rise of Worse Is Better (1991)

#329
post #319

I have a theory that the worse is better approach begets an environment where the worse is better approach is better. At least hypothetically, I think there's an approach which is not "the right thing" or "worse is better" but rather more like "the right foundations". Most interface complexity in my experience seems to be inherited from underlying interface complexity, and it takes a lot of work to fix that underlyin…

> the worse is better approach is better. I think this ties back to the idea of "get it working, then once it's working go back and make it fast | preformant | better for whatever meaning of better". I think much of the consternation towards "worse is better" comes from re-inventing things to achieve the "make it better" improvements from scratch instead of leveraging existing knowledge. Re-inventing might be fine, b…

That may be one failure mode, but another one is more prominent: Half-assing the next feature is more interesting than going back and making the last feature that you half-implemented actually work. That goes for both commercial and open-source software.

Re: The Rise of Worse Is Better (1991)

#330
post #78

Earlier quoted context omitted.

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.

Wow, you're not kidding about book-length: at 246 pages, that's an epic takedown. Learning all kinds of other things about networking along the way, though. I do remember all nine layers of the OSI stack though: physical, data link, network, transport, session, presentation, application, financial, political.

But we freakin have those layers now. Above TCP/IP there is SSL, and then about that https, and within that there's some JSON RPC or whatever.

The first few OSI layers are fairly readily identifiable in TCP, IP and Ethernet, and some of the rest are built by applications.

Post reply on HN