5 ms·

If Smalltalk and Lisp are so magical then why didn't they win?

robotresearcher 10y ago
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.
- hota_mazi 10y ago
  > 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...).
  - niftich 10y ago
    [1] https://en.wikipedia.org/wiki/Smalltalk#History 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 http://www.strongtalk.org/history.html [3] https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk
  - robotresearcher 10y ago
    '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.
    - hota_mazi 10y ago
      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.
      - pjmlp 10y ago
        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
      - robotresearcher 10y ago
        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 https://www.jwz.org/doc/worse-is-better.html
- cageface 10y ago
  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.
  - robotresearcher 10y ago
    No caveat needed: that's exactly how I intended the use of 'worse'. I linked the original essay in another comment below.
  - wtbob 10y ago
    > 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.
    - wtetzner 10y ago
      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.
      - junke 10y ago
- ww520 10y ago
  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.
  - varjag 10y ago
    Java wasn't really light on resources at any point of its history either.
    - ww520 10y ago
      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.
      - varjag 10y ago
        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.
deleted 10y ago
[deleted]
sdegutis 10y ago
Why is nobody mentioning Clojure in this thread? I feel like Lisp kind of did win in the sense that Clojure is a reasonably sane Lisp that's gaining popularity and that lives on the JVM.
- JBiserkov 10y ago
  Not only is Clojure "a reasonably sane Lisp", it's a practical language that feels designed (because it is) using "power trough simplicity", decomposition, decompletion. This frees up an enormous number of brain cycles to design the upper layers. It embraces it's host (JVM, JavaScript) which enables tremendous reach and code-reuse; at the same time it fixes most WATs and subtler pitfalls (by using immutable, persistent data (structures) by default).
  - mateuszf 10y ago
    If only the problems of slow startup and unfriendly error messages could be solved - it would be like a dream coming true.
    - soberhoff 10y ago
      I think the spec library that they're putting together right now might be able to solve the error messages. What I'm waiting for is to be able to hit something like dot in my ide and see a list of suggestions, I'm not sure if spec can be leveraged to that extent.
      - swlkr 10y ago
        There is compliment: https://github.com/alexander-yakushev/compliment/wiki/Examples https://github.com/alexander-yakushev/compliment/wiki/Exampl...
        soberhoff 10y ago
        Completing the first half of a symbol that I've been typing already works reasonably well with Cursive. What I'm looking for is something that looks at the result of an expression and figures out what other functions can accept that as input. Matching up specced postconditions with preconditions might work, but I'm not sure how well.
ww520 10y ago
You asked a good question. And I hate to say it but that fact has driven a lot of people up the wall and they couldn't grasp how a language could win widespread adoption.
oblio 10y ago
I don't get why you're being downvoted. Lisp had a 40 year head start, it had commercial backing in multiple iterations, it has a grassroots community that pesters the other to this day. I can't say anything about Smalltalk because I don't know enough about its history, but at this point in time it's pretty sure that unless some sort of major event happens, Lisp won't ever go mainstream.
StreamBright 10y ago
Because just like with many other things humans use the least common denominator wins. Everybody understands the concepts in Java pretty much but having trouble with LISP concepts. Just by interviewing ~40-50 Java programmers (mostly juniors) I can tell that even concepts like recursion is not well known or understood among them. At this level they think they do not need to know these advanced concepts to be successful as a software developer. As a company you want to use a language that everybody can understand so you do not have trouble with hiring, few exceptions (like Jane Street).
twic 10y ago
Smalltalk has a strength and a weakness in its 'image' approach. Smalltalk doesn't really have source code and object code, it has an 'image' full of objects which you can run, and which contains all of the standard library, the development environment, and your code. You work in this image, and save changes as you go along. That makes Smalltalk super easy and convenient to develop in, and very consistent across platforms. But it's a roadblock to publishing code, working as a team, deploying, and the other things you need to do with software that isn't a toy. The Smalltalk environment and community certainly have ways of doing all those things, but they can be clunky, and some of them are quite recent. Meanwhile, C++ was a bit of a pain to write, but once you'd written it, sharing it was as easy as emailing a file, or checking it into RCS (or that hot new CVS thing), and building a production release was a matter of running 'make' and going for lunch. Java kept C++'s simple approach. Smalltalkers at the time laughed at how caveman-like the experience was. But it turned out that that simplicity was exactly what you needed to grow virally on the then-nascent web.

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.

hota_mazi 10y ago
> 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...).
- niftich 10y ago
  [1] https://en.wikipedia.org/wiki/Smalltalk#History 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 http://www.strongtalk.org/history.html [3] https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk
- robotresearcher 10y ago
  '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.
  - hota_mazi 10y ago
    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.
    - pjmlp 10y ago
      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
    - robotresearcher 10y ago
      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 https://www.jwz.org/doc/worse-is-better.html
cageface 10y ago
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.
- robotresearcher 10y ago
  No caveat needed: that's exactly how I intended the use of 'worse'. I linked the original essay in another comment below.
- wtbob 10y ago
  > 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.
  - wtetzner 10y ago
    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.
    - junke 10y ago
ww520 10y ago
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.
- varjag 10y ago
  Java wasn't really light on resources at any point of its history either.
  - ww520 10y ago
    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.
    - varjag 10y ago
      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.

deleted 10y ago

[deleted]

sdegutis 10y ago

Why is nobody mentioning Clojure in this thread? I feel like Lisp kind of did win in the sense that Clojure is a reasonably sane Lisp that's gaining popularity and that lives on the JVM.

JBiserkov 10y ago
Not only is Clojure "a reasonably sane Lisp", it's a practical language that feels designed (because it is) using "power trough simplicity", decomposition, decompletion. This frees up an enormous number of brain cycles to design the upper layers. It embraces it's host (JVM, JavaScript) which enables tremendous reach and code-reuse; at the same time it fixes most WATs and subtler pitfalls (by using immutable, persistent data (structures) by default).
- mateuszf 10y ago
  If only the problems of slow startup and unfriendly error messages could be solved - it would be like a dream coming true.
  - soberhoff 10y ago
    I think the spec library that they're putting together right now might be able to solve the error messages. What I'm waiting for is to be able to hit something like dot in my ide and see a list of suggestions, I'm not sure if spec can be leveraged to that extent.
    - swlkr 10y ago
      There is compliment: https://github.com/alexander-yakushev/compliment/wiki/Examples https://github.com/alexander-yakushev/compliment/wiki/Exampl...
      - soberhoff 10y ago
        Completing the first half of a symbol that I've been typing already works reasonably well with Cursive. What I'm looking for is something that looks at the result of an expression and figures out what other functions can accept that as input. Matching up specced postconditions with preconditions might work, but I'm not sure how well.

ww520 10y ago

You asked a good question. And I hate to say it but that fact has driven a lot of people up the wall and they couldn't grasp how a language could win widespread adoption.

oblio 10y ago

I don't get why you're being downvoted. Lisp had a 40 year head start, it had commercial backing in multiple iterations, it has a grassroots community that pesters the other to this day. I can't say anything about Smalltalk because I don't know enough about its history, but at this point in time it's pretty sure that unless some sort of major event happens, Lisp won't ever go mainstream.

StreamBright 10y ago

Because just like with many other things humans use the least common denominator wins. Everybody understands the concepts in Java pretty much but having trouble with LISP concepts. Just by interviewing ~40-50 Java programmers (mostly juniors) I can tell that even concepts like recursion is not well known or understood among them. At this level they think they do not need to know these advanced concepts to be successful as a software developer. As a company you want to use a language that everybody can understand so you do not have trouble with hiring, few exceptions (like Jane Street).

twic 10y ago

Smalltalk has a strength and a weakness in its 'image' approach. Smalltalk doesn't really have source code and object code, it has an 'image' full of objects which you can run, and which contains all of the standard library, the development environment, and your code. You work in this image, and save changes as you go along. That makes Smalltalk super easy and convenient to develop in, and very consistent across platforms. But it's a roadblock to publishing code, working as a team, deploying, and the other things you need to do with software that isn't a toy. The Smalltalk environment and community certainly have ways of doing all those things, but they can be clunky, and some of them are quite recent. Meanwhile, C++ was a bit of a pain to write, but once you'd written it, sharing it was as easy as emailing a file, or checking it into RCS (or that hot new CVS thing), and building a production release was a matter of running 'make' and going for lunch. Java kept C++'s simple approach. Smalltalkers at the time laughed at how caveman-like the experience was. But it turned out that that simplicity was exactly what you needed to grow virally on the then-nascent web.