4 ms·

It’s funny because I’ve only started using it recently and what really captivates me is the live environment. The fact that you can dig in and evaluate/change

It’s funny because I’ve only started using it recently and what really captivates me is the live environment. The fact that you can dig in and evaluate/change everything in the same environment you are running it provides an amazing feedback loop. To me it really seems like the “killer feature” of the language but I can’t think of any modern language that has adopted it.

hodgesrm 6y ago
Smalltalk was inspirational, but the environment was a double-edged sword. In ParcPlace Smalltalk even things like stack frames were editable classes. One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM. BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must have existed in other systems but Smalltalk was the first language where I encountered it.
- stcredzero 6y ago
  BTW another brilliant innovation of Smalltalk was incremental compilation. Actually, Smalltalk compilation to bytecodes isn't incremental, from a certain point of view. The compiler finishes completely with bytecodes, usually instantly from the POV of the programmer. The compilation is complete. However, the binding is late. (Usually termed "late binding." You see, usually only one method has to be compiled at any given time.) If the VM is a JIT VM, then there's another compilation step to machine code. Arguably, one could term this "incremental compilation" as well. It fits the colloquial definition of "incremental." Another weird way one could term the features of Smalltalk, is the argument that it's a strongly typed language. Yes, that's right. It's just that the only type is Object. The differing of behaviors of instances of different classes is just runtime magic. (Late binding again.)
  - em-bee 6y ago
    the key feature i like here is that code can be changed and recompiled while an application is running. when an error occurs, the application does not crash but freezes allowing me to fix the error and resume. to the point that when the aplication is a website and an error occurs while a browser is accessing it, the loading of the page just stalls until the error is fixed, at which point it resumes without any user intervention from the browser side.
- twic 6y ago
  Same: the first thing i ever did in a Smalltalk environment - after grinding through swapping floppies in and out of my Mac Plus for twenty minutes - was define an empty LinkedList class, or rather, redefine the LinkedList class that the Smalltalk kernel used to schedule threads to be empty.
- kjs3 6y ago
  Heh...Symbolics Genera environment (Lisp) had the same sort of footgun. You could edit pretty much everything down to bare metal on the fly, and the closer you got to the bottom, the more likely you were to touch something that should not be touched by mortals.
- igouy 6y ago
  "ObjectWorks for C++" was a ParcPlace IDE which iirc provided incremental compilation.
- klipt 6y ago
  > One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM Sounds like these live environments didn't support version control or reproducibility in the modern sense then?
  - codefrau 6y ago
    They did and do support version control etc. E.g. even Smalltalk back in the day kept a log of every single change of code in what's called a "changes" file. "Corrupting the VM" just means that you were editing the stack frame class in the live system running on the VM and as soon as you hit "save", the VM crashes. So you simply run it again. And if needed, replay the changes log up to before the crashing change. This only takes seconds, and is part of the reason why Smalltalk is so productive.
tarkin2 6y ago
I only did a small amount of squeak programming many years after smalltalk’s heyday but I found the live interface incredibly productive. It was lisp’s image based systems with an incredibly useful gui. I created a small audio app with it very quickly. I wish more languages would incorporate it. The closest thing I know of is inspecting DOM elements through javascript’s debugger and using the developer console to run operations on them. But that only lasts until you press refresh. With smalltalk, seeing an object and then being able to edit the object and then making it interact with other objects made OOP come alive, rather than Java’s inheritance soup with dubiously modelled classes that eventually made developers want to throw away OOP.

hodgesrm 6y ago

Smalltalk was inspirational, but the environment was a double-edged sword. In ParcPlace Smalltalk even things like stack frames were editable classes. One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM. BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must have existed in other systems but Smalltalk was the first language where I encountered it.

stcredzero 6y ago
BTW another brilliant innovation of Smalltalk was incremental compilation. Actually, Smalltalk compilation to bytecodes isn't incremental, from a certain point of view. The compiler finishes completely with bytecodes, usually instantly from the POV of the programmer. The compilation is complete. However, the binding is late. (Usually termed "late binding." You see, usually only one method has to be compiled at any given time.) If the VM is a JIT VM, then there's another compilation step to machine code. Arguably, one could term this "incremental compilation" as well. It fits the colloquial definition of "incremental." Another weird way one could term the features of Smalltalk, is the argument that it's a strongly typed language. Yes, that's right. It's just that the only type is Object. The differing of behaviors of instances of different classes is just runtime magic. (Late binding again.)
- em-bee 6y ago
  the key feature i like here is that code can be changed and recompiled while an application is running. when an error occurs, the application does not crash but freezes allowing me to fix the error and resume. to the point that when the aplication is a website and an error occurs while a browser is accessing it, the loading of the page just stalls until the error is fixed, at which point it resumes without any user intervention from the browser side.
twic 6y ago
Same: the first thing i ever did in a Smalltalk environment - after grinding through swapping floppies in and out of my Mac Plus for twenty minutes - was define an empty LinkedList class, or rather, redefine the LinkedList class that the Smalltalk kernel used to schedule threads to be empty.
kjs3 6y ago
Heh...Symbolics Genera environment (Lisp) had the same sort of footgun. You could edit pretty much everything down to bare metal on the fly, and the closer you got to the bottom, the more likely you were to touch something that should not be touched by mortals.
igouy 6y ago
"ObjectWorks for C++" was a ParcPlace IDE which iirc provided incremental compilation.
klipt 6y ago
> One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM Sounds like these live environments didn't support version control or reproducibility in the modern sense then?
- codefrau 6y ago
  They did and do support version control etc. E.g. even Smalltalk back in the day kept a log of every single change of code in what's called a "changes" file. "Corrupting the VM" just means that you were editing the stack frame class in the live system running on the VM and as soon as you hit "save", the VM crashes. So you simply run it again. And if needed, replay the changes log up to before the crashing change. This only takes seconds, and is part of the reason why Smalltalk is so productive.

tarkin2 6y ago

I only did a small amount of squeak programming many years after smalltalk’s heyday but I found the live interface incredibly productive. It was lisp’s image based systems with an incredibly useful gui. I created a small audio app with it very quickly. I wish more languages would incorporate it. The closest thing I know of is inspecting DOM elements through javascript’s debugger and using the developer console to run operations on them. But that only lasts until you press refresh. With smalltalk, seeing an object and then being able to edit the object and then making it interact with other objects made OOP come alive, rather than Java’s inheritance soup with dubiously modelled classes that eventually made developers want to throw away OOP.