4 ms·

I've often heard two statements online from older programmers. "Delphi/TurboPascal was the peak of developer productivity" And "Smalltalk was the peak of

I've often heard two statements online from older programmers. "Delphi/TurboPascal was the peak of developer productivity" And "Smalltalk was the peak of developer productivity" I've only been programming about a decade so both of those languages were long before my time. Can anyone who has experience programming in Smalltalk share what was so special about it/what made it so productive to write programs in versus other languages? It seems like this unique playground-VM thing makes it sort of unwieldy for non-graphical tools. IE can you use it for scripting tasks system, or for writing networked applications? There must be something unique about Smalltalk for so many of it's developers to reminisce about it and claim it's been unparalleled since.

AceJohnny2 5y ago
It's a very noisy datapoint, but compare performance VW Smalltalk to NodeJS: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/smalltalk.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... VW Smalltalk is between 2x and 27x times slower than Javascript. And Pharo is slower yet than VW Smalltalk: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-pharo.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Nevertheless, as the front page the the Benchmarks Game is careful to mention, benchmark performance is 1) not necessarily representative of real-world performance and 2) not even always important in the greater context! Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. What would our world look like if Brendan Eich had gone for Smalltalk instead of creating a language from scratch?
- jhgb 5y ago
  > Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. Well...if you consider that the heritage of V8 in Node.js kind of goes back to StrongTalk, I'd say Smalltalk has received more of it than perhaps many people think. Unfortunately StrongTalk didn't really succeed on the market for the same reasons as many other Smalltalk implementations - proprietary nature and exclusivity doesn't really help you in the long run against worse-but-cheaper-and-more-accessible solutions.
- Qem 5y ago
  Those benchmarks are quite old, from Pharo 5 in 2017. It would be interesting to see a updated version. Eliot Miranda and Clément Béra are working on speculative inlining for the JIT compiler. From http://www.mirandabanda.org/cogblog/about-cog/ http://www.mirandabanda.org/cogblog/about-cog/ - "With Clément Béra I’m working on adaptive optimisation (a.k.a. speculative inlining) at the image level, optimising from bytecode to bytecode. We call this project Sista, which stands for Speculative Inlining Smalltalk Architecture. Clément’s image-level (entirely in Smalltalk above the virtual machine) adaptive optimizer is called Scorch. Sista should offer about a -66% speed-up (3x) for conventional Smalltalk code. The combination of Spur and Sista should yield almost a 5x speedup over the original Cog."
  - igouy 5y ago
    > Pharo 5 in 2017 Seems to be tagged 2020 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM] The pharo.version file contains — 80
    - Qem 5y ago
      I'm sorry. You're right. I did a stupid mistake by confounding the vm version with Pharo version. I can't edit my post anymore, but please, anyone reading this, disregard the "Those benchmarks are quite old, from Pharo 5 in 2017" part.
      - igouy 5y ago
        The person who receives the contact email usually allows posts to be re-opened.
      - igouy 5y ago
        The Pharo 9.0 vm from — https://files.pharo.org/get-files/90/pharo64-linux-stable.zip https://files.pharo.org/get-files/90/pharo64-linux-stable.zi... — is the same as Pharo 8.0 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
- e12e 5y ago
  Just run your smalltalk/self on the js vm... https://lively-next.org/ https://lively-next.org/
Qem 5y ago
It's better shown than told. Just see this: 7 minutes of Pharo Smalltalk for Rubyists - https://www.youtube.com/watch?v=HOuZyOKa91o https://www.youtube.com/watch?v=HOuZyOKa91o
- gavinray 5y ago
  I watched the whole video, thank you for sharing! The bit towards the end (around 5 min mark I believe) where he gives the IDE (is that what you call it?) an input + desired output and asks it what message would produce the result he wants is pretty damn cool. The rest of it is "interesting" I suppose. I can imagine that, at the time, this sort of interactive/live visual environment was revolutionary. This would be 1972-1990's I think, and during those early years there was nothing even remotely similar, right? Towards the end Rapid Application Development (RAD) IDE's would start taking hold and then came the Pascal-powered heydays for a bit. I think that maybe just due to familiarity bias, I still prefer a text-based IDE which has hot-reloading and live eval results. Something pretty neat I use personally is an extension called "Quokka" which places the results of each line next to them, live as you edit (similar to a REPL) https://quokkajs.com/ https://quokkajs.com/ Jetbrains IDE's have a similar thing with "Worksheets" for languages like Kotlin, Python, Scala, and likely a few others. (Also "Metals" extension in VS Code can do this for Scala incredibly well)
chillpenguin 5y ago
I haven't used it much myself, but I've watched a lot of Alan Kay videos and I've read his "Early History of Smalltalk" which I highly recommend. My take is that it is largely about creating a computing system from the smallest yet most fundamental/powerful building blocks. In smalltalk, "everything is an object", which means everything has the semantics of a "whole computer". These computers are networked together and can send/receive messages back and forth with each other. This creates a drastically different paradigm than simply creating a pipeline of functions to send data through (for example). It excels at modeling complex systems, it's really "OOP done right". Of course there are other interesting features worth talking about, such as "images" and the introspection capabilities. Which are both great and often sorely missed in todays systems. But I think the big idea is to try to understand what Kay had in mind with OOP. Another aspect of smalltalk that is important, beyond just the "language" is to recognize its role in advancing "personal computing". Smalltalk was essentially an operating system that empowered the user to create new media and tinker with the system. If you want to see a modern web-browser based smalltalk-like system that uses javascript, check out Dan Ingalls' Lively Web. That will give you an idea into how smalltalk systems were meant to be used, in terms of "personal computing".
nsm 5y ago
I wrote a post about this as someone who only discovered it in 2020 - https://nikhilism.com/post/2021/experiencing-smalltalk/ https://nikhilism.com/post/2021/experiencing-smalltalk/
mcguire 5y ago
Speaking as someone who had experience programming in Smalltalk in its heyday, it had at least as many downsides as upsides and those who claim it was a peak are either looking at it through rose-tinted nostalgia or are Alan Kay. One favorite advantage was that as much as possible of the system was written in itself and the development environment was an integral component. Any developer could see and change anything. The approach was that you took the Smalltalk system and built your application as an extension onto it. "Playground-VM" is a pretty good description. Unwieldy? Not if you bought into it entirely, in roughly the same way that certain people I know bought into Emacs: Use it as your login shell and do everything through it. It was bad for creating stand-alone programs or scripts; instead, you add objects and methods to do whatever you wanted to do today.
igouy 5y ago
> … scripting tasks system, or for writing networked applications? Sure. Back in the day, Smalltalk without GUI was known as "headless" so Google "headless smalltalk" and you should find info.

AceJohnny2 5y ago

It's a very noisy datapoint, but compare performance VW Smalltalk to NodeJS: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/smalltalk.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... VW Smalltalk is between 2x and 27x times slower than Javascript. And Pharo is slower yet than VW Smalltalk: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/vw-pharo.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Nevertheless, as the front page the the Benchmarks Game is careful to mention, benchmark performance is 1) not necessarily representative of real-world performance and 2) not even always important in the greater context! Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. What would our world look like if Brendan Eich had gone for Smalltalk instead of creating a language from scratch?

jhgb 5y ago
> Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. Well...if you consider that the heritage of V8 in Node.js kind of goes back to StrongTalk, I'd say Smalltalk has received more of it than perhaps many people think. Unfortunately StrongTalk didn't really succeed on the market for the same reasons as many other Smalltalk implementations - proprietary nature and exclusivity doesn't really help you in the long run against worse-but-cheaper-and-more-accessible solutions.
Qem 5y ago
Those benchmarks are quite old, from Pharo 5 in 2017. It would be interesting to see a updated version. Eliot Miranda and Clément Béra are working on speculative inlining for the JIT compiler. From http://www.mirandabanda.org/cogblog/about-cog/ http://www.mirandabanda.org/cogblog/about-cog/ - "With Clément Béra I’m working on adaptive optimisation (a.k.a. speculative inlining) at the image level, optimising from bytecode to bytecode. We call this project Sista, which stands for Speculative Inlining Smalltalk Architecture. Clément’s image-level (entirely in Smalltalk above the virtual machine) adaptive optimizer is called Scorch. Sista should offer about a -66% speed-up (3x) for conventional Smalltalk code. The combination of Spur and Sista should yield almost a 5x speedup over the original Cog."
- igouy 5y ago
  > Pharo 5 in 2017 Seems to be tagged 2020 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM] The pharo.version file contains — 80
  - Qem 5y ago
    I'm sorry. You're right. I did a stupid mistake by confounding the vm version with Pharo version. I can't edit my post anymore, but please, anyone reading this, disregard the "Those benchmarks are quite old, from Pharo 5 in 2017" part.
    - igouy 5y ago
      The person who receives the contact email usually allows posts to be re-opened.
    - igouy 5y ago
      The Pharo 9.0 vm from — https://files.pharo.org/get-files/90/pharo64-linux-stable.zip https://files.pharo.org/get-files/90/pharo64-linux-stable.zi... — is the same as Pharo 8.0 — 5.0-202002121043 Wed Feb 12 11:06:45 UTC 2020 gcc 5.4.0 [Production Spur 64-bit VM]
e12e 5y ago
Just run your smalltalk/self on the js vm... https://lively-next.org/ https://lively-next.org/

Qem 5y ago

It's better shown than told. Just see this: 7 minutes of Pharo Smalltalk for Rubyists - https://www.youtube.com/watch?v=HOuZyOKa91o https://www.youtube.com/watch?v=HOuZyOKa91o

gavinray 5y ago
I watched the whole video, thank you for sharing! The bit towards the end (around 5 min mark I believe) where he gives the IDE (is that what you call it?) an input + desired output and asks it what message would produce the result he wants is pretty damn cool. The rest of it is "interesting" I suppose. I can imagine that, at the time, this sort of interactive/live visual environment was revolutionary. This would be 1972-1990's I think, and during those early years there was nothing even remotely similar, right? Towards the end Rapid Application Development (RAD) IDE's would start taking hold and then came the Pascal-powered heydays for a bit. I think that maybe just due to familiarity bias, I still prefer a text-based IDE which has hot-reloading and live eval results. Something pretty neat I use personally is an extension called "Quokka" which places the results of each line next to them, live as you edit (similar to a REPL) https://quokkajs.com/ https://quokkajs.com/ Jetbrains IDE's have a similar thing with "Worksheets" for languages like Kotlin, Python, Scala, and likely a few others. (Also "Metals" extension in VS Code can do this for Scala incredibly well)

chillpenguin 5y ago

I haven't used it much myself, but I've watched a lot of Alan Kay videos and I've read his "Early History of Smalltalk" which I highly recommend. My take is that it is largely about creating a computing system from the smallest yet most fundamental/powerful building blocks. In smalltalk, "everything is an object", which means everything has the semantics of a "whole computer". These computers are networked together and can send/receive messages back and forth with each other. This creates a drastically different paradigm than simply creating a pipeline of functions to send data through (for example). It excels at modeling complex systems, it's really "OOP done right". Of course there are other interesting features worth talking about, such as "images" and the introspection capabilities. Which are both great and often sorely missed in todays systems. But I think the big idea is to try to understand what Kay had in mind with OOP. Another aspect of smalltalk that is important, beyond just the "language" is to recognize its role in advancing "personal computing". Smalltalk was essentially an operating system that empowered the user to create new media and tinker with the system. If you want to see a modern web-browser based smalltalk-like system that uses javascript, check out Dan Ingalls' Lively Web. That will give you an idea into how smalltalk systems were meant to be used, in terms of "personal computing".

nsm 5y ago

I wrote a post about this as someone who only discovered it in 2020 - https://nikhilism.com/post/2021/experiencing-smalltalk/ https://nikhilism.com/post/2021/experiencing-smalltalk/

mcguire 5y ago

Speaking as someone who had experience programming in Smalltalk in its heyday, it had at least as many downsides as upsides and those who claim it was a peak are either looking at it through rose-tinted nostalgia or are Alan Kay. One favorite advantage was that as much as possible of the system was written in itself and the development environment was an integral component. Any developer could see and change anything. The approach was that you took the Smalltalk system and built your application as an extension onto it. "Playground-VM" is a pretty good description. Unwieldy? Not if you bought into it entirely, in roughly the same way that certain people I know bought into Emacs: Use it as your login shell and do everything through it. It was bad for creating stand-alone programs or scripts; instead, you add objects and methods to do whatever you wanted to do today.

igouy 5y ago

> … scripting tasks system, or for writing networked applications? Sure. Back in the day, Smalltalk without GUI was known as "headless" so Google "headless smalltalk" and you should find info.