My biggest interaction with Smalltalk was having been invited by Alan Kay (along with a number of others from my university) to tour Parc. We got down there, saw a demo of Smalltalk-74, and were of course blown away. There were other things we were explicitly told we could not know about, such as the “ball-bearing machine” (which I now believe to have been a laser printer). Because much of their low-level coding was done in BCPL, and I was very familiar with the internals of Martin Richards' compiler, I also asked to chat with their BCPL guy, whose name I now forget. I introduced myself, and we chatted for a few minutes. He then got suspicious, and asked me why I was there. I explained what was going on, and he called for a lawyer, who asked me if I was a U.S. citizen. I replied that I was Canadian. Shortly thereafter, the whole lot of us were rounded up and expelled.
A few years later, I was working at another place (definitely not Parc!) and found a copy of the Smalltalk-76 manual that somebody had left on the Xerox [sic!] machine. I lost no time in copying it, and admiring the amazing thought that had had gone into the language's design.
1) I think U. of Waterloo (Canada) had several CS coop students (paid interns) at Parc in the mid-80's, so I'm surprised there was a citizenship issue.
2) I later worked for Incyte, who leased space next door from Parc around 2002. I smiled whenever I got a meeting invitation at Parc. :)
That story dates from 1974, presumably things had changed a lot by the 1980s. As I recall, the Parc LRG had considerable difficulty getting permission to publish the Smalltalk books.
I worked on air traffic control display prototypes using Smalltalk in the early 90s. Pretty much everything was done in C and Ada back then (at least in my company), and the sheer productivity of the Smalltalk environment blew away everyone who came into contact with it. Years later, fell in love with Ruby because it was so clearly itself a love letter to Smalltalk !
The great tragedy of our craft is that, despite exponential improvements in other areas of computing, IMO nothing since has really come close.
I've been reading about Smalltalk and Squeak for years and only just now realized the relationship between their names.
Anyway... My only real exposure to Smalltalk was via obj-c. That combination of simple languages was truly amazing in terms of its power/complexity ratio.
I'm not doing native iOS dev anymore, but from a distance, it's a little sad for me to see how much of radical departure Swift is from that simplicity...
I wonder if the name Smalltalk was inspired by the name "Lisp". Lisp is away of talking, so is small talk. Maybe creators of ST-80 desired to create something higher level, more human-like than "lisp".
This really is a potentially very misleading bit of uninformed speculation.
"LISP" gets its name from "list processor".
"Smalltalk" gets its name from the the fact that the language came from the Learning Research Group at Xerox PARC -- the "small" was thus meant as an acknowledgement of the study that how children learn was crucial to the design of the Smalltalk system, and the "talk" relates to the fact that objects "talk" to one other by messaging.
If you dive into the history of Xerox PARC workstations, you will find similar developer experiences for Lisp (Interlisp-D), Mesa (XDE) and Mesa/Cedar.
The graphical debugger, dynamic code loading, bytecodes with microcoded CPU configured on boot, REPL with access to the whole OS, the way OS, libraries and applications blend together, all there across all those language stacks.
Doesn't look like it although Alan Kay has expressed admiration for Lisp in many places.
> As for hype: Another motive for "smalltalk" was the practice at the time of naming operating, and other, systems (which hardly did anything) after mighty indo-european gods, such as Thor, Zeus, Odin, etc. I figured that if Smalltalk ever did something neat, then people would be pleasantly surprised.
I remember my first encounter with Smalltalk.in 1994 I believe.
It was so different than Pascal I used daily ( that's I loved for the clean sub function call BTW).
Here in Smalltalk, an object was like a cell, with both its functions (sort of mini API cell) and its values... Wahoo !
I also read a book from MIT press full of parallels between people asking/answering things to others like in Smalltalk an objets send messages to other objects.
The fascination I had with Smalltalk at first was that I felt suddenly that you could program software in a more humain way of thinking...
It was the 81 BYTE article that got me really interested in Smalltalk (I miss BYTE of that era, but times change ...).
First time I got to use it was to put together a live demo for a bid we were working on for a new project. Must have been around 87/88, got a shiny new Dell 286 to run Smalltalk/V, took Dell several goes to find me a VGA card that would work properly on the system.
Last time I used it in anger was at JP Morgan in 2009.
Things like IntelliJ IDEA get you part way these days, but the whole live, interactive environment really was revelatory, only thing close I used was Interlisp on a XEROX 1108.
It's amazing how progress in software engineering has been held back by fashion and entrenched opinions, what people think is trendy and would look good on their CV.
will have an analogous effect on an "alive" Unix image. I mean, a Unix machine. :-)
Incidentally, in the latest Squeak,
True := False.
doesn't work -- the compiler complains that you can't assign into a read-only variable. So let's try this:
Smalltalk at: #True put: False.
But now the metaprogramming system complains you're trying to modify a read-only binding! So we view source on ClassBinding>>value:, and see that a resumable exception is being used to guard the modification, so let's explicitly signal that we REALLY want to modify that binding:
[Smalltalk at: #True put: False]
on: AttemptToWriteReadOnlyGlobal
do: [:ex | ex resume: true].
Finally! Now, evaluating "True" yields "False".
But the image keeps running! Use of the literal class True seems to be rare enough that things are OK for at least several minutes after the change.
Doing this, however, definitely should immediately torpedo things:
true become: false.
... huh. It didn't work. It used to! Again, on this current Squeak version, we see a different behaviour. This time, it says "Cannot execute #elementsExchangeIdentityWith: on read-only object #(false)".
So we'll have to try harder:
true becomeForward: false.
That doesn't work either! Same error as for #become:.
Welp, I'm actually all out of ways to crash this modern image in analogous ways to the easy pitfalls of images of yesteryear...
That used to be the case with JavaScript too - until recently (ECMAScript 2015, IIRC?) you could do `undefined = null;` and other fun things like overwrite the `Array` constructor (which became a particularly nasty JSON attack vector).
Wouldn't such redefinition make more sense to be isolated in a newly spawned universe? That way the whole system would not collapse yet you could still play with such concepts.
Yep! Absolutely. Just like Unix VMs (and containers, etc.): recursive whole-system composition makes perfect sense. Smalltalk hasn't been taken in that direction yet by anyone, though, as far as I know.
There are two things I'd like to do with Smalltalk. That's one, and the other is giving each object a thread-like construct and make all execution asynchronous apart from dependencies.
I have been using Pharo Smalltalk to solve Advent of Code this year and it’s been a really fun experience! I wish I could use Smalltalk more places, particularly because of the interactive development and the visualization toolkits. Something like PetitParser2 made several of the AoC challenges really easy because if just write a full parser instead of regex or hand parsing.
This is fantastic, especially for those of us still working on/with Smalltalk.
Dan Ingalls himself has sometimes joined the online meetings of the UK Smalltalk User Group ( http://www.uksmalltalk.org ). We'll look into asking him to give a tour of this.
I still develop in Smalltalk almost daily. It's a very productive environment and a godsend regarding debugging and inspecting live running application. The caveat is nonexistent support on our old version.
Also after having checked various "modern" Smalltalk implementations I have to sadly say that none come close to the experience of the older ones. Maybe Cincom, but that is proprietary. So the whole language and idea is mostly dead.
I’d be interested if you could expand on why the modern Smalltalks feel wrong, because on paper they have more features etc. Not arguing - genuinely interested.
It's probably a personal thing but the main point is this:
- Pharo and Squeak are both one full screen application with their own window manager inside. And that window manager is terrible and slow. I can't even alt-tab between windows. The old "Visual SmallTalk Enterprise 3.1" from 95 leverages all window handling to the OS and is quick and snappy. It also has a native look if that is your thing. This contributes a lot to the developer experience: shortcuts and code completion are quick and snappy, you can easily deal with the separate windows, etc. In Pharo everything is so slow compared to this and not very developer friendly. Maybe someone can show me what I have been doing wrong but this is my main gist.
Dolphin Smalltalk from Object Arts allows alt-tabbing between native windows. The formerly commercial professional version has been released as open source. It is Windows only, but it apparently runs well via Wine on Linux and Mac. Though the executable is 32-bit only, and lightly maintained, it provides an aesthetically pleasing and responsive development environment.
I am guessing that there's not much motivation to change this because of the desire to run anywhere. They can run inside an SDL window on a computer, but, with little modification, you can also get everything running on bare metal, in a browser canvas, or on a mobile device. Visual Smalltalk Enterprise, on the other hand, only ran on Windows.
Personally, I'd welcome something that can do a decent job at cross-platform native-like UI. But I'm not terribly hopeful. As far as cross-platform UI goes, Electron seems to have sucked all the air out of the room.
Yeah I understand it's easier to make it run everywhere but more choices would be nice. Yeah VSE only runs on Windows, that is one of the many negatives about it.
Original Smalltalk was always "full screen" so it is strange to argue this way. Anyway, there are still Dolphin Smalltalk and Smallltalk/X (jv-branch) under active development that use OS windows manager. Pharo will allow working this way soon as well. On the other hand, it has own downsides if you work in multiple images at once and mix their windows together.
Yeah the original was, but many following that weren't "full screen". As I said it's a personal preference. I did hear that Pharo is working on something like that so I hope it will be implemented soon.
I thought that Dolphin was not developed anymore, that is nice to hear. I'll have to check it out again. Which of the two would you recommend?
I've been a huge Alan Kay admirer for years. The statement of his that stands out for me is "We weren't trying to make a new language, we were trying to build a new Operating System". Zing! Makes some of the paradigms in Squeak much easier to understand. (Where is my 'save' menu?)
Smalltalk is one of those languages I can’t wait to try once I have a project I feel it would be a good fit for. I can’t find good resources for learning it though, outside what seem to be dated video tutorials or books. Is it true that the original smalltalk books are mostly still good for Squeak?
Yes the Blue book is still good. But there is not much language syntax to learn[1], you should start with using objects directly in the Squeak or Etoys environment, preferably a few Morphs. Even simpler, see these video tutorials[2]. You'll be fluent in the language in an hour. Learning the whole environment takes a few days. Even faster, do a screen sharing session with a Smalltalker like me. merik at fiberhood dot nl
For the 'core' (i.e. non-interactive parts of the) language, that's still somewhat true. So for basic class/method definitions, collections classes etc. you could probably somewhat get by with the Blue Book. (with a massive caveat that the UI class hierarchy and interaction paradigm is completely different. Also, VM has gone through several iterations of changes that have necessitated some image-side changes which wouldn't track with the old books either.)
However, your learning curve will be much easier if you start with a tutorial/reference targeting the dialect you want to work with. Then go back to things like the Blue Book to understand where it all came from and analyze the differences if you're so inclined.
Seaside's at least still being actively maintained.
My sense is that, as one of those languages that, while still reasonably popular, never really took off as an open source platform, the bulk of Smalltalk work is proprietary work that you don't really get to hear about. I'm hoping Pharo's good work turns that tide a bit; they've done a whole lot of work to address things that hindered the use of Smalltalk in open source projects.
Reportedly it's popular in finance. For example, JP Morgan somewhat famously built a major risk management system in Smalltalk. I've heard plenty of similar intimations, but, considering that, during my stint in the financial industry, I wasn't allowed to talk publicly about any technology that the company considered a competitive advantage (though we were encouraged to name-drop Java as much as we liked), I wouldn't hold my breath for a lot of specifics.
I love the hyper-introspective living environment of Smalltalk, but I'm a functional programming type nerd and fantasize regularly about something like Smalltalk + dependent types, which feels like it'd be a dream development environment for me.
Smalltalk almost killed me in '89. I was in school.. Carleton U, where there was almost a religious zeal for Smalltalk. They had it running on a collection of Apple Lisas which were running some sort of Mac emulation. Slow? Brutal. After BASIC and Pascal, Smalltalk seemed impenetrable. But we all seemed to survive. Come that summer... employers had no clue about how awesome Smalltalk was. They wanted COBOL, dBase, Fortran. No work in Smalltalk... so it died for me that day. Happy to see it's still out there though. Fun times.
I got introduced to Smalltalk via Smalltalk/V on Windows 3.1, that alongside IDEs that took inspiration from Smalltalk spoiled me in what to expect from developer tooling.
The live IDE thing - which isn't a gimmick at all, in my opinion - really is the only thing left that sets Smalltalk apart in 2020. Besides that, it's a very simple, dynamic, single-inheritance class-based pervasively object-oriented programming language that doesn't do anything especially interesting these days. Of course, while it was being developed in the 70s, all that was pretty revolutionary!
The closest popular language to it today is probably Ruby, which was directly inspired by it and is similarly dynamic, single-inheritance, class-based, and pervasively object-oriented.
I would say something like LispWorks, Factor or even JavaScript with the browser console do a better job at this.
I have given Smalltalk plenty of tries, and always ended giving up due to the lack of polish prevalent on all current implementations:
Pharo looks blurry on my Macbook and is crashing all the time.
Squeak is a bit more stable but feels and runs like a toy.
Cincom is a tad better and has a pretty nice UI designer that is best in class (I would be embarrassed to give a client the ugly non native user interfaces that I see people building in Pharo) but I had the community version (which is not even the latest version) also crash on me a few times and you cannot test it on macOS Catalina / Big Sur.
But without the live IDE thing, you lose many of the great things about Smalltalk.
I spend a lot of time on the Ruby Docs, looking up which methods an object has. "Traditional" IDEs give you type-ahead features, where they perform a code-analysis and then predict what you might want to type. But in Smalltalk I just ask the class how I should be using it and it tells me there and then, even if the class has been modified with methods added or removed or rewritten at run-time.
Is the REPL the same environment as your running code?
If your environment has stuff added dynamically (for example every Rails app) you need to attach to the live environment - an OO version of gdb. And once you’re doing that, you’ve basically got Smalltalk without the nice presentation layer.
Update: by presentation layer I mean I can ask to inspect a live object and open a window that shows not just it’s instance variables and the messages it responds to, but read the documentation (the equivalent of Rubydoc) and source code (including editing that source code if I wanted to).
probably because of the type of programming i do (business intelligence),
live environment doesnt mean much to me
most programs run, and finish, and updating most programs while running, is not something important, you can always update it and run it again
for long running processes like servers
well again,not really sure what this means
but i deal with database management systems, and i mean you can update a stored proc, without shutting down the server, you can of course update the data etc ..
as for the dbms process itself, i am not big on dba stuff,but most databases allow in-place upgrade , but usually you can to disconnect everyone while doing it
as for large website, like facebook or anything else even a lot smaller in scale, those are obviously not a single program .. and most likely they just restart services to pick up updates, and use a form of load balancing to work will go to servers that are not restarting
So in summary, this notion of live app, seem more theoretical than real to me
My bet is that it's MIT's Scratch. Notsomething used in production, but if you have a kid learning how to program these days, it's the obvious good choice (and I've done a ton of research).
The language itself is surprisingly pleasant to program (even for a professional programmer). The real problem is the lack of data structures (like a dict), so some projects (unfortunately, many my 7yo comes up with) become extremely annoying to program.
It's definitely more than a gimmick. I understand why someone with no experience developing with Smalltalk might thing it's one - developers are used to claims of life changing IDEs that fall short.
Unfortunately, I've never found anything with an IDE that touches what you get in Smalltalk. I've always wanted someone to create an environment for Ruby, Python, or JavaScript that would give us the best of both worlds, depending on what you needed at the time. I remember attempts in the early 2000s, but nothing really touched it.
The only other language with an environment like Smalltalk that I've seen is Self, which is a prototype OOP language derived from Smalltalk, but that's even less popular.
A few years later, I was working at another place (definitely not Parc!) and found a copy of the Smalltalk-76 manual that somebody had left on the Xerox [sic!] machine. I lost no time in copying it, and admiring the amazing thought that had had gone into the language's design.