This is something I try, over and over, to explain to people, and I’ve never, ever succeeded in doing it in print or a talk. I always get a response along the lines of, “oh yeah, I love TDD, that’s how I write [OCaml/Go/C#/whatever],” and that’s effectively the end of the conversation on their end: “neat, this guy likes Smalltalk because it has really good TDD”, is about all they hear, and the rest washes off like tears in rain.
“Experiencing Smalltalk” is a great title for an article like this because you really need to actually experience it, ideally using it yourself, to get it. Smalltalk the language is…fine. It gets a lot right, it gets a lot wrong, languages like Self and Slate have tried to improve it, but at any rate, it gets the job done with minimal fuss. People who just look at its syntax and semantics are right in 2021 that many other languages deliver the same or better.
But that misses the point. The thing that differentiates Smalltalk is its entire development flow, which is radically different from literally anything else I’ve ever used: write broken code, run it, repeatedly fix the code as you slowly walk through methods and whole classes that either didn’t work or didn’t even exist when you initiated the execution, and end up with a working spike that had its first successful run the second you’re done writing the last line of code. A very few languages, like Factor and Common Lisp, come very close, but as of 2021, Smalltalk is the only environment I’ve ever used that still delivers it.[1]
I don’t write Smalltalk anymore, and I don’t see that changing (mostly just because I’m old and have kids and spend what little time I do coding for fun on things like Factor), but the experience of developing in it remains absolutely without peer.
[1]: I’ve been told that the actual Lisp Machines of the 80s did have this same flow, but I’ve never used one–and I definitely don’t think SBCL in 2021 matches the dev flow of Pharo or Squeak Smalltalk.
The thing that differentiates Smalltalk is its entire development flow, which is radically different from literally anything else I’ve ever used: write broken code, run it, repeatedly fix the code as you slowly walk through methods and whole classes that either didn’t work or didn’t even exist when you initiated the execution, and end up with a working spike that had its first successful run the second you’re done writing the last line of code.
This describes my experience writing Emacs pretty closely. However, I know that many people who know Emacs intimately still say that Smalltalk is different, so I have to conclude that there’s more to it, and that it’s just very difficult to describe what exactly the difference is in words. I expect it has to do with a more seamlessly integrated debugger that reifies the call stack and things. I suppose there’s only one way to really find out.
While I agree with the ideas presented here, in particular the comments on IDEs (or as I like to call them, Interactive Computing Environments, to avoid confusion with “regular” IDEs), I do wonder why these ideas keep getting forgotten. We had Smalltalk, we had Lisp Machines and we have Unix shells, but the tendency always seems to go towards a rigid cookie-cutter-style of programming. I don’t like the idea that people are “too stupid” to understand or use it, and I don’t know how much of it is just that people were used to whatever reached the market first, no matter how annoying it is and how much time people spend fighting it. One component is certainly external (often proprietary) dependencies. Or is it education that de-prioritizes these kinds of thinking?
There are two issues, in my opinion, both shaped by own experience using Smalltalk and trying to teach it to others.
The first is that you can’t get a flow like the one in this article without learning new tooling on top of the language, and that ends up being a big issue. If I know Emacs (or Visual Studio Code, or Vim, or any of the even vaguely extensible editors), I can use that same tool to handle basically every language, focusing just on the new language. To get a good flow in Smalltalk (or, I believe, a Lisp machine, but notably not contemporary Common Lisp or Schemes), you have to learn the IDE. In Smalltalk, this is especially bad, because the traditional dev flow effectively uses a source database instead of source files, so (until recently) you couldn’t even use things like diff or git.
The second thing is that this kind of dev flow, in my experience, thrives when you’re doing something novel. Nowadays, most dev work I do is “just” assembling tons of existing libraries in familiar patterns. That’s not a problem, and I don’t think it’s laziness; it’s about predictability and repeatability, and I mostly view it as a sign that the industry is maturing. It lets me do much more with much less effort and much lower risk than doing everything bespoke. But it does mean that if, for example, I want to write a Smalltalk backend for a website in 2021, I’m going to have to write a bunch of stuff (e.g., OAuth connectors, AWS APIs, possibly DB drivers, etc.) that I’d get for free in virtually any other language, which in turn are new places things can go wrong, where I won’t be able to ask or pay someone else for support, and which likely don’t have anything to do with making my software sell. This applies pretty intense brakes to using novel environments even if you believe you’d be happier in one. This is basically the same as your point on external dependencies, but I think looking at it one step back from a repeatability and reliability perspective makes it more obvious why it’s such an issue.
As someone who has dabbled in Common Lisp w/ SLIME, another limitation of that development style I have noticed is keeping track of state and making sure things are reproducible from the code, and not some unreachable state you have arrived at from mutating things in the REPL. There is a similar issue with Jupyter notebooks
In Smalltalk, this is especially bad, because the traditional dev flow effectively uses a source database instead of source files, so (until recently) you couldn’t even use things like diff or git.
While I certainly agree with the lamentations on using modern VCS tools – ten years ago, I spent four months writing a tool that could split a single multi-megabyte XML source database configuration file into multiple files for more atomic versioning and review and combine those files for deployments — I feel like the file paradigm is one that advanced IDE users may be OK abstracting away. I use IntelliJ and other JetBrains products, and Eclipse before them, that have “search by symbol” features, generally used to search by a class, object, trait, interface, etc. name. There are some projects I’ve worked on where the only time I really have to care about files is when I identify the need to create a new package or module necessitating a new directory. Otherwise, my IDE handles the files almost entirely as an abstraction.
This was difficult to wrap my head around it but because of my experience with Smalltalk in college, I understood it more quickly than my peers and it accelerated my development productivity by a little bit. I’ll readily admit that I’m slower on file-based IDEs or text editors without some kind of fuzzy finder (I’ve been using Elementary Code in a VM for one project and dreadfully missing CtrlP or the like) but it is my preference to treat encapsulated code as an object instead of as a file. I think if more people preferred this, and Smalltalk would have been more popular for other reasons, perhaps a solid VCS for source databases may have emerged; one that didn’t rely on disaggregating the database into the filesystem paradigm.
I feel like the file paradigm is one that advanced IDE users may be OK abstracting away. I use IntelliJ and other JetBrains products, and Eclipse before them, that have “search by symbol” features, generally used to search by a class, object, trait, interface, etc. name. There are some projects I’ve worked on where the only time I really have to care about files is when I identify the need to create a new package or module necessitating a new directory.
While it’s true that individual users might be OK with this, there’s two factors to consider. One is that you operate with the knowledge that when your tools do stop working, you can always drop down a level to the “real” files to find out what’s actually going on. The second is that you can collaborate with others who use Vim and Emacs; your choice to use IntelliJ does not force your teammates to adopt your same tools.
I’m going to have to write a bunch of stuff (e.g., OAuth connectors, AWS APIs, possibly DB drivers, etc.) that I’d get for free in virtually any other language
Those seem to be largely available in Pharo via existing libraries e.g.:
I don’t think that’s the right question. The right question is whether these things have an SDK that is easy to use from Smalltalk. Unfortunately the answer is still ‘no’. Even in Smalltalks that have a way of calling other languages, the integration is usually painful because the Smalltalk image abstraction doesn’t play nicely with the idea that some state exists outside of the image.
I don’t think that being object-based is necessary – it makes it cleaner and more efficient. Following this article, you do have a dialogue with the computer (even if it is rather simple), users can and do modify their environment (shell and PATH) and in the end, it is simple, perhaps too simple.
I claim that being object-based is “necessary” in the sense that you’re meaningfully far away from the Smalltalk ideal if your system is built around text. Obviously, there’s a gradient, not a discrete transition, but being object-oriented is one of the major factors.
Additionally, Unix (shells) is dis-integrated, both in ideals and in implementation. Another major design decision of Lisp/Smalltalk is integration between components - something the Unix philosophy explicitly spurns.
I think different tools are just good at different jobs. I don’t write in-the-large network services in Smalltalk just like I don’t write tax filing products in spreadsheets.
This is not to say that Smalltalk or spreadsheets are less – far from it! If I want to bang out a business projection I don’t reach for Rails or Haskell or Rust, I grab a spreadsheet. I think there are similarly many situations where something more Smalltalk-like is the ideal tool, but your day-job as a programmer in tech is not full of those situations and we haven’t given enough knowledge of what computers are capable of to those who would use computing as a tool for their own ends.
Also, OP - if you have not seen this great video with Bob Taylor, I highly recommend it. Interview contains bits about some of the people chronicled in “The Dream Machine”.
Just build a CLI app before GUI. Its the Unix way of REPL / TDD I feel.
I’ve never felt “happy” or “productive” with lisp and smalltalk. I do like lisp because it allows you to compose long expressions in the middle and you kinda get used to the prefix notation because there is less to remember.
This is something I try, over and over, to explain to people, and I’ve never, ever succeeded in doing it in print or a talk. I always get a response along the lines of, “oh yeah, I love TDD, that’s how I write [OCaml/Go/C#/whatever],” and that’s effectively the end of the conversation on their end: “neat, this guy likes Smalltalk because it has really good TDD”, is about all they hear, and the rest washes off like tears in rain.
“Experiencing Smalltalk” is a great title for an article like this because you really need to actually experience it, ideally using it yourself, to get it. Smalltalk the language is…fine. It gets a lot right, it gets a lot wrong, languages like Self and Slate have tried to improve it, but at any rate, it gets the job done with minimal fuss. People who just look at its syntax and semantics are right in 2021 that many other languages deliver the same or better.
But that misses the point. The thing that differentiates Smalltalk is its entire development flow, which is radically different from literally anything else I’ve ever used: write broken code, run it, repeatedly fix the code as you slowly walk through methods and whole classes that either didn’t work or didn’t even exist when you initiated the execution, and end up with a working spike that had its first successful run the second you’re done writing the last line of code. A very few languages, like Factor and Common Lisp, come very close, but as of 2021, Smalltalk is the only environment I’ve ever used that still delivers it.[1]
I don’t write Smalltalk anymore, and I don’t see that changing (mostly just because I’m old and have kids and spend what little time I do coding for fun on things like Factor), but the experience of developing in it remains absolutely without peer.
[1]: I’ve been told that the actual Lisp Machines of the 80s did have this same flow, but I’ve never used one–and I definitely don’t think SBCL in 2021 matches the dev flow of Pharo or Squeak Smalltalk.
This describes my experience writing Emacs pretty closely. However, I know that many people who know Emacs intimately still say that Smalltalk is different, so I have to conclude that there’s more to it, and that it’s just very difficult to describe what exactly the difference is in words. I expect it has to do with a more seamlessly integrated debugger that reifies the call stack and things. I suppose there’s only one way to really find out.
While I agree with the ideas presented here, in particular the comments on IDEs (or as I like to call them, Interactive Computing Environments, to avoid confusion with “regular” IDEs), I do wonder why these ideas keep getting forgotten. We had Smalltalk, we had Lisp Machines and we have Unix shells, but the tendency always seems to go towards a rigid cookie-cutter-style of programming. I don’t like the idea that people are “too stupid” to understand or use it, and I don’t know how much of it is just that people were used to whatever reached the market first, no matter how annoying it is and how much time people spend fighting it. One component is certainly external (often proprietary) dependencies. Or is it education that de-prioritizes these kinds of thinking?
It’s the insistence on doing everything via text.
There are two issues, in my opinion, both shaped by own experience using Smalltalk and trying to teach it to others.
The first is that you can’t get a flow like the one in this article without learning new tooling on top of the language, and that ends up being a big issue. If I know Emacs (or Visual Studio Code, or Vim, or any of the even vaguely extensible editors), I can use that same tool to handle basically every language, focusing just on the new language. To get a good flow in Smalltalk (or, I believe, a Lisp machine, but notably not contemporary Common Lisp or Schemes), you have to learn the IDE. In Smalltalk, this is especially bad, because the traditional dev flow effectively uses a source database instead of source files, so (until recently) you couldn’t even use things like
difforgit.The second thing is that this kind of dev flow, in my experience, thrives when you’re doing something novel. Nowadays, most dev work I do is “just” assembling tons of existing libraries in familiar patterns. That’s not a problem, and I don’t think it’s laziness; it’s about predictability and repeatability, and I mostly view it as a sign that the industry is maturing. It lets me do much more with much less effort and much lower risk than doing everything bespoke. But it does mean that if, for example, I want to write a Smalltalk backend for a website in 2021, I’m going to have to write a bunch of stuff (e.g., OAuth connectors, AWS APIs, possibly DB drivers, etc.) that I’d get for free in virtually any other language, which in turn are new places things can go wrong, where I won’t be able to ask or pay someone else for support, and which likely don’t have anything to do with making my software sell. This applies pretty intense brakes to using novel environments even if you believe you’d be happier in one. This is basically the same as your point on external dependencies, but I think looking at it one step back from a repeatability and reliability perspective makes it more obvious why it’s such an issue.
As someone who has dabbled in Common Lisp w/ SLIME, another limitation of that development style I have noticed is keeping track of state and making sure things are reproducible from the code, and not some unreachable state you have arrived at from mutating things in the REPL. There is a similar issue with Jupyter notebooks
While I certainly agree with the lamentations on using modern VCS tools – ten years ago, I spent four months writing a tool that could split a single multi-megabyte XML source database configuration file into multiple files for more atomic versioning and review and combine those files for deployments — I feel like the file paradigm is one that advanced IDE users may be OK abstracting away. I use IntelliJ and other JetBrains products, and Eclipse before them, that have “search by symbol” features, generally used to search by a class, object, trait, interface, etc. name. There are some projects I’ve worked on where the only time I really have to care about files is when I identify the need to create a new package or module necessitating a new directory. Otherwise, my IDE handles the files almost entirely as an abstraction.
This was difficult to wrap my head around it but because of my experience with Smalltalk in college, I understood it more quickly than my peers and it accelerated my development productivity by a little bit. I’ll readily admit that I’m slower on file-based IDEs or text editors without some kind of fuzzy finder (I’ve been using Elementary Code in a VM for one project and dreadfully missing CtrlP or the like) but it is my preference to treat encapsulated code as an object instead of as a file. I think if more people preferred this, and Smalltalk would have been more popular for other reasons, perhaps a solid VCS for source databases may have emerged; one that didn’t rely on disaggregating the database into the filesystem paradigm.
While it’s true that individual users might be OK with this, there’s two factors to consider. One is that you operate with the knowledge that when your tools do stop working, you can always drop down a level to the “real” files to find out what’s actually going on. The second is that you can collaborate with others who use Vim and Emacs; your choice to use IntelliJ does not force your teammates to adopt your same tools.
Those seem to be largely available in Pharo via existing libraries e.g.:
Here’s a quick reality check, using two examples that have come up in my own work:
Does PayPal have an official SDK for Smalltalk?
Is there a Smalltalk version of the AWS Encryption SDK?
Spoiler: The answer to both is no.
I don’t think that’s the right question. The right question is whether these things have an SDK that is easy to use from Smalltalk. Unfortunately the answer is still ‘no’. Even in Smalltalks that have a way of calling other languages, the integration is usually painful because the Smalltalk image abstraction doesn’t play nicely with the idea that some state exists outside of the image.
One of these is not like the others.
PowerShell is closer due to being object-based, but it’s still very clunky.
I don’t think that being object-based is necessary – it makes it cleaner and more efficient. Following this article, you do have a dialogue with the computer (even if it is rather simple), users can and do modify their environment (shell and
PATH) and in the end, it is simple, perhaps too simple.I claim that being object-based is “necessary” in the sense that you’re meaningfully far away from the Smalltalk ideal if your system is built around text. Obviously, there’s a gradient, not a discrete transition, but being object-oriented is one of the major factors.
Additionally, Unix (shells) is dis-integrated, both in ideals and in implementation. Another major design decision of Lisp/Smalltalk is integration between components - something the Unix philosophy explicitly spurns.
I think different tools are just good at different jobs. I don’t write in-the-large network services in Smalltalk just like I don’t write tax filing products in spreadsheets.
This is not to say that Smalltalk or spreadsheets are less – far from it! If I want to bang out a business projection I don’t reach for Rails or Haskell or Rust, I grab a spreadsheet. I think there are similarly many situations where something more Smalltalk-like is the ideal tool, but your day-job as a programmer in tech is not full of those situations and we haven’t given enough knowledge of what computers are capable of to those who would use computing as a tool for their own ends.
OT but that’s a really nicely designed site
The Day 5 code gist got blocked in Firefox for me. Here’s the gist if anyone has/had same issue: https://github.com/nikhilm/AdventOfCode2020/blob/master/AdventOfCode-Tests/Day5Test.class.st
Also, OP - if you have not seen this great video with Bob Taylor, I highly recommend it. Interview contains bits about some of the people chronicled in “The Dream Machine”.
If I’m reading the Pharo Discord correctly, Pharo 9 could be coming in April, and it will have an ARM64 version.
I feel this way with Unix stuff.
I’ve never felt “happy” or “productive” with lisp and smalltalk. I do like lisp because it allows you to compose long expressions in the middle and you kinda get used to the prefix notation because there is less to remember.