I learned Smalltalk in the Elder Days (1985). Coming from C and Pascal, the power and majesty of true collections—dynamic lists! that you didn't have to build yourself with pointers! sets! dictionaries! iteration over objects not integers! selection, rejection, injection!—was <i>astounding</i>. The ability to define behaviors in a generic not intensely specific way, the ability to meta-program, the ability to twiddle your environment directly—just <i>so many</i> world-changing innovations. Thankfully most of these advances are now baked into Ruby, Python, JavaScript, etc. (either right into the language, or with ready-to-hand libraries like itertools, more-itertools, and Underscore.js).<p>The image—all your code, data/state, your entire OS and windowing system, your IDE, all rolled up into one—that was an interesting approach but honestly that is the worst thing about Smalltalk. No modularity. No version control. Your image persists your data and changes forever—including any mistakes you make, knocking around inside big ball of ever-declining clarity and reliability. Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. Then you have to chuck it and start afresh. Rinse and repeat! Give me today's alternative, non-persistent dev environments and version control, any day.
I did smalltalk professionally as my second job out of college, 1995-1997. It was cool learning it, and it definitely gets you into OOP. It also laid the groundwork for realizing that OOP isn't a great paradigm for software development. Plus it was really slow and clunky, in the end. For the time, the IDE (VisualAge and the other one I can't remember) was cool, although git crushes the model they used back then.<p>Overall, I'm glad I learned it, much like TCL and Lisp, but I'm definitely glad I don't use it professionally.<p>The languages basically take their premise to the extreme, where the premise for each is "What if everything, including the language itself, was ..."<p>TCL: ...a string?<p>Lisp: ...a list?<p>Smalltalk: ...an object?<p>I don't know enough about it, but I think with Haskell the suffix would be "...a function?"<p>Neat experiments, neat learning them, but I appreciate other languages more for actually implementing large projects.
I worked with Smalltalk for a number of years, and was even present at discussion during the ESUG (European Smalltalk User Group) meetup in 2008 that was the very birthplace of Pharo, though admittedly was a little out of my depth with some of the technicalities (and politics) that caused the rift from Squeak.<p>I <i>loved</i> working with Smalltalk as a language, and developing inside the fully integrated VM. It's my fondest development experience to date.<p>I really didn't love deploying Smalltalk applications and even collaborating was more difficult than file based languages/systems. Deployments (at the time) were a practice of shipping the image to the servers that needed to run. There literally is no (separate) "runtime" it's all in the image. This thing got bulky real quick.<p>I haven't touched Smalltalk in a while, so maybe (hopefully?) things have improved and deployments are no longer a problem.
I've played in Smalltalk systems over the years, but not used it for anything serious.<p>On one hand I like the idea of an image, being inspectable, adjustable, etc. Yet on the other hand I'm also a fan of stateless, pure-functional approaches where possible (e.g. Haskell, Nix, etc.).<p>I get a similar feeling from Emacs: it's really useful to inspect, override, debug, etc. the underlying Lisp; yet I prefer to keep my config as declarative as possible (e.g. via use-package). In fact, I rebooted recently and found that ANSI colour codes had stopped working in my Emacs terminals: turns out I'd forgotten to update my xterm-color config when switching from shell-mode to shx-mode several weeks ago!
Love these ambiguous enough titles to be either something interesting for the whole population (how to learn small talk) or something incredibly specific for one subset of the programmers population.
smalltalk and lisp are both secret weapons; understand and appreciate them and even though you may not use them in any commercial or professional setting, knowledge of them makes becoming familiar with other languages much easier.
What is the current state of multi-core and multi-threading in Smalltalk? I remember Squeak wouldn’t use more than one core and one OS process and would implement threads in itself, but that was a very long while ago.
This is heartening. It was hugely influential on the Xerox Star and by extension, Lisa and Mac, even though we didn't actually write in it. It showed you a different way of thinking about things.<p>But for anyone saying they learned Smalltalk in the Elder Days (1980s):<p><i>No, you didn't.</i><p>In [1] I discuss learning it in 1978, and there was an icon prototype written in Smalltalk that same year.<p>[1] <a href="https://www.albertcory.io" rel="nofollow">https://www.albertcory.io</a>
Maybe - one day - somebody will make the image based virtual machine for Java... VisualAge for Java was an attempt in that direction, but the image part was abandoned later in Eclipse...
Smalltalk was my introduction to OO in the 90s. It is the perfect introduction in my opinion, but as the author says, it might spoil you for anything else. If I remember right, the whole image thing took a bit of care, with odd forgotten stuff ending up in production. Someone may correct me.
The problem I have with Smalltalk (and I love the idea!) is that when I want to save things in Git, or when I want to deploy something minimal, things are so glued with each other that I find difficult to figure out what belongs to me.<p>There are also other problems:<p>- a desktop app cannot look like a regular one, at least in Pharo.<p>- I am not sure how to glue native code, so when doing graphics stuff (this is what I really want to do with Pharo bc of its interactivity) I did not know how to consume APIs for drawing.<p>I do not have a lot of training admittedly. The interactivity looks super, super cool! But also you have to change a lot of habits.
What do some of you smalltalksters do with it?<p>I've had a daydream that some sort of data Swiss army knife/visualizer toolkit would be a fun project but it lacks the share ability of notebooks. Are there other operational sorts of things you use smalltalk for? I have a set of scripts and tools I use daily for work (things that slice and dice our data, perform various operational tasks against AWS, etc..) that I could see cooking in to some sort of smalltalk system but I haven't done it.
<i>If feels like you build the environment to match the problem, not figure out how to describe your problem on the terms of your language.</i><p>Yes. Correct. That was the intention of the language design. Here is described in detail by Dan Ingalls <a href="https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html" rel="nofollow">https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....</a>
Smalltalk has the unrivaled ability to explore and change your environment graphically, and for the changes to persist. Only the web with the developer console comes close, and the changes aren't persistent.<p>Binary image-based development with serialisation, now we aren't all trying to make exes, should be more of a thing.
I remember learning Smalltalk. Or rather, beating the crap out of the bloody machine it ran on. This was back in 1989...Carleton U in Ottawa. The CompSci faculty was all-in on the glory of Smalltalk. We had to learn it on old (even then) Apple Lisa machines running some sort of Mac emulation to run Smalltalk-80. Occasionally, the Lisa would eat your diskette...and you had to rip the case apart to pry it out. We were told Smalltalk was the future...seemed no one was offering jobs in Smalltalk though...just a whole lot of dBaseIV. Must admit, it was fun, and cute...but it had no chance of paying my bills at the time.
I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Smalltalk devs do so far.