Hacker News Reader

Comment by robotresearcher | Hacker News Reader

Because Worse is Better applies here as usual. Java was fast enough and familiar enough and the libraries were good enough and the language safe enough and Sun supported it well enough in the enterprise. Nothing else had the same combination of okayness. I never enjoyed Java but it had my half-grudging respect.

View on HN

I'd agree with you with the caveat that "worse" in that paper means that something might be less elegant or rigorous on a theoretical level but still the more practical choice.

And now that we have good, modern high level languages with robust but flexible type systems I'd choose Haskell or Ocaml or maybe Swift over Smalltalk or Lisp if I wanted to stick my neck out technically on a project. I consider dynamically typed languages to be significantly "worse" in an absolute sense for building non-trivial software.

No caveat needed: that's exactly how I intended the use of 'worse'. I linked the original essay in another comment below.

> And now that we have good, modern high level languages with robust but flexible type systems I'd choose Haskell or Ocaml or maybe Swift over Smalltalk or Lisp if I wanted to stick my neck out technically on a project. I consider dynamically typed languages to be significantly "worse" in an absolute sense for building non-trivial software.

I don't know if there are any typed SmallTalks, but Common Lisp has optional static typing: you can declare types and the compiler will enforce them. This seems to me the best of both worlds: the freedom to interact with your program dynamically, with the safety of strong static types.

But with Common Lisp, you don't get the safety of strong static types. If the compiler can prove that there's a type error, it will throw an error. That's not the same as throwing a type error when the compiler can't prove that there isn't a type error, as a sound type system would.

Even worse, Common Lisp will use your type annotations to optimize code, which can change the behavior of your program. It's better to think of them as type hints for optimization than to think of them as optional static types.

That's true, because doing so in Lisp is undecidable and because you allow function definitions to change (that's why type checking works better with inline and local functions).

The type of analysis applied to Lisp is adapted to its type system: you have ranges of values, unions, etc. In particular SBCL can exploit some relationships between runtime values and types (I detailed it recently, so I prefer not to repeat myself: https://news.ycombinator.com/item?id=12222404)

As far as I am concerned, it is already quite powerful to detect the type-related errors that I tend to do. The part that cannot be decided during compilation is left to be checked at runtime, which is strong dynamic safety. Instead of manipulating untyped bits, you have all you need to never corrupt the state of your program. The good news is that if implementors make progress with type inference, you don't have to change the language: more checks can move from runtime to compile-time (the hard stuff would be the check the "satisfy" type ;-).

With some types left to be checked at runtime, you end up in a situation that is no worse than statically typed programs which throw exceptions for other kinds of errors. Sometimes, those errors arise because programmers implement a dynamic things, like ad-hoc tags to identify objects at runtime (so this is basically a dynamic type system in disguise). Other errors related to safety are tied to temporal issues, deadlocks, permissions, priority, security, etc. You can't always encode them with types. There are formal tools for dealing with them, but at this point, whether you use them generate safe code in Lisp or OCaml is not very important (and generating Lisp code is straightforward).

> Even worse, Common Lisp will use your type annotations to optimize code, which can change the behavior of your program.

This is a strange concern. The modified behavior belongs to the set of behaviors that would be possible without checking types, not a new, faulty behavior that contradicts what the code says.

> Because Worse is Better applies here as usual.

It's not that simple. They lost for very pragmatic reasons: Smalltalk and Lisp were worse than Java in many ways (even smaller than Java's initial implementations, Smalltalk's binary images were undeployable in production, these two languages are dynamically typed, etc...).

[1] https://en.wikipedia.org/wiki/Smalltalk#History, scroll midway down:

"During the late 1980s to mid-1990s, Smalltalk environments -- including support, training and add-ons -- were sold by two competing organizations: ParcPlace Systems and Digitalk, (...) Both firms struggled to take Smalltalk mainstream due to Smalltalk's substantial memory needs, limited run-time performance, and initial lack of supported connectivity to SQL-based relational database servers. (...)"

"In 1995, ParcPlace and Digitalk merged into ParcPlace-Digitalk and then rebranded in 1997 as ObjectShare (...) The merged firm never managed to find an effective response to Java as to market positioning, and by 1997 its owners were looking to sell the business."

There was also Strongtalk, a strongly typed variant of Smalltalk. The guys who wrote Self and the guys who wrote Strongtalk were both eventually acqui-hired by Sun and they were the ones who wrote HotSpot [2][3]

[2] http://www.strongtalk.org/history.html

[3] https://en.wikipedia.org/wiki/Strongtalk

'Worse is Better' is exactly about pragmatic reasons prevailing over idealism. The 'MIT Way' is the stereotyped opposite approach, and LISP is a great example of that: in theory it's the 'right way', but in practice it fails to address some aspect of real world needs somehow.

I understand that but I still dislike the "Worse is Better" characterization, which sounds very condescending to me and which is usually put forward by proponents of the languages that lost, hinting that the reason for the outcome is because people are stupid and picked the worse alternative.

Looking at how Go has became successful, which is basically Java 1.0 or if you prefer Limbo merged with Oberon-2, it isn't very far from how people pick languages.

At least the amount of insecure C code decreases, as it gets written in a safer language

Well, the originator was a 'losing' LISP guy who admired the robustness and practical effects of the other approach:

"However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach."

"There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up."

Richard Gabriel https://www.jwz.org/doc/worse-is-better.html

I remember Smalltalk and Lisp were pretty slow at the time and required tons of resources to run. Smalltalk and Lisp had better concepts but they fell short in delivering practical result.

Java wasn't really light on resources at any point of its history either.

Java's resource requirement fitted pretty well within the hardware capability at the time, and grew with the hardware over time. Smalltalk and Lisp were quite ahead of their time requiring way more resource than the hardware could provide at the time.

Ok which time are we talking about? In 1965, sure. In the times Java was actually around, it hardly had an edge against Common Lisp (can't comment on Smalltalk) implementations of the day by any resource metric. That's two and a half decades already.

Reply on news.ycombinator.com