5 ms·

As a former professional Smalltalk developer, I would caution against the experience of greybeards who wax lyrical about the incredible power of Lisp and Smallt

As a former professional Smalltalk developer, I would caution against the experience of greybeards who wax lyrical about the incredible power of Lisp and Smalltalk, because even in their heyday that power was largely illusory. Firstly, anybody who encountered these environments early in their career will always be misty eyed about them. Secondly, ask them how big the team was they were working in and what the mechanism was they were using to deploy their programs. Smalltalk in particular is particularly difficult to package up into a deployable program that somebody else can run, and collaborating on development is fraught with code sharing issues you just don't get with less exciting environments like .NET or Python or Javascript/Node. In a modern context, Smalltalk and Lisp make little to no sense, especially when you have available a rich system of code being shared in more prosaic environments. It's a modern miracle that you can build what you need without re-inventing the wheel. There is no better time to be a programmer than now. Lisp and Smalltalk may well be great for reinventing wheels, for writing un-readable self modifying code and as a challenging intellectual exercise, but all your productivity just went out the window.

neilv 4y ago
Sounds like you're evaluating software configuration management for Smalltalk from before that was hardly a thing for any development platform? Decades ago, Smalltalk implementations would let you dump some part of a system (say, the part that held your application) to a human-readable ASCII file (which is pretty Git-able), and also load that. If you were using it today, while we're using Git, I can't think of a reason a Smalltalk system couldn't have more tight integration with Git. Regarding Lisps, I'm not sure which school of thought you're coming from, but there are multiple. To someone without firsthand experience, the things you might've heard someone say, like "Foo is great because code and date are the same darn thing", or "Foo is great because it's dynamic up the wazoo", not only aren't necessarily the strengths that others would claim, or they might not mean the same thing. For example, imagine some kinds of syntactic extension in Lisps, in which some region of syntax isn't a function call. The region is clearly delimited, and it has an identifier right there that can be looked up to tell you the behavior. Someone without experience with that, but who has used an unfortunate kind of "DSL" in some other language, or, worse, has experienced surprise "operator" overloading in a different language, or who's seen unfortunate choices of when to introduce languages and when not, might think this Lisps thing is more of the same thing, when it's not.
- Jtsummers 4y ago
  Pharo, at least, has very tight integration with git via Iceberg. Other variants have had (not from personal experience, only reading what others wrote) very good or at least decent (that is, no worse than the rest of industry) version control at least back to the 90s.
- smackeyacky 4y ago
  Envy/Developer was in heavy use where I worked, and it was pretty great but still nothing like the packagement management tools we now have. I'd say the change log in something like VisualWorks was definitely not git-able in any way that would facilitate merging of several developers code. In fact it was extremely difficult to keep images in sync without something like Envy/Developer. Lisp to me is like a fascinating fossil.
  - neilv 4y ago
    When I used ParcPlace Objectworks Smalltalk 4.1. and then VisualWorks Smalltalk in the early '90s, you'd use a menu item to write a human-readable ASCII serialization of some part of the system (not changelog) to the host filesystem. And it'd be diffable and mergeable and loadable. Doing Git with just that seems only a little different than what we'd do with a collection of source files today in some other language, including branches and merges. At the same time, one commercial site I worked at was doing its SCM for C code using kludge scripts over SCCS to an NFS volume. The next was putting C and C++ into Apollo DSEE and making SPARCstations jump through hoops to use that (because ancient DSEE on some Apollo DN10ks for SCM and CI/CD was better than the state of the art almost everyone else was using) and my advanced R&D group had just gotten DSEE-descendant Atria ClearCase for greenfield work in C++ from our Sun and HP workstations. The next site was using some dumpster fire of `.BAT` scripts over Perforce(?) for Windows NT-dominated C++ development. I'd say VisualWorks Smalltalk's wasn't the problem for team development at the time. The state of practice of everything else was more the problem.
  - User23 4y ago
    > Lisp to me is like a fascinating fossil. Evidently you have some experience with Smalltalk, but what makes you say that about Lisp? Also which Lisp exactly do you have in mind? To me the Lisp family of languages is more like Classical music: it doesn’t satisfy some modern sensibilities, but it has a timeless elegance and will be around long after the latest fad is gone.
protocontrol 4y ago
Although it's true that today it is easy for everyone to write, even those who have no experience or have had a disappointing experience, the effects of what they write are often not measurable. That is, it is easier to measure the resources needed to write than to measure its effects. Smalltalk is a tool for the creative spirit. It's a very powerful tool for those who have something inside and want to develop it. On the other hand, nowadays, the alternatives that are massively propagated have other characteristics. They are for those who feel better (or calmer) absorbing what someone else has done. They are for those who hide behind the phrase "it is better to ride on the shoulders of others" trying to show wisdom, but in reality revealing dependency and unproductivity. The problem with Smalltalk is that in computing, the "creative spirit" is a dying breed. Smalltalk is for the creative. Most think that creating is expensive and settle for copying (imitating) or using (claiming to re-use!). Whoever thinks someone has something to contribute, let him use a Smalltalk, whoever doesn't, let him buy the latest.
- smackeyacky 4y ago
  Contribute to what? If you have something that is fundamentally difficult to share (like a Smalltalk image) what are you contributing to other than entropy?
  - igouy 4y ago
    The Smalltalk image is just a file, so that's not that difficult to share? Maybe you mean the Smalltalk code that's been "saved" as part of the Smalltalk image snapshot? In which case, why wouldn't we export the Smalltalk code from the image and share those source code files?
    - smackeyacky 4y ago
      Because poor Smalltalkers often extend stupid things like "Object" and none of their code will run on your image without finding all the changes they made. So you either try to file out your own changes and merge into somebody elses image, or try to extract theirs for your image. I realise the state of the art must have moved on since the 1990s but change files back then were a constant source of problems along with how you deploy your image once you are happy with it. Contrast that with pip or npm. Once I've built my requirements.txt or whatever, I have not only solved how to share my environment with my collaborators, I can use it to build a Docker container and also solve my deployment dependencies. Smalltalk: play whack-a-mole with change sets until it looks like it's working then strip the image of unwanted stuff and hope it still works. It's caveman stuff.
rscho 4y ago
> Lisp and Smalltalk may well be great for reinventing wheels, for writing un-readable self modifying code and as a challenging intellectual exercise, but all your productivity just went out the window. This assessment seems very unfair to the current environments of both languages. Perhaps you ought to delve in a second time?
mtlmtlmtlmtl 4y ago
This is a very insightful comment, thank you. I have much the same experience from the Lisp of side of things. I will say though, these languages have their niches where they really shine. The oft understated power of Lisp is in creating software that is infinitely configurable assuming you know a bit of Lisp. Extensions are a first class citizen in Lisp programs. The configuration is just some lisp code that's compiled into the running program upon loading. The config can even redefine existing functions. One time I used the config file to fix an actual bug in a program that was abandoned by the maintainer. Of course, only programmers want this functionality, and so its usefulness is limited to things like Emacs. But it still has its place.
skissane 4y ago
> especially when you have available a rich system of code being shared in more prosaic environments I don't think this is as big an issue as you think it is. You can find a number of Lisp family language implementations which compile to JVM bytecode, .Net bytecode, or JavaScript – Clojure, ClojureCLR and ClojureScript are the most notable and active (even if Clojure is somewhat of an unorthodox Lisp), but there are others (such as Armed Bear Common Lisp, ABCL). So you can write your Lisp code, and easily consume those massive library ecosystems. Similarly, Smalltalk has PharoJS, and I know there have been ports of Smalltalk to JVM and .Net too (although I don't think they've been as successful). Technologies for in-process multiple language integration, such as FFI libraries, have greatly improved over the last 10–20 years. Mixing code from different languages is easier than it ever was in the past, and there are further improvements on the horizon (for example, in Java, the planned replacement of JNI with the FFM API). I think WebAssembly is really exciting – especially if they improve the WebAssembly-JavaScript integration story, which I know they are working on. Compile whatever language you like to WebAssembly, and then you have full access to the JavaScript library ecosystem; and an improved WebAssembly-JavaScript integration will likely also help simplify cross-language integration between different languages targeting WebAssembly. We have an abundant choice of technologies for inter-process/inter-machine cross-language code integration – everything from relatively modern approaches such as REST, GraphQL, gRPC, Thrift, through to more old-fashioned approaches such as SOAP, CORBA, DCOM, etc. With the rise of micro-services, server-less, etc, it is easier than it ever was to build an application containing a mix of services in different languages. Few care if your app is composed of two or three or four different containers, and even fewer care if the code in those containers is written in different languages.
travisgriggs 4y ago
Interesting. I did 20 years of professional Smalltalk development as well, 6 years at Cincom. This coming Wednesday will mark 10 years out of the balloon, wandering in the wilderness as a polyglot. My conclusions are not the same as yours. Smalltalk was (for me) unparalleled at modelling things, including its own self (pun?). I think it also thrived in an era where a high percentage of the programming population pursued it as a form of mastery. The percentage of people that still program with some sort of mastery of the art is much lower now (to wit, I think there are more of them total, but less as a percentage). Working with the stack of internet technologies is like becoming a city planning engineer, a little bit of engineering, a whole lot byzantine rules and policies to navigate, jobs creation program itself in the number of "specialties" that need to be mastered to assemble anything. I left Smalltalk, because the number of places I could advocate its use was shrinking. Desktop was dying. There's not a lot of technologies for browser delivered programming where going outside of the mainstream is worth the impedance mismatch it causes. And when it comes to handhelds, the hardware vendors have cobbled such an oligarchy of "use our approved/supported technologies" that it's rarely worth it bucking the idiomatic trends. All mainstream code movements live and die on the blessing of iOS, Android, or the browser(s). There's a small remainder of competitive evolution that goes on in the server space, but not a lot. Node may be more modern than Fortran, but half of the basic programs running on the backside are simple enough it doesn't really matter what you write them in, you could write them in Fortran or Basic. I miss Smalltalk's simplicity. I miss Smalltalk's block closures: sure did make ad hoc functional program easy. I miss Smalltalk's very nicely balanced syntax: kind of code like, but also uncannily natural language at times. I miss Smalltalk's ability to try and see code and code artifacts as something other than text files. I miss Smalltalk's code navigation and execution tools. Once Smalltalk became a commercial offering, with the need to support and maintain an installed base, it quit changing. Any vestiges of Smalltalk today, are basically Smalltalk-80+. For Smalltalk to "go on", they (we) needed to "burn the disk pack" again. For me, the ultimate modern language would look something like Smalltalkish syntax and IDE, with Elixir/Erlang like execution semantics, but retaining a strong object/class declaration story (instead of let's pretend dictionaries are structures), and a namespace story somewhat akin to Python (but without the shadow binding behavior), and VM extensibility story similar to Smalltalk\X (unlike other Smalltalks which always ran into a <primitive> when you got to the "performance" parts, Smalltalk\X just supported inline C extensions, so you could just optimize right in place, no JNI/FFI two worlds nonsense). And a world where delivery vendors (browsers, handhelds, etc) had an incentive to simplify program development instead of maintain status quos. Smalltalk deployment was a PITA compared to compiling a command line tool from C, it was improving, but slowely. Ironically, compared to docker images and microservices and kubernetes and everything else that goes into any "complicated" program to deploy now days, Smalltalk was a breeze.
didibus 4y ago
> ask them how big the team was they were working What team today is bigger than 10 developer? Where I work dev teams are between 4 to 12 devs at max, most common around 7-8 developers. So you really don't need a language to support more than that, and if LISP or Smalltalk lets you be faster at that scale it's perfect.
divs1210 4y ago
I have used Clojure professionally at several companies, and can confidently say that you will find libraries for everything. Common Lisp/Scheme on the other hand are pretty bad in that regard, and only iseful for hobby stuff.
- dagw 4y ago
  I have used Clojure professionally at several companies, and can confidently say that you will find libraries for everything. Actual Clojure libraries or by wrapping Java libraries?
  - divs1210 4y ago
    Both - libraries written in Clojure and wrapped versions of Java libraries. And because Java interop is pretty good, you can use Java libraries directly from Clojure as well. I have written REST servers, data stream processing pipelines, hadoop jobs, react-based frontends, mobile apps, etc. in Clojure.

neilv 4y ago

Sounds like you're evaluating software configuration management for Smalltalk from before that was hardly a thing for any development platform? Decades ago, Smalltalk implementations would let you dump some part of a system (say, the part that held your application) to a human-readable ASCII file (which is pretty Git-able), and also load that. If you were using it today, while we're using Git, I can't think of a reason a Smalltalk system couldn't have more tight integration with Git. Regarding Lisps, I'm not sure which school of thought you're coming from, but there are multiple. To someone without firsthand experience, the things you might've heard someone say, like "Foo is great because code and date are the same darn thing", or "Foo is great because it's dynamic up the wazoo", not only aren't necessarily the strengths that others would claim, or they might not mean the same thing. For example, imagine some kinds of syntactic extension in Lisps, in which some region of syntax isn't a function call. The region is clearly delimited, and it has an identifier right there that can be looked up to tell you the behavior. Someone without experience with that, but who has used an unfortunate kind of "DSL" in some other language, or, worse, has experienced surprise "operator" overloading in a different language, or who's seen unfortunate choices of when to introduce languages and when not, might think this Lisps thing is more of the same thing, when it's not.

Jtsummers 4y ago
Pharo, at least, has very tight integration with git via Iceberg. Other variants have had (not from personal experience, only reading what others wrote) very good or at least decent (that is, no worse than the rest of industry) version control at least back to the 90s.
smackeyacky 4y ago
Envy/Developer was in heavy use where I worked, and it was pretty great but still nothing like the packagement management tools we now have. I'd say the change log in something like VisualWorks was definitely not git-able in any way that would facilitate merging of several developers code. In fact it was extremely difficult to keep images in sync without something like Envy/Developer. Lisp to me is like a fascinating fossil.
- neilv 4y ago
  When I used ParcPlace Objectworks Smalltalk 4.1. and then VisualWorks Smalltalk in the early '90s, you'd use a menu item to write a human-readable ASCII serialization of some part of the system (not changelog) to the host filesystem. And it'd be diffable and mergeable and loadable. Doing Git with just that seems only a little different than what we'd do with a collection of source files today in some other language, including branches and merges. At the same time, one commercial site I worked at was doing its SCM for C code using kludge scripts over SCCS to an NFS volume. The next was putting C and C++ into Apollo DSEE and making SPARCstations jump through hoops to use that (because ancient DSEE on some Apollo DN10ks for SCM and CI/CD was better than the state of the art almost everyone else was using) and my advanced R&D group had just gotten DSEE-descendant Atria ClearCase for greenfield work in C++ from our Sun and HP workstations. The next site was using some dumpster fire of `.BAT` scripts over Perforce(?) for Windows NT-dominated C++ development. I'd say VisualWorks Smalltalk's wasn't the problem for team development at the time. The state of practice of everything else was more the problem.
- User23 4y ago
  > Lisp to me is like a fascinating fossil. Evidently you have some experience with Smalltalk, but what makes you say that about Lisp? Also which Lisp exactly do you have in mind? To me the Lisp family of languages is more like Classical music: it doesn’t satisfy some modern sensibilities, but it has a timeless elegance and will be around long after the latest fad is gone.

protocontrol 4y ago

Although it's true that today it is easy for everyone to write, even those who have no experience or have had a disappointing experience, the effects of what they write are often not measurable. That is, it is easier to measure the resources needed to write than to measure its effects. Smalltalk is a tool for the creative spirit. It's a very powerful tool for those who have something inside and want to develop it. On the other hand, nowadays, the alternatives that are massively propagated have other characteristics. They are for those who feel better (or calmer) absorbing what someone else has done. They are for those who hide behind the phrase "it is better to ride on the shoulders of others" trying to show wisdom, but in reality revealing dependency and unproductivity. The problem with Smalltalk is that in computing, the "creative spirit" is a dying breed. Smalltalk is for the creative. Most think that creating is expensive and settle for copying (imitating) or using (claiming to re-use!). Whoever thinks someone has something to contribute, let him use a Smalltalk, whoever doesn't, let him buy the latest.

smackeyacky 4y ago
Contribute to what? If you have something that is fundamentally difficult to share (like a Smalltalk image) what are you contributing to other than entropy?
- igouy 4y ago
  The Smalltalk image is just a file, so that's not that difficult to share? Maybe you mean the Smalltalk code that's been "saved" as part of the Smalltalk image snapshot? In which case, why wouldn't we export the Smalltalk code from the image and share those source code files?
  - smackeyacky 4y ago
    Because poor Smalltalkers often extend stupid things like "Object" and none of their code will run on your image without finding all the changes they made. So you either try to file out your own changes and merge into somebody elses image, or try to extract theirs for your image. I realise the state of the art must have moved on since the 1990s but change files back then were a constant source of problems along with how you deploy your image once you are happy with it. Contrast that with pip or npm. Once I've built my requirements.txt or whatever, I have not only solved how to share my environment with my collaborators, I can use it to build a Docker container and also solve my deployment dependencies. Smalltalk: play whack-a-mole with change sets until it looks like it's working then strip the image of unwanted stuff and hope it still works. It's caveman stuff.

rscho 4y ago

> Lisp and Smalltalk may well be great for reinventing wheels, for writing un-readable self modifying code and as a challenging intellectual exercise, but all your productivity just went out the window. This assessment seems very unfair to the current environments of both languages. Perhaps you ought to delve in a second time?

mtlmtlmtlmtl 4y ago

This is a very insightful comment, thank you. I have much the same experience from the Lisp of side of things. I will say though, these languages have their niches where they really shine. The oft understated power of Lisp is in creating software that is infinitely configurable assuming you know a bit of Lisp. Extensions are a first class citizen in Lisp programs. The configuration is just some lisp code that's compiled into the running program upon loading. The config can even redefine existing functions. One time I used the config file to fix an actual bug in a program that was abandoned by the maintainer. Of course, only programmers want this functionality, and so its usefulness is limited to things like Emacs. But it still has its place.

skissane 4y ago

> especially when you have available a rich system of code being shared in more prosaic environments I don't think this is as big an issue as you think it is. You can find a number of Lisp family language implementations which compile to JVM bytecode, .Net bytecode, or JavaScript – Clojure, ClojureCLR and ClojureScript are the most notable and active (even if Clojure is somewhat of an unorthodox Lisp), but there are others (such as Armed Bear Common Lisp, ABCL). So you can write your Lisp code, and easily consume those massive library ecosystems. Similarly, Smalltalk has PharoJS, and I know there have been ports of Smalltalk to JVM and .Net too (although I don't think they've been as successful). Technologies for in-process multiple language integration, such as FFI libraries, have greatly improved over the last 10–20 years. Mixing code from different languages is easier than it ever was in the past, and there are further improvements on the horizon (for example, in Java, the planned replacement of JNI with the FFM API). I think WebAssembly is really exciting – especially if they improve the WebAssembly-JavaScript integration story, which I know they are working on. Compile whatever language you like to WebAssembly, and then you have full access to the JavaScript library ecosystem; and an improved WebAssembly-JavaScript integration will likely also help simplify cross-language integration between different languages targeting WebAssembly. We have an abundant choice of technologies for inter-process/inter-machine cross-language code integration – everything from relatively modern approaches such as REST, GraphQL, gRPC, Thrift, through to more old-fashioned approaches such as SOAP, CORBA, DCOM, etc. With the rise of micro-services, server-less, etc, it is easier than it ever was to build an application containing a mix of services in different languages. Few care if your app is composed of two or three or four different containers, and even fewer care if the code in those containers is written in different languages.

travisgriggs 4y ago

Interesting. I did 20 years of professional Smalltalk development as well, 6 years at Cincom. This coming Wednesday will mark 10 years out of the balloon, wandering in the wilderness as a polyglot. My conclusions are not the same as yours. Smalltalk was (for me) unparalleled at modelling things, including its own self (pun?). I think it also thrived in an era where a high percentage of the programming population pursued it as a form of mastery. The percentage of people that still program with some sort of mastery of the art is much lower now (to wit, I think there are more of them total, but less as a percentage). Working with the stack of internet technologies is like becoming a city planning engineer, a little bit of engineering, a whole lot byzantine rules and policies to navigate, jobs creation program itself in the number of "specialties" that need to be mastered to assemble anything. I left Smalltalk, because the number of places I could advocate its use was shrinking. Desktop was dying. There's not a lot of technologies for browser delivered programming where going outside of the mainstream is worth the impedance mismatch it causes. And when it comes to handhelds, the hardware vendors have cobbled such an oligarchy of "use our approved/supported technologies" that it's rarely worth it bucking the idiomatic trends. All mainstream code movements live and die on the blessing of iOS, Android, or the browser(s). There's a small remainder of competitive evolution that goes on in the server space, but not a lot. Node may be more modern than Fortran, but half of the basic programs running on the backside are simple enough it doesn't really matter what you write them in, you could write them in Fortran or Basic. I miss Smalltalk's simplicity. I miss Smalltalk's block closures: sure did make ad hoc functional program easy. I miss Smalltalk's very nicely balanced syntax: kind of code like, but also uncannily natural language at times. I miss Smalltalk's ability to try and see code and code artifacts as something other than text files. I miss Smalltalk's code navigation and execution tools. Once Smalltalk became a commercial offering, with the need to support and maintain an installed base, it quit changing. Any vestiges of Smalltalk today, are basically Smalltalk-80+. For Smalltalk to "go on", they (we) needed to "burn the disk pack" again. For me, the ultimate modern language would look something like Smalltalkish syntax and IDE, with Elixir/Erlang like execution semantics, but retaining a strong object/class declaration story (instead of let's pretend dictionaries are structures), and a namespace story somewhat akin to Python (but without the shadow binding behavior), and VM extensibility story similar to Smalltalk\X (unlike other Smalltalks which always ran into a <primitive> when you got to the "performance" parts, Smalltalk\X just supported inline C extensions, so you could just optimize right in place, no JNI/FFI two worlds nonsense). And a world where delivery vendors (browsers, handhelds, etc) had an incentive to simplify program development instead of maintain status quos. Smalltalk deployment was a PITA compared to compiling a command line tool from C, it was improving, but slowely. Ironically, compared to docker images and microservices and kubernetes and everything else that goes into any "complicated" program to deploy now days, Smalltalk was a breeze.

didibus 4y ago

> ask them how big the team was they were working What team today is bigger than 10 developer? Where I work dev teams are between 4 to 12 devs at max, most common around 7-8 developers. So you really don't need a language to support more than that, and if LISP or Smalltalk lets you be faster at that scale it's perfect.

divs1210 4y ago

I have used Clojure professionally at several companies, and can confidently say that you will find libraries for everything. Common Lisp/Scheme on the other hand are pretty bad in that regard, and only iseful for hobby stuff.

dagw 4y ago
I have used Clojure professionally at several companies, and can confidently say that you will find libraries for everything. Actual Clojure libraries or by wrapping Java libraries?
- divs1210 4y ago
  Both - libraries written in Clojure and wrapped versions of Java libraries. And because Java interop is pretty good, you can use Java libraries directly from Clojure as well. I have written REST servers, data stream processing pipelines, hadoop jobs, react-based frontends, mobile apps, etc. in Clojure.