[HN Gopher] The Rise of Worse Is Better (1991)
___________________________________________________________________
The Rise of Worse Is Better (1991)
Author : t14n
Score : 161 points
Date : 2024-10-07 14:22 UTC (8 hours ago)
(HTM) web link (www.dreamsongs.com)
(TXT) w3m dump (www.dreamsongs.com)
| Dansvidania wrote:
| looking at how it played out with javascript one can't but agree.
|
| (edit: I mean it unironically)
| TacticalCoder wrote:
| 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.
| karel-3d wrote:
| 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
|
| https://youtu.be/EeYvFl7li9E
| GiorgioG wrote:
| It will always be a turd. Typescript is a nice illusion,
| but underneath is still the same turd.
| actionfromafar wrote:
| To me WASM is the wildcard. It lets other languages
| infect the Javascript host organism.
| api wrote:
| 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.
| Der_Einzige wrote:
| 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
| actionfromafar wrote:
| Javascript is the _only_ language which straddled the
| Client Server Gap. If it weren 't for Node, Javascript
| would not have been as popular.
| api wrote:
| 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.
| bigstrat2003 wrote:
| 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?
| homebrewer wrote:
| 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.
| api wrote:
| Reducing cognitive load by having only one language. In
| theory at least. In reality server side JS tends to turn
| into dependency hell and over time to suffer the typical
| melting into a blob of hacks that dynamic language code
| bases suffer.
|
| TypeScript improves on the latter problem.
| GiorgioG wrote:
| 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.
| adastra22 wrote:
| We will still be stuck with it forever for compatibility
| reasons
| aredox wrote:
| And then we wonder why everything gets worse and worse.
| ta988 wrote:
| what is getting worse and how?
| st_goliath wrote:
| > ... 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 ...
|
| -- Napoleon XIV, more or less...
|
| Via:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
| dkasper wrote:
| 1991 tag. An all time classic.
| orwin wrote:
| 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?
| gpderetta wrote:
| Empirically, it seems Worse is Better appear to have been
| correct many many times.
| kayo_20211030 wrote:
| 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.
| AnimalMuppet wrote:
| 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.
| ezekiel68 wrote:
| 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.
| ripap wrote:
| Worse is Better is Worse:
| https://www.dreamsongs.com/Files/worse-is-worse.pdf
|
| Same author (name is an anagram).
| gpderetta wrote:
| A pseudonym you mean?
| AnimalMuppet wrote:
| An anagram. Same letters, different order.
| gpderetta wrote:
| I might be dense today, but how's Nickieben Bourbaki an
| anagram of Richard P. Gabriel?
| jes5199 wrote:
| both!
| jes5199 wrote:
| the name also seems to be a reference to another pseudonym,
| https://en.wikipedia.org/wiki/Nicolas_Bourbaki
| orwin wrote:
| I wish i could upvote you more than once. This is a very good
| counterargument.
| samatman wrote:
| 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.
| NAHWheatCracker wrote:
| 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.
| tialaramex wrote:
| 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.
| kqr wrote:
| 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.
| Feathercrown wrote:
| I think the counterargument is that something being easy to
| proliferate doesn't mean that it's good.
| gpderetta wrote:
| > 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.
| ezekiel68 wrote:
| Yep. And nary a tear is shed these days over the death of the
| so-called superior Lisp machines.
| rwmj wrote:
| Maybe not in any position to do anything about it, but I'm
| quite sad :-/
| gpderetta wrote:
| The Spirit of the Machine still lives in some form in emacs.
| Jach wrote:
| 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.
| i_s wrote:
| 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."
| NAHWheatCracker wrote:
| 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.
| adamnemecek wrote:
| It's a signaling mechanism to say "I went to MIT" or at the
| very least to say "I could have gone to MIT".
| djha-skin wrote:
| 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.
| Blackthorn wrote:
| 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.
| anthk wrote:
| Do either the book on Symbolic Computation + PAIP and/or
| SICP, and you'll understand.
| yoyohello13 wrote:
| 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.
| turtleyacht wrote:
| Once you get far enough to need external dependencies, do you
| use your work as a library in another language or rewrite it?
|
| http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
| anthk wrote:
| 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 docstring
| looking up tool, you are god.
| kqr wrote:
| > 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?
| pjc50 wrote:
| > 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).
| pjmlp wrote:
| 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.
| BoingBoomTschak wrote:
| 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.
| kragen wrote:
| 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.
| susam wrote:
| > ... 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
| kragen wrote:
| Aha, thanks!
| BoingBoomTschak wrote:
| 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?).
| kragen wrote:
| 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.juliala
| ng.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.
| pjmlp wrote:
| 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.
| linguae wrote:
| 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.
| pjmlp wrote:
| 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.
| kragen wrote:
| 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.
| pjmlp wrote:
| 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.
| kragen wrote:
| 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.
| pjmlp wrote:
| 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.
| kragen wrote:
| 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).
| anthk wrote:
| 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.
| kragen wrote:
| Vaporware can always be better than actually existing
| software because vaporware doesn't have bugs or
| schedule/scope tradeoffs.
| kragen wrote:
| 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
| l-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.
| samatman wrote:
| > > _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.
| anthk wrote:
| Ever used SBCL?
| kragen wrote:
| I love SBCL. Does Python optimize with parametric
| polymorphism now?
| Jach wrote:
| What do you think of Coalton?
| pjc50 wrote:
| 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.
| arethuza wrote:
| 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...
| blenderob wrote:
| 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.
| sceptic123 wrote:
| 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.
| kayodelycaon wrote:
| > 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.
| eikenberry wrote:
| 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.
| Jach wrote:
| 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... for table tennis. 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. If downsides
| are mentioned at all it's often not about the preferred
| thing, but some deficiency of something else.
|
| 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 and heritage. Not to mention doc
| and so on not shown for applications they made for 3D
| graphics or document editing
| (https://youtube.com/watch?v=ud0HhzAK30w)
| djha-skin wrote:
| 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.
| mattgreenrocks wrote:
| 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
| pif wrote:
| > languages which are constantly changing
|
| They change because they are used.
| skribanto wrote:
| 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
| linguae wrote:
| 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.
| kragen wrote:
| 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.
| bbor wrote:
| 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.
| hcarvalhoalves wrote:
| 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.
| anthk wrote:
| And today with Lem/Emacs+slime+sbcl
| taeric wrote:
| 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.
| buescher wrote:
| It's not really about lisp or even about vague reverse-snobbish
| ideas of "practicality" but about very specific categories of
| design compromises.
| Jach wrote:
| 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? I'm not saying it'll
| spark joy in you, just that you might understand. (Do you
| understand Haskell's draw to certain people? Rust's?) 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
| api wrote:
| 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.
| djha-skin wrote:
| 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.
| busterarm wrote:
| 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.
| warkdarrior wrote:
| > 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.
| crabmusket wrote:
| I'm pretty sure your customers care that your software
| doesn't segfault!
| busterarm wrote:
| 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.
| morning-coffee wrote:
| > 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?
| busterarm wrote:
| 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.
| dokyun wrote:
| 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.
| steveklabnik wrote:
| > 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.
| dokyun wrote:
| ....so why is it so slow to generate code?
| steveklabnik wrote:
| 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.
| Der_Einzige wrote:
| 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?)
| AnimalMuppet wrote:
| Central vacuums are worse in at least one specific way: Cost of
| fixing or replacing them when they break.
| ezekiel68 wrote:
| 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.
| floren wrote:
| Also, I can take my regular vacuum out into the garage and
| clean the car.
| pjc50 wrote:
| What the heck is a central vaccum? One plumbed into the house?
| Isn't that spectacularly expensive?
| stonemetal12 wrote:
| >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.
| pm215 wrote:
| 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...
| jen20 wrote:
| 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.
| kragen wrote:
| Yes, one plumbed into the house.
| sophacles wrote:
| > 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.
| bee_rider wrote:
| 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.
| dmansen wrote:
| New Jersey: https://en.wikipedia.org/wiki/Bell_Labs
| bee_rider wrote:
| Oh. Ok, that makes sense.
| ezekiel68 wrote:
| I made the same error when I first read it years ago. It
| certainly felt like an academic reference.
| karel-3d wrote:
| (1991)
| shagie wrote:
| 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/d
| ocs/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.
| karel-3d wrote:
| 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"
| pjc50 wrote:
| 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?
| kragen wrote:
| 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/1iL0fY
| mMmariFoSvLd9U5nPVH...
|
| I'm not sure he's right, but I do think his point of view is
| important to understand.
| fanf2 wrote:
| 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
| kragen wrote:
| 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._
| chuckadams wrote:
| 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.
| fanf2 wrote:
| BTDTGTTS https://shop.isc.org/collections/shirts/products
| /osi-9-layer...
| chuckadams wrote:
| I can't claim to have BTDT, but I did get the T-shirt.
| That's how I learned them :)
| lizknope wrote:
| 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.
| kragen wrote:
| I'm interested to hear what you think! I haven't finished
| reading it yet. It's a bit repetititive.
| fanf2 wrote:
| 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.
| foobarian wrote:
| I finally understand why OSI failed, it's the naming! Dear
| lord.
| rwmj wrote:
| https://www.wired.com/1996/10/atm-3/ Netheads vs Bellheads
| chuckadams wrote:
| > "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 ;)
| bee_rider wrote:
| Haha, I didn't get it until your last sentence
| hiatus wrote:
| X.25 is still used in ham radio with AX.25
| PhilipRoman wrote:
| 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.
| ahoka wrote:
| The problem is that this is not true. There are no such clean
| strictly hierarchical layers in most of the protocols that
| make up the internet.
| supportengineer wrote:
| I've never done any kernel programming but I assumed the OSI
| model corresponded to Linux kernel modules or a similar
| division internally.
| hammock wrote:
| 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
|
| [1]https://tinaja.computer/2017/10/13/expedience.html
| onlyrealcuzzo wrote:
| > 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?
| hammock wrote:
| 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.
| UniverseHacker wrote:
| 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.
| adastra22 wrote:
| I think Toyota would have gotten your point across better.
| Tesla is most certainly not expedient. It is a luxury
| purchase.
| foobazgt wrote:
| 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.
| marxisttemp wrote:
| "In a class above Toyota" in what sense? Certainly not in
| reliability or interior quality or CarPlay
| compatibility...
| KerrAvon wrote:
| Neither. Going by the parent poster's gauge, the most
| "expedient" is probably Lucid; better engineering, better
| range, and better service.
| KerrAvon wrote:
| but it's really not what "expedient" means
| jprete wrote:
| 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.
| AnimalMuppet wrote:
| If you include the cost of gathering information, the expedient
| solution may in fact be the best.
| dkarl wrote:
| "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.
| circlefavshape wrote:
| > 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
| downWidOutaFite wrote:
| No you don't because there is no expedient solution.
| hinkley wrote:
| See also: war crimes
| KerrAvon wrote:
| I think this is misleading -- geoengineering + social change
| will be necessary. You're not going to Scotty your way out of
| climate change.
| ambicapter wrote:
| What's misleading here? He was using that as an example of
| usage of the word 'expedient', not actually suggesting
| climate change solutions.
| adastra22 wrote:
| 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?
| downWidOutaFite wrote:
| why are you fantasizing? none of that is going exist
| (caveat: unless we figure out infinite clean energy).
| adastra22 wrote:
| 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.
| Hasu wrote:
| 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.
| CM30 wrote:
| 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.
| lisper wrote:
| > 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.
| katbyte wrote:
| 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
| WalterBright wrote:
| > 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.
| contagiousflow wrote:
| Are you removing paid working time in doing the extra work?
| If not it is just an opportunity cost
| WalterBright wrote:
| In my line of work, yes.
| d0mine wrote:
| 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
| hammock wrote:
| 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)
| RcouF1uZ4gsC wrote:
| >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.
| clarkevans wrote:
| 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.
| AnimalMuppet wrote:
| 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.
| jes5199 wrote:
| what's the old saw about "unix design prioritizes simplicity over
| correctness, and on modern hardware simplicity is also no longer
| considered necessary"
| marcosdumay wrote:
| 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.
| mseepgood wrote:
| Maybe don't call it "worse", maybe it's just you who has a skewed
| perception of "good"/"right".
| hammock wrote:
| 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."
| stonemetal12 wrote:
| 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.
| JohnFen wrote:
| "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.
| ezekiel68 wrote:
| 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.
| dang wrote:
| 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)
| dang wrote:
| ... 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)
| ezekiel68 wrote:
| 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."
| bbor wrote:
| 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
| hyggetrold wrote:
| It's a funny expression _and_ it is rooted in advertising:
| https://en.wikipedia.org/wiki/Frank_Perdue
| sebastianconcpt wrote:
| To _Worse is Better_ I 'd say, careful with what you wish.
| agumonkey wrote:
| 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.
| bccdee wrote:
| > 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.
___________________________________________________________________
(page generated 2024-10-07 23:00 UTC)