5 ms·

Smalltalk remains my all time favorite language. I started programming in the 1960s, with BASIC and FORTRAN (FORTRAN II, in fact, from McCracken's famous "Guid

Smalltalk remains my all time favorite language. I started programming in the 1960s, with BASIC and FORTRAN (FORTRAN II, in fact, from McCracken's famous "Guide"), and before I quit coding professionally, implemented production systems in more than two dozen different languages. Wrote the most lines of code in Java, but the most interesting systems in Fortran, Pascal, Object Pascal (and one in Concurrent Pascal). Liked LISP least of all, followed closely by C++ and COBOL (although APL would probably be at the bottom, had anything I did in that strange elixir ever reach production - none did), but I loved Smalltalk. Unfortunately, Smalltalk arrived to too much hype before it's (potential) time, and was crippled as production language by it's image based development and deployment methodology. A truly elegant and sweet language coupled to a really awful engineering paradigm. Thinking back on all this, I am astonished once again at how much has happened in computing in my lifetime (I am older than FORTRAN, e.g., so essentially all code every compiled has been compiled in my lifetime, unless you want to count Autocoder macros as compiled code).

aeneasmackenzie 4y ago
Usually people mention lisp and smalltalk in the same breath. What turned you off of lisp, especially as compared to smalltalk?
- ErikCorry 4y ago
  Apart from being contemporaneous they have little in common. Lisp is functional, Smalltalk is object oriented.
  - PaulHoule 4y ago
    Both are dynamically type and have garbage collection. Both have lambdas.
  - Qem 4y ago
    Both run in the same context they are written in. See https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-power-of-symmetry-8bd96aaa0c0c https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-pow... Previous discussion: https://news.ycombinator.com/item?id=14333157 https://news.ycombinator.com/item?id=14333157
  - fiddlerwoaroof 4y ago
    Common Lisp is not a functional language. If anything, it’s object oriented. Generally speaking, lisps have always been multi-paradigm languages because macros let them absorb nearly any paradigm you can think of.
- walnutclosefarm 4y ago
  Neither the list paradigm, nor functional languages generally, ever really gelled in my mind, the way, say, OO did. Algorithms expressed in functional form in LISP always seemed contorted from their natural form, to me. So, mostly I found LISP to be an awkward, "unscannable" language. I could write it, and read it, but it always felt a little like reading and writing a foreign language to me, not something in which my mind was native.
  - baldfat 4y ago
    I am the exact opposite :) I started learning languages with Basic, Assembly and Fortran and ended up loving all things Lisp.
nealabq 4y ago
I'm only slightly younger than you, and, like you, have worked in many languages. And my very favorite were the LISPs (zeta, common, scheme). But the dev env, projects, and my time in life were all part of that positive experience. I was in my 20s (a super learning time) working on my own code on Symbolics Lisp machines. Fortran/Ratfor were my least favorite, since that work was always maintaining code written (and barely commented) by someone I didn't know. Smalltalk and Erlang are my next choices. Same reasons as LISP.
Qem 4y ago
> Unfortunately, Smalltalk arrived to too much hype before it's (potential) time, and was crippled as production language by it's image based development and deployment methodology. I was exposed to image based through Pharo, and I've found the idea to be awesome, as it allows very tight feedback loops on development. I see people complaining because it was nontrivial to extricate a finished program from the environment and ship it to customers in a "tamper-proof" opaque form. What puzzles me is why didn't Smalltalk play a bigger role on the ascension of free and open source software, given what was a bug for proprietary shops (hard to ship a opaque binary) is actually a feature for copyleft development (fully inspectable source code together with full development environment included by default). The GNU-Smalltalk development appears to be mostly stale. The torch of free smalltalk is carried most by Squeak and Pharo today.
- igouy 4y ago
  > … nontrivial to extricate a finished program from the environment and ship it to customers in a "tamper-proof" opaque form. 1) source code management Even ancient Smalltalk-80 provided — "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... 2) deployment Not all software was shrink-wrap — plenty of high-value enterprise software.
  - walnutclosefarm 4y ago
    Smalltalk images were fine for one-person development of single programs. Not really very manageable for teams, and modular development though. Not that these things couldn't be done - we certainly did it at IBM, when SmallTalk was the "thing" there for a while - but it never was very satisfactory. A lot of developers significantly younger than me seem to think that source code control was developed in the the last couple of decades, but in fact we did source code control, modular development, and build pipelines way back in the 70s - mostly with home built tools, but the capabilities began to be built out as soon as source code left card decks for permanent residence and in place modification on rotating storage. And SmallTalk was at best hostile to all those techniques.

aeneasmackenzie 4y ago

Usually people mention lisp and smalltalk in the same breath. What turned you off of lisp, especially as compared to smalltalk?

ErikCorry 4y ago
Apart from being contemporaneous they have little in common. Lisp is functional, Smalltalk is object oriented.
- PaulHoule 4y ago
  Both are dynamically type and have garbage collection. Both have lambdas.
- Qem 4y ago
  Both run in the same context they are written in. See https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-power-of-symmetry-8bd96aaa0c0c https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-pow... Previous discussion: https://news.ycombinator.com/item?id=14333157 https://news.ycombinator.com/item?id=14333157
- fiddlerwoaroof 4y ago
  Common Lisp is not a functional language. If anything, it’s object oriented. Generally speaking, lisps have always been multi-paradigm languages because macros let them absorb nearly any paradigm you can think of.
walnutclosefarm 4y ago
Neither the list paradigm, nor functional languages generally, ever really gelled in my mind, the way, say, OO did. Algorithms expressed in functional form in LISP always seemed contorted from their natural form, to me. So, mostly I found LISP to be an awkward, "unscannable" language. I could write it, and read it, but it always felt a little like reading and writing a foreign language to me, not something in which my mind was native.
- baldfat 4y ago
  I am the exact opposite :) I started learning languages with Basic, Assembly and Fortran and ended up loving all things Lisp.

nealabq 4y ago

I'm only slightly younger than you, and, like you, have worked in many languages. And my very favorite were the LISPs (zeta, common, scheme). But the dev env, projects, and my time in life were all part of that positive experience. I was in my 20s (a super learning time) working on my own code on Symbolics Lisp machines. Fortran/Ratfor were my least favorite, since that work was always maintaining code written (and barely commented) by someone I didn't know. Smalltalk and Erlang are my next choices. Same reasons as LISP.

Qem 4y ago

> Unfortunately, Smalltalk arrived to too much hype before it's (potential) time, and was crippled as production language by it's image based development and deployment methodology. I was exposed to image based through Pharo, and I've found the idea to be awesome, as it allows very tight feedback loops on development. I see people complaining because it was nontrivial to extricate a finished program from the environment and ship it to customers in a "tamper-proof" opaque form. What puzzles me is why didn't Smalltalk play a bigger role on the ascension of free and open source software, given what was a bug for proprietary shops (hard to ship a opaque binary) is actually a feature for copyleft development (fully inspectable source code together with full development environment included by default). The GNU-Smalltalk development appears to be mostly stale. The torch of free smalltalk is carried most by Squeak and Pharo today.

igouy 4y ago
> … nontrivial to extricate a finished program from the environment and ship it to customers in a "tamper-proof" opaque form. 1) source code management Even ancient Smalltalk-80 provided — "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... 2) deployment Not all software was shrink-wrap — plenty of high-value enterprise software.
- walnutclosefarm 4y ago
  Smalltalk images were fine for one-person development of single programs. Not really very manageable for teams, and modular development though. Not that these things couldn't be done - we certainly did it at IBM, when SmallTalk was the "thing" there for a while - but it never was very satisfactory. A lot of developers significantly younger than me seem to think that source code control was developed in the the last couple of decades, but in fact we did source code control, modular development, and build pipelines way back in the 70s - mostly with home built tools, but the capabilities began to be built out as soon as source code left card decks for permanent residence and in place modification on rotating storage. And SmallTalk was at best hostile to all those techniques.