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 buyer's remorse, etc.
Is Amazon "the best" place to go shopping? No, you might find better prices on individual items if you put a little more work into it, but it's the most expedient. Is Facebook/Instagram/Tiktok/insert here "the best" social network? No, but it is the most accessible, easy-to-use, useful one. Is a Tesla (perhaps outdated example since X) "the best" car - no, but it is the most expedient.
There is a tangent here that intersects with refinement culture as well. Among the group of society that (subconsciously) care about these "expedient" choices, you see everyone and everything start to look the same
"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 might be to place them in separate classes. The "right thing" would be to address the problem on the social and emotional level, but if continued efforts to do so is likely to result in continued disruption to the students' education, it might be better to separate them. "Expedient" acknowledges the trade-off, while emphasizing the positive outcome.
Often a course of action is described as "expedient" when it seems to dodge an issue of morality or virtue. For example, if we solve climate change with geoengineering instead of by addressing thoughtless consumerism, corporate impunity, and lack of international accountability, many people would feel frustrated or let down by the solution because it would solve the problem without addressing the moral shortcomings that led to the problem. The word expedient stresses the positive side of this, the effectiveness and practicality of the solution, while acknowledging that it leaves other, perhaps deeper issues unaddressed.
> For example, if we solve climate change with geoengineering instead of by addressing thoughtless consumerism, corporate impunity, and lack of international accountability, many people would feel frustrated or let down by the solution because it would solve the problem without addressing the moral shortcomings that led to the problem.
Oof. Now I understand something I didn't before
No you don't because there is no 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.
What's misleading here? He was using that as an example of usage of the word 'expedient', not actually suggesting climate change solutions.
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.
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?
why are you fantasizing? none of that is going exist (caveat: unless we figure out infinite clean energy).
It’s not fantasy. I’m working on a startup to enable this technology. It’s a hard problem, but not impossible. And the energy needs are not as great as you think. A relatively small patch of the Sahara or Gobi desert or open ocean would be sufficient.
See also: war crimes
> Is Amazon "the best" place to go shopping? No, you might find better prices on individual items if you put a little more work into it, but it's the most expedient.
It's not just that. Every time you do business with a new web site you assume additional risk. Amazon is a known quantity. You can be pretty sure that they are not going to outright scam you, and they aren't going to be hacked by script kiddies. There is a significant risk of getting a counterfeit item, but they have a very liberal return policy, so the real cost to you in this case is a minute or two to get a return code and possibly a trip to the nearest Whole Foods to drop it off.
Amazon sucks in many ways, but at least their suckage is a known quantity. Predictability has significant value.
Yep it’s the return policy that allowed me to gamble on items that may or may not be real/functional vs spending a ton of time to find one elsewhere that maybe is, but if it’s not it’ll be hard to return
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)
> you might find better prices on individual items if you put a little more work into it
That extra work costs you money, too. Calculate how much your job pays you per hour, then you can deduce the $cost of spending more time to get a better deal.
Are you removing paid working time in doing the extra work? If not it is just an opportunity cost
In my line of work, yes.
Related - thinking takes a lot of energy, so people prefer options that are cheap to evaluate. This definitely contributes to the preference for expedient options.
> Is a Tesla (perhaps outdated example since X) "the best" car - no, but it is the most expedient.
The most expedient car? Or BEV in the US?
Fair point... it was a coastal California-centric point but there is plenty of nuance or adjustment to be made. At some point in the 90's we'd probably have said "Silver E class Mercedes" is the most expedient luxury sedan, if you wanted a different example.
The early to mid 90s E class aka W124 definitely went down in history as one of the best quality and best designed cars ever made. Other luxury cars may be faster, more fun, or have more features… but the W124 probably is “the best” if you’re looking just at build quality and well thought out design details.
As a car nerd though, I never felt the need to buy one because they just seem fairly boring- other than a few rare models most were 4 door sedans with automatics, fairly small engines, and soft non sporty suspension.
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 its competitors in the value market, and the media is being awfully silent about it. I guess it's far too easy to focus on Elon instead.
“In a class above Toyota” in what sense? Certainly not in reliability or interior quality or CarPlay compatibility…
Neither. Going by the parent poster's gauge, the most "expedient" is probably Lucid; better engineering, better range, and better service.
but it's really not what "expedient" means
>Is Amazon "the best" place to go shopping?
The number one reason I use Amazon, is not for the best prices, but because of their return policy. Amazon returns are actually often more painless than physical store returns.
Being able to return something predictably and easily outweighs a small difference in price.
If you include the cost of gathering information, the expedient solution may in fact be the best.
> 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.
I'm always happy whenever this old article goes viral. For two reasons: First, learning to accept the fact that the better solutions doesn't always win has helped me keep may sanity over more than two decades in the tech industry. And second, I'm old enough to have a pretty good idea what the guy meant when he replied, "It takes a tough man to make a tender chicken."
I’m glad to know a new article that “everyone knows”! Thanks for pointing out the age.
And, at the risk of intentionally missing the metaphor: they do in fact make automated tenderizers, now ;) https://a.co/d/hybzu2U
> 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.
Yep. And nary a tear is shed these days over the death of the so-called superior Lisp machines.
The Spirit of the Machine still lives in some form in emacs.
Maybe not in any position to do anything about it, but I'm quite sad :-/
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?
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. 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.
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.
I can't claim to have BTDT, but I did get the T-shirt. That's how I learned them :)
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 significant real-world adoption.
LDAP is “lightweight” compared to the X.500 directory access protocol. LDAP DNs are basically the same as X.500 DNs.
SNMP is “simple” compared to X.711 CMIP. But SNMP also uses ASN.1 and X.660 OIDs.
I finally understand why OSI failed, it's the naming! Dear lord.
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 ;)
Haha, I didn’t get it until your last sentence
X.25 is still used in ham radio with AX.25
IMO the OSI layer system (even though using TCP/IP suite) has some merit in education. To most of us, the concept of layering protocols may seem obvious, but I've talked to people who are just learning this stuff, and they have a lot of trouble understanding it. Emphasizing that each layer is (in theory) cleanly separated and doesn't know about layers above and below, is a very useful step towards understanding abstractions.
I've never done any kernel programming but I assumed the OSI model corresponded to Linux kernel modules or a similar division internally.
Isn't "Worse is better" just a restatement of "Perfect is the enemy of Good", only slanted to make better\Perfect sound more enticing?
>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.
"Worse is better" has become like "move fast and break things". They're both sayings that reveal an often-overlooked truth, but they have both been taken far too far and result in worse things for everybody.
I see what you mean. Yet I feel like the first one (at least, as outlined in the article) is more about accepting an inevitability that you probably have little control over, while the second is more often adopted as a cultural process guideline for things you can control. But that's just my impression.
I've read this a few times over the years and I think the argument is sound. But I wonder if it is sound in the same way this statement is:
"It is better to go picking blueberries before they are fully ripe, that way you won't have much competition."
I assume that 'worse' often means find adequation with average and mass. This ensures a longer existence, later you may absorb the "better" you didn't have early on. Look how dynamic languages started to have better data types, various traits (generators, closures..), jit .. all things they could pluck out of old "glorious" languages that were .. somehow too advanced for the mainstream. It's a strange schizophrenic situation.
I think the worse-is-better philosophy is not well encapsulated with the 4 priorities given. Perhaps it is 4 completely different priorities. Here's a strawman.
1. Minimal -- the design and implementation must be the smallest as possible, especially the scope (which should be deliberately "incomplete")
2. Timely -- the implementation must be delivered as soon as feasible, even if it comes before the design (get it working first, then figure out why)
3. Relevant -- the design and implementation must address important, unmet need, eschewing needs that are not urgent at the time (you can iterate or supplement)
4. Usable -- the implementation must be integrated with the existing, working and stable infrastructure (even if that integration causes design compromises)
The other dimensions, simplicity, correctness, consistency, and completeness are very nice to have, but they are not the primary drivers of this philosophy.
That seems like a fairly solid strawman.
I would say that Timely and Relevant drive Minimal. I would also say that Minimal and Usable are in tension with each other.
Maybe don't call it "worse", maybe it's just you who has a skewed perception of "good"/"right".
For another discussion on this https://wiki.c2.com/?WorseIsBetter which starts out with:
RichardGabriel makes this observation on the survival value of software in the paper Lisp: Good News, Bad News, How to Win Big. See http://www.jwz.org/doc/worse-is-better.html for the section on WorseIsBetter.
For those seeking the first node, see http://web.archive.org/web/19990210084721/http://www.ai.mit.edu/docs/articles/good-news/good-news.html.
For even more context on WorseIsBetter see http://www.dreamsongs.com/WorseIsBetter.html. My favorite part is RichardGabriel arguing with himself.The distinction between the set of five "right" principles and the five "worse is better" principles is known as compromise in design.
It's the opposite of what marketers want you to think of when they say "uncompromising design."
These look to be the interesting threads on Gabriel's worse-is-better essays:
Lisp: Good News, Bad News, How to Win Big (1990) [pdf] - https://news.ycombinator.com/item?id=30045836 - Jan 2022 (32 comments)
Worse Is Better (2001) - https://news.ycombinator.com/item?id=27916370 - July 2021 (43 comments)
Lisp: Good News, Bad News, How to Win Big (1991) - https://news.ycombinator.com/item?id=22585733 - March 2020 (21 comments)
The Rise of Worse Is Better (1991) - https://news.ycombinator.com/item?id=21405780 - Oct 2019 (37 comments)
The Rise of Worse Is Better (1991) - https://news.ycombinator.com/item?id=16716275 - March 2018 (44 comments)
Worse is Better - https://news.ycombinator.com/item?id=16339932 - Feb 2018 (1 comment)
The Rise of Worse is Better - https://news.ycombinator.com/item?id=7202728 - Feb 2014 (21 comments)
The Rise of "Worse is Better" - https://news.ycombinator.com/item?id=2725100 - July 2011 (32 comments)
Lisp: Good News, Bad News, How to Win Big [1991] - https://news.ycombinator.com/item?id=2628170 - June 2011 (2 comments)
Worse is Better - https://news.ycombinator.com/item?id=2019328 - Dec 2010 (3 comments)
Worse Is Better - https://news.ycombinator.com/item?id=1905081 - Nov 2010 (1 comment)
Worse is better - https://news.ycombinator.com/item?id=1265510 - April 2010 (3 comments)
Worse Is Better - https://news.ycombinator.com/item?id=1112379 - Feb 2010 (5 comments)
Lisp: Worse is Better, Originally published in 1991 - https://news.ycombinator.com/item?id=1110539 - Feb 2010 (1 comment)
Lisp: Good News, Bad News, How to Win Big - https://news.ycombinator.com/item?id=552497 - April 2009 (2 comments)
... and these are the some of the threads discussing it or aspects of it. Others welcome!
Worse Is Better - https://news.ycombinator.com/item?id=36024819 - May 2023 (1 comment)
My story on “worse is better” (2018) - https://news.ycombinator.com/item?id=31339826 - May 2022 (100 comments)
When Worse Is Better (2011) - https://news.ycombinator.com/item?id=20606065 - Aug 2019 (13 comments)
EINTR and PC Loser-Ing: The “Worse Is Better” Case Study (2011) - https://news.ycombinator.com/item?id=20218924 - June 2019 (72 comments)
Worse is worse - https://news.ycombinator.com/item?id=17491066 - July 2018 (1 comment)
“Worse is Better” philosophy - https://news.ycombinator.com/item?id=17307940 - June 2018 (1 comment)
What “Worse is Better vs. The Right Thing” is really about (2012) - https://news.ycombinator.com/item?id=11097710 - Feb 2016 (35 comments)
The problematic culture of “Worse is Better” - https://news.ycombinator.com/item?id=8449680 - Oct 2014 (116 comments)
"Worse is Better" in the Google Play Store - https://news.ycombinator.com/item?id=6922127 - Dec 2013 (10 comments)
What “Worse is Better vs The Right Thing” is really about - https://news.ycombinator.com/item?id=4372301 - Aug 2012 (46 comments)
Worse is worse - https://news.ycombinator.com/item?id=437966 - Jan 2009 (3 comments)
what's the old saw about "unix design prioritizes simplicity over correctness, and on modern hardware simplicity is also no longer considered necessary"
There's a really important detail in that simplicity tends to lead to correctness.
Anyway, worse is better is about simplicity of implementation versus conceptual simplicity. By principle, that's a much harder choice.
To Worse is Better I'd say, careful with what you wish.
looking at how it played out with javascript one can't but agree.
(edit: I mean it unironically)
JavaScript really illustrates the ultimate path-dependence of evolution. It got widely deployed during a boom time and therefore we are stuck with it forever.
We don’t have to be stuck with it forever. Start pushing WASM instead of React, etc. We can get there, but as technologists we have to make a concerted effort to do so.
We will still be stuck with it forever for compatibility reasons
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?
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.
There was something long ago called GWT -- Google Web Toolkit -- that tried to make Java into that language by having it compile to JavaScript.
It actually worked decently well, but was due to Java needlessly verbose.
WASM lets us run other languages efficiently in the browser but that just opens the field to a lot of languages, not one language to rule them all.
Yup first thing I thought. That pathetic piece of crap conceived in basically 15 days (not kidding)... BUT it is what we have on the front-end for web apps so there's that. JavaScript is the mediocre turd I love to hate.
And it keeps being polished and improved to the point it's almost not a turd, and now has types sort of, and much better engines, and now there are ARM machines that are literally designed to run it faster, and now most of your actual PC applications are written in it.
But honestly it's kind of refreshing to see the original node.js presentation, where using javascript is sort of a side-note. He wanted to use callback-heavy language and JS fit the bill
It will always be a turd. Typescript is a nice illusion, but underneath is still the same turd.
To me WASM is the wildcard. It lets other languages infect the Javascript host organism.
This... Honestly the first lines seemed I thought this was an arrogant take, but he made _really_ good point and now I tend to agree with him.
Still I am a bit bothered, does a counterargument exist?
Worse is Better is Worse: https://www.dreamsongs.com/Files/worse-is-worse.pdf
Same author (name is an anagram).
the name also seems to be a reference to another pseudonym, https://en.wikipedia.org/wiki/Nicolas_Bourbaki
I wish i could upvote you more than once. This is a very good counterargument.
May as well complete the set: Is Worse Really Better? https://dreamsongs.com/Files/IsWorseReallyBetter.pdf
Also: Nickieben Bourbaki might be an anagram of something, but it is definitely not an anagram of Richard Gabriel, with or without the P. There's no G, there's no h, there's an N and a k, it isn't even particularly close.
That claim is my best interpretation of this sentence:
> Same author (name is an anagram).
Although perhaps it was not your intention to connect the clauses in that way.
A pseudonym you mean?
both!
An anagram. Same letters, different order.
I might be dense today, but how's Nickieben Bourbaki an anagram of Richard P. Gabriel?
It is going to come down to context. For the most part, you never know quite what it is you are designing, so an iterative approach to design with fast feedback cycles will get you there quicker. Give people something to play with, see how they use it, and continue from there.
But sometimes you need to know what is you are designing before giving it to people, because there are large risks associated with improvising. In those cases, making The Right Thing is still expensive, but it may reduce the risk of catastrophe.
I think, however, that the latter cases are rarer than most people think. There are ways of safely experimenting even in high-risk domains, and I believe doing so ultimately lowers the risk even more than doing The Right Thing from the start. Because even if we think we can spend years nailing the requirements for something down, there are always things we didn't think of but which operational experience can tell us quickly.
Empirically, it seems Worse is Better appear to have been correct many many times.
The New Jersey approach has the benefit of dealing with time in a sensible way.
The time to market for the MIT approach is just too long if your revenue relies on actually shipping a product that covers the cost of the next iteration that will move you from 80% to 90%, or even 60% to 70%. It's an old joke, but in the long run we're all dead; and waiting for the production of an ivory tower implementation won't work out well. If it's all academic, and there's no commercial pressure, well, have at it. There's not much at stake except reputations.
Furthermore, in the real world, your users' requirements and your internal goals, theoretically covered by "the" design, will change. Not everything can be reasonably anticipated. The original design is now deficient, and its implementation, which is taking too long anyway, will be a perfect reflection of its deficiency; and, not fit for its new purpose.
I'll go further. Even if users' requirements and your goals don't change, you don't adequately understand them. You don't know what your users need perfectly. It's better to fire rapidly and adjust your aim than it is to try to have your first attempt be perfect. (Yes, people take this too far the other way...)
Get something out there and start getting feedback. You won't actually know until you do.
Yes and it almost serves as more of a coping mechanism (a thought framework that helps us accept what may not seem to be 'the better') than an airtight philosophical position.
One counterargument is that people who claim "worse is better" are often making excuses for why their preferred technology didn't win.
Often in these arguments, worse means "shortcut" and better means "won". The difficulty is proving that not taking the shortcut had some other advantages that are assumed, like in the article.
Winning is temporary. In 1900 Britain has an empire for example. Colonialism won right? The battleship, answering machines, VHS, the compact disk, steam engines.
This "victory" is fleeting. When people people tell you C++, a language which didn't even exist when I was born, is "forever" they are merely betraying the same lack of perspective as when Britain thought its Empire would last forever.
I think the counterargument is that something being easy to proliferate doesn't mean that it's good.
I don’t get the name New Jersey approach, is it just the general association of New Jersey and poor quality? When I think of New Jersey and CS, I think of Princeton, which has a pretty good program IIRC.
—
Anyway, I wouldn’t put simplicity on the same level as the other things. Simplicity isn’t a virtue in and of itself, simplicity is valuable because it helps all of the other things.
Simplicity helps a bit with consistency, in the sense that you have more trouble doing really bizarre and inconsistent things in a simple design.
Simplicity helps massively with correctness. You can check things that you don’t understand. Personally, that means there’s a complexity prove after which I can’t guarantee correctness. This is the main one I object to. Simplicity and correctness simply don’t belong in different bullet-points.
Simplicity could be seen as providing completeness. The two ways to produce completeness are to either work for a really long time and make something huge, or reduce scope and make a little complete thing.
It’s all simplicity.
New Jersey: https://en.wikipedia.org/wiki/Bell_Labs
Oh. Ok, that makes sense.
I made the same error when I first read it years ago. It certainly felt like an academic reference.
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.
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 leave it" manner. Rust will force you to program the way the compiler wants in the name of safety, while Common Lisp will allow you to program safely and freely, and decide which parts are important. An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, while Common Lisp compilers are very fast because they do most type-checking at runtime.
> 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.
....so why is it so slow to generate code?
The compiler doesn't do a whole lot to try and minimize LLVM-IR, and monomorphization produces quite a lot of it. This makes LLVM do a lot of work. (EDIT: maybe that's being too harsh, but what I mean is, there's been some work towards doing this but more that could possibly be done, but it's not a trivial problem.)
On my current project, "cargo check" takes ten seconds, and "cargo build" takes 16. That's 62.5% of the total compilation time taken by code generation, roughly (and linking, if you consider those two to be separate).
In my understanding, there can sometimes be problems with -Z time-passes, but when checking my main crate, type_check_crate takes 0.003 seconds, and llvm_passes + codegen_crate take 0.056 seconds. Out of a 0.269 second total compilation time, most things take less than 0.010 seconds, but other than the previous codegen mentioned, monomorphization_collector_graph_walk takes 0.157s, generate_crate_metadata takes 0.171 seconds, and linking takes 0.700 seconds total.
This general shape of what takes longest is consistent every time I've looked at it, and is roughly in line with what I've seen folks who work on compiler performance talk about.
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.
Exactly!
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.
I'm pretty sure your customers care that your software doesn't segfault!
My customers aren't running my software, I am. They don't know if it segfaulted or not.
If your customers are running your software you might have a business model problem instead of a software quality one.
> Rust will only protect me from things my customers don't care about and don't understand.
Are you suggesting your customers don't care about CVE's, even indirectly when it affects them?
> Rust will only protect me from things my customers don't care about and don't understand.
That's the wrong kind of protection. Rust should protect you from things people other than your customers (who presumably are well behaved) care about.
Disagree.
I think this is a self-delusion experienced by Rustaceans because they overvalue a certain type of software correctness and because Rust gets that right, the rest of its warts are invisible.
1991 tag. An all time classic.
(1991)
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 1980s, despite them being superior in every way compared to regular ones?
"Worse" vacuums are "better" for the economy? (because Dyson makes jobs and consumes resources?)
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.
True; but my family and neighbors had them and they seemed to last forever. Maybe they were made so well that the company couldn't gain repeat sales often enough.
What the heck is a central vaccum? One plumbed into the house? Isn't that spectacularly expensive?
>A main disadvantage of central vacuums is the higher initial cost. In the United States, the average central vacuum system has an installed cost of around $1,000.
https://en.wikipedia.org/wiki/Central_vacuum_cleaner
Considering the price of a house it isn't "spectacularly expensive". On the other hand vs the price of a hoover yeah a bit. Since it sits in a closet or garage and doesn't move, weight becomes a non issue so it can be a real behemoth of a vacuum.
Seems like it could be rather expensive to retrofit, compared to cost of putting it in the house to start with (certainly I couldn't imagine getting it retrofitted into my UK house -- the labour alone to dig channels into walls and then make good again and redecorate would dwarf the equipment cost). But the thing about features put in a house when it's built is that they have to meet the economic bar of "do potential buyers value them enough to pay XYZ more than they otherwise would", which can be quite hard. If the average buyer wouldn't value the house at an extra $1000 then it's not worth the builder installing one...
I have one (in a ~2yo house). It's a nice idea, but practically the hoses are a pain in the ass, and I still use my Dyson almost exclusively.
Yes, one plumbed into the house.
> Isn't that spectacularly expensive?
Not spectacularly expensive when installed as the house is built. It's another run of pvc pipe in the walls before you close them up. Approx a day of labor and some pipe are the added expense - not much in terms of house building cost at all. Hardwood floors are much more expensive - and still need to be swept or vacuumed.
And then we wonder why everything gets worse and worse.
> ... everything gets worse and worse ...
They're coming to take me a away haha
they're coming to take me a away hoho hihi haha
to the funny farm where code is beautiful all the time ...
Via: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
what is getting worse and how?
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 and uncomfortable. Which they are .. for the right hand of a right-handed person.
Other popular examples of such taste controversy are Python's semantic whitespace, the idioyncracies of Perl, the very unusual shape of J/APL, and anyone using FORTH for non-trivial purposes.
edit: https://news.ycombinator.com/item?id=41766753 comment about "other people's Lisp" reminds me, that working as a solo genius dev on your own from-scratch code and working in a team inside a large organization on legacy code are very different experiences, and the "inflexibility" of some languages can be a benefit to the latter.
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... 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.
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. Not to mention doc not shown for applications they made for 3D graphics or document editing (https://youtube.com/watch?v=ud0HhzAK30w)
I've always preferred to use classical "fine" artists as an metaphor for development language preferences. Artists don't just pick up any medium at a whim, most have specific mediums that they excel in and ignore the others. For example Van Gogh produced his most famous works in oil paints. He had worked in other mediums but his talent definitely seemed to shine when working in oils and when he first found oils he took to them quickly and adopted them as his primary medium.
Most people definitely seem to have specific preferences built into their talents. I don't see why programming or programming languages would be any different from any other medium or art form.
I've seen Common Lisp source code that I didn't even recognise as Common Lisp because of over-enthusiastic use of reader macros...
Edit: I should also mention that once I worked out how reader macros worked I went on to enthusiastically (ab)use them for my own ends...
If there has been over-enthusiastic use of reader macros, I think we will have to admit that the over-enthusiastic developer is no longer writing Common Lisp code.
Those reader macros have morphed the language into a new bespoke language. So it is then natural for a new developer to face a steep learning curve to learn that new bespoke language before they can make sense of the code.
I'm not condoning overuse of macros. I'd hate to be working with such code too. I'm only stating that Common Lisp is that language that can be programmed to become a different language. They call it a "programmable programming language" for a reason.
I would say the analogy fails because it's not about discomfort or weirdness (or taste); left-handed scissors just don't work if you try to use them right-handed. But right-handed scissors don't work if you try to use them left-handed either.
So it's not about taste or preference, left handed people learn how to use right-handed scissors, but they can also use left handed scissors in a way that a right-handed person would struggle to.
All that said, the analogy still works because most people don't understand why it doesn't work.
> What if that's not true?
It is definitely not true. The existence of neurodivergence is proof enough.
I can visualize an entire application in my head like it is a forest. I can fly around and see various parts and how they fit together. I am unable to juggle the tokens necessary to do logic and basic math in my head but I have no trouble reading a graph in understanding the relationships between numbers.
No matter how many times I try to read it, Lisp is completely inscrutable to me. It requires the same token juggling math does.
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? 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
> 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 – so much so that the New Jersey people skipped right past most of it.
Today these things are par for the course. At the time, they were the The Right Thing that made the system correct but complex, and had adoption penalties. As time passes, the bar for The Right Thing shifts, and today, it would probably not be embodied by Lisp, but maybe by something like Haskell or Rust?
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 don't think there's a Common Lisp implementation with any kind of parametrically-polymorphic static type system, not even as an optimization. First-class functions are also from 01959, or, arguably from 01936, in the untyped λ-calculus, or 01920, in combinatory logic.
Some of these things were brand spanking new in 01973, but none were in 01991.
There were Lisp systems for minicomputers like the PDP-11; BSD included one (which I think was ancestral to Franz Lisp) and XLISP ran on CP/M. And of course Smalltalk was developed almost entirely on PDP-11-sized minicomputers. But to my recollection virtually all "serious" software for microcomputers and minicomputers was written in low-level languages like assembly or C into the late 80s, not even PL/M—though Pascal did start to win in the late 80s, in significant part by adopting C's low-level features. Nowadays, microcomputers are big enough and fast enough that Lisp, Haskell, or even Rust is viable.
I don't think "the right thing" is mostly about what features your system has. I think it has more to do with designing those features to work predictably and compose effectively.
Ever used SBCL?
I love SBCL. Does Python optimize with parametric polymorphism now?
> > At the time C was invented
> C is from 01973.
> Some of these things were brand spanking new in 01973
...right. The Rise of Worse is Better is a memoir, it's set in the past.
> 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 everywhere).
Lisp-2, Prolog, Dylan, Erlang, Julia, R....
Are all homoiconic without being full of parenthesis all over the place, the actual meaning is code and data being interchangeable.
I think following what's written in Wikipedia (https://en.wikipedia.org/wiki/Homoiconicity#Implementation_m...) and only using the adjective for stuff like Lisp, Tcl, Rebol is better than diluting its meaning to the point where it applies to any language with tree-sitter bindings and a parser.
Prolog, Dylan, Julia, and R are stuff like Lisp, Tcl, and Rebol. I don't know about Erlang, and I don't know what pjmlp means by "Lisp-2", which I normally interpret as meaning a Lisp with different namespaces for functions and variables, following Steele's terminology.
> ... I don't know what pjmlp means by "Lisp-2", which I normally interpret as meaning a Lisp with different namespaces for functions and variables ...
There indeed was a language named LISP 2: https://dl.acm.org/doi/pdf/10.1145/1464291.1464362
I posted it on HN two weeks ago but it didn't get much traction: https://news.ycombinator.com/item?id=41640147
Aha, thanks!
Looking at https://docs.julialang.org/en/v1/manual/metaprogramming/, I have a hard time considering it "fully" homoiconic, as the parsed data structure Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1) isn't the same representation as the code itself, even having some new elements like :call.
How it this different from tree-sitter, except that you can feed the modified code back to the language to evaluate?
I mean, don't get me wrong, Julia metaprogramming seems lovely, but it just seems to me that the word loses meaning if it can applied to all languages with AST macros, no matter how gnarly the AST data structure is (is Rust homoiconic because of proc_macro?).
First, I want to point out that I've never written a single line of Julia code, so I'm no expert on this. I could easily be wrong about some of what I just found out by reading a small amount of Julia documentation.
However, that's not a parsed data structure; it's a Julia expression to construct one. Though I don't have Julia installed, apparently you can just as well write that as :(a + b*c + 1), as explained a few paragraphs further down the page than I guess you read: https://docs.julialang.org/en/v1/manual/metaprogramming/#Quo.... That's also how Julia represents it for output, by default. What you've written there is the equivalent of Lisp (list '+ 'a (list '* 'b 'c) 1), or perhaps (cons '+ (cons 'a (cons (cons '* (cons 'b (cons 'c '()))) (cons 1 '())))). The data structure is as simple as Prolog's, consisting of a .head such as :call and a list of .args. Prolog's, in turn, is only slightly more complex than Lisp's. From a certain point of view, Prolog's structure is actually simpler than Lisp's, but it's arguable.
How this is different from having a tree-sitter parser is that it's trivially easy to construct and analyze such structures, and not just at compile time.
Possibly the source of your confusion is the syntactic sugar which converts x + y + z into what we'd write in Lisp as (+ x y z), and also converts back? I would argue that such syntactic sugar is precisely what you want for constructing and analyzing expressions. That is, it's part of what makes Julia homoiconic in a more useful sense than J. Random Language equipped with a parser for its own syntax.
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.
Counterpoint: Some other “worse” would have probably taken over. We’ve seen this in the personal computing market, where MS-DOS (later Windows) and the x86 won out against competing operating systems and ISAs not because of technical superiority, but because of market forces and cost. Look at the evolution of the Web, especially JavaScript....
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.
Or maybe we would be enjoying VMS or something like that, not written in a language that 60 years later after its inception still doesn't do bounds checking and decays arrays into pointers to save typing four characters.
BLISS-11 didn't do bounds-checking either. VMS was my favorite operating system until I got access to a Unix. People chose Unix because it was better—and not just by a little. Handicapping Unix wouldn't have improved the alternative systems.
VMS also supported Pascal and BASIC dialects for systems programming, in equal footing to BLISS.
People choose free beer, it always goes even if warm.
VAX Pascal is viable for systems programming (though standard Pascal wasn't). I only ever used VAX BASIC a tiny bit; was it interpreted like microcomputer BASICs? That made BASIC a nonstarter for "serious software" in the 80s. Not having records, local variables, or subroutine parameters was also a pretty big problem, but maybe VAX BASIC fixed that.
I wasn't paying for access to VMS either; it just didn't hold a candle to Unix.
No one really uses standard C for systems programming, yet that always applies to other languages.
There is always Assembly, compiler extensions, or OS specific APIs, as part of the deliverable.
Funny how UNIX folks always have these two weights approach.
I beg to differ in wax quality for candles, but if we get to do juice with bitter lemons, so be it.
At least is refreshing during Summer.
Do you know if VAX BASIC fixed the problems I mentioned in BASIC? Was it interpreted?
K&R C has separate compilation, pointer casting, a usable but janky and bug-prone variable-length string type, variadic functions, static variables, literal data of array and record types, bitwise operations, a filesystem access API, and an array iterator type. None of those require "assembly, compiler extensions, or OS specific APIs." (Well, I'm not sure if they specified variadic functions in the book. The first ANSI C did.)
Jensen & Wirth Pascal has none of those, making it completely inadequate for anything beyond classroom use, which was what it was designed for.
Each Pascal implementation that was used for systems programming did of course add all of these features, but many of them added them in incompatible ways, with the result that, for example, TeX had to implement its own string type (in WEB).
Imagine if RMS brought Lisp OS with Emacs not being bound to GNU/Unix. JITted Emacs since the 2000 and Eshell as the default CLI, with a floating WM as an easy desktop. Multithreaded, own modules for images/PDF and whatever. No need for security, daily backups and rollbacks would be granted. Today you would be 'rewinding in time' from Emacs if any attack happened.
Vaporware can always be better than actually existing software because vaporware doesn't have bugs or schedule/scope tradeoffs.
I like LISP, but I wouldn't say I'm an evangelist. Here's my 2 cents for why LISP has such a following.
1. LISP is easy to start with if you're not a programmer. There is very little syntax to get to grips with, and once you understand "everything is a list" it's super easy to expand out from there.
2. LISP really makes it easy to hack your way to a solution. With the REPL and the transparency of "code is data" model you can just start writing code and eventually get to a solution. You don't need to plan, or think about types, or deal with syntax errors. You just write your code and see it executed right there in the REPL.
For my part, I love LISP when it's just me doing the coding, but once you start adding other peoples custom DSL macros or whatever the heck it becomes unwieldy. Basically, I love my LISP and hate other peoples LISP.
Once you get far enough to need external dependencies, do you use your work as a library in another language or rewrite it?
Keep in mind that this essay was written in the early 1990s. Today there are many programming languages available that offer features that are unavailable in C but have long been available in Lisp. This was not the case in the 1980s during the AI boom of that era. There was a large chasm between classic procedural languages (C, Fortran, Pascal, Simula) and dynamic languages (Smalltalk and Lisp). Prolog was a popular alternative to Lisp in AI circles, especially in Japan back when it was pursuing the Fifth Generation Computing Project. When looking at the language landscape in the 1980s in the context of AI, it makes sense that practitioners would gravitate toward Lisp and Prolog.
Today we benefit from having a variety of languages, each with tradeoffs regarding how their expressiveness matches the problem at hand and also the strength of its ecosystem (e.g., tools, libraries, community resources, etc.). I still think Lisp has advantages, particularly when it comes to its malleability through its syntax, its macro support, and the metaobject protocol.
As a Lisp fan who codes occasionally in Scheme and Common Lisp, I don’t always grab a Lisp when it’s time to code. Sometimes my language choices are predetermined by the ecosystem I’m using or by my team. I also think strongly-typed functional programming languages like Standard ML and Haskell are quite useful in some situations. I think the strength of Lisp is best seen in situations where flexibility and have malleable infrastructure is highly desirable.
Such a weird take on HN. Lisp should be experimented with if only to appreciate the profound beauty of a small, powerful, cohesive design. It is a wholly different feeling from industry standard languages which are constantly changing.
In Lisp, almost all of the language’s power is in “user space.”
The ramifications for that are deep and your beliefs as to whether that is good are largely shaped by whether you believe computation is better handled by large groups of people (thus, languages should restrict users) or smaller groups of people (thus, languages should empower users).
See this for more discussion: https://softwareengineering.stackexchange.com/a/237523
> languages which are constantly changing
They change because they are used.
Well the main point is that there are changes that for most languages would need a change in the compiler/interpreter itself. However in lisp those kinds of things can be done in userspace
LISP remains one of the only languages where manipulating the code looks exactly the same as executing it. This is often illustrated by pointing out that "eval" in lisp doesn't take in a string of characters. (https://taeric.github.io/CodeAsData.html is a blog I wrote on the idea a bit more.)
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.
In the words of "Programmers Are Also Human" YouTube channel, it's just more comfortable. REPL development, ease of refactoring, dynamic typing, good CFFI, all just adds up to a developer experience that I find to be, in a word, chill.
See these demos for the kinds of interactive systems LISP enabled back in the day:
https://www.youtube.com/watch?v=o4-YnLpLgtk
https://www.youtube.com/watch?v=gV5obrYaogU
It makes working on VSCode today look like banging rocks together, let alone 30 years ago.
And today with Lem/Emacs+slime+sbcl
It's not really about lisp or even about vague reverse-snobbish ideas of "practicality" but about very specific categories of design compromises.
It’s for the dreamers. The crazy ones among us that do not think of themselves as experts in programming machines to solve business problems, but rather novices in cajoling machines to think like humans do.
The paper was written for an audience of Lisp programmers, so the things you're talking about were sort of out of scope. I'm not going to try to convince you that Lisp and ITS really did aim at "the right thing" in a way that C and Unix didn't; you'll see that it's true if you investigate.
Lisp definitely does depend on personality type. Quoting Steve Yegge's "Notes from the Mystery Machine Bus" (https://gist.github.com/cornchz/3313150):
> Software engineering has its own political axis, ranging from conservative to liberal. (...) We regard political conservatism as an ideological belief system that is significantly (but not completely) related to motivational concerns having to do with the psychological management of uncertainty and fear. (...) Liberalism doesn't lend itself quite as conveniently to a primary root motivation. But for our purposes we can think of it as a belief system that is motivated by the desire above all else to effect change. In corporate terms, as we observed, it's about changing the world. In software terms, liberalism aims to maximize the speed of feature development, while simultaneously maximizing the flexibility of the systems being built, so that feature development never needs to slow down or be compromised.
Lisp, like Perl and Forth, is an extremist "liberal" language, or family of languages. Its value system is centered on making it possible to write programs you couldn't write otherwise, rather than reducing the risk you'll screw it up. It aims at expressiveness and malleability, not safety.
The "right thing" design philosophy is somewhat orthogonal to that, but it also does pervade Lisp (especially Scheme) and, for example, Haskell. As you'd expect, the New Jersey philosophy pervades C, Unix shells, and Golang. Those are also fairly liberal languages, Golang less so. But a C compiler had to fit within the confines of the PDP-11 and produce fast enough code that Ken would be willing to use it for the Unix kernel, and it was being funded as part of a word processing project, so things had to work; debuggability and performance were priorities. (And both C and Unix were guided by bad experiences with Multics and, I infer, M6 and QED.) MACLISP and Interlisp were running on much more generous hardware and expected to produce novel research, not reliable production systems. So they had strong incentives to both be "liberal" and to seek after the "right thing" instead of preferring expediency.
It’s a signaling mechanism to say “I went to MIT” or at the very least to say “I could have gone to MIT”.
I learned Racket at Brigham Young University in Utah, and Clojure, then Common Lisp on my own. I don't think it's just an MIT thing. It's in the ethos now. Lots of people know about SICP, for example.
How do you know someone knows lisp? They'll tell you. And tell you. And tell you...
I like lisp for the most part, but holy shit is the enduring dialog surrounding it the absolute worst part of the whole family of languages by far. No, it doesn't have or give you superpowers. Please grow up.
