Methods for Teaching the Programming Language Smalltalk (1977) [pdf]
bitsavers.org
bitsavers.org
In particular, modern Smalltalks use call-by-value, while these early Smalltalks used something more like call-by-name. Message arguments were passed in as unevaluated structures and parsed by the method. This allows some syntactic tricks that may look more natural than modern Smalltalk. For example, you could write "size increase by x" rather than the modern "size increaseBy: x" because the "increase" message could check for the presence of the word "by" and ignore it.
So this was kind of like using Lisp macros to define DSLs like the LOOP macro, but it was all evaluated at runtime.
Friend of mine works for a scientific equipment lab (mainly various kinds of microscopes and simulation equipment), and spends most of his time maintaining and adding features to Smalltalk images. It's an inhouse Smalltalk developed in the early 80s.
Some clients still pay to have their machines that run off 8" floppies maintained and upgraded.
Bear in mind, that for this sort of work, a contract can have timelines like 10yrs to implementation, with 20yrs support thereafter.
EDIT:
To expand, and try and answer your question a bit more thoroughly...
Smalltalk can be painful at times, and he vastly prefers C++. Especially a Smalltalk that has a completely different idea what file systems should look like, and how serial ports should be treated.
This old Smalltalk doesn't allow exceptions to happen on IO, which creates a large amount of debug-hell at times, though at least with Smalltalk the boilerplate is limited.
However, despite ten years of cruft, and fifteen different project leads, the projects are still manageable. That is a huge mark in Smalltalk's favour. There are other languages where this is possible, but it usually requires a lot of discipline.
VA Smalltalk. Large, fairly complex ERP. I am far more productive in Smalltalk compared to what I used to do before: .Net (C#, Powershell), a little Java, a DSL, COBOL. I am one of those people that "live in the debugger". I can usually deliver a fix within two minutes if I have a "walkback log", which is the stack-trace leading to the exception, or less than 30 minutes if reproduction steps are given.
The whole thing, GUI (forms etc) + logic, is in Smalltalk. GUI also modifiable graphically. All changes are trivial if the base code is good quality.
I also discovered Envy here - I also use Mercurial, git and fossil (personal projects) and Envy is the most powerful of them all.
I use Pharo for personal projects. Also very, very productive. I plan to retire with Pharo as my goto tool.
Do you know of online resources to get a feel for Envy? I'm not finding much, mostly obscure hints that this awesome version control system exists, without anything concrete. There are excerpts of a book on Google Books, but that doesn't help much either.
I found this book[1] on Amazon in case you or anyone else is interested.
I was forced to buy "Mastering ENVY/Developer" by Pelrine, Knight and Cho. It is well worth the money though.
Visual Smalltalk is no longer commercially available but in terms of memory requirements it was highly efficient because it was designed to run on PCs of 20 years ago.
This is my first job so I cannot really compare with other companies but I can compare to my university experience.
At the university I had to do 2 group projects. One in Java/Angular and the other we had the choice and I succeeded to convince others to do it in Pharo.
In the end we got a much better result in Pharo with more constraints. On the constraints we had for example the fact that I was alone to know Pharo at the beginning. Also we got a group problem and we ended up to be 3 when the other groups where 4-5. But we got the more advanced project at the end. We could not have done it in the languages the others used.
In fact, at the beginning, our teacher wanted everyone to do Java and/or Javascript, but she accepted that we used Pharo because she though we would not have the full team knowing Pharo fast enough and that we would stop Pharo to use Java. That did not happened.
2) I joined a company using smalltalk.
3) We are developing a set of tools to do software analysis and planification of software refactorings. Deployment is not really a problem. I find it simpler than in Java. There is still room for improvements and I plan to contribute to Pharo to help the deployment when I wall find the time.
One of my favourite researchers is Capers Jones. He's been researching software productivity for decades. His current company, Namcook Analytics, published a paper on his recent efforts [1]. Tables 14.1, 14.2, and 14.3 are of particular interest, although the whole paper is well worth reading for its own sake.
Some of his previous work seems impossible to find now. internet bit rot. One stands out in my memory. It also compared productivity in various languages, but also included error rates. Smalltalk ranked equally highly in that work, with significantly lower error rates per line of code.
To answer how Smalltalk compares to what I did previously, I have worked professionally using quite a number of languages, including Fortran, C, C++, and assembler (numerous). I would not willingly stop working in Smalltalk. Yes, it is that good.
Most companies using Smalltalk have exceptionally small staffing associated with their Smalltalk application, often having only a handful of developers & DBAs. Most of these businesses seem reluctant to talk about their Smalltalk applications. It doesn't seem to be due to embarrassment, but rather due to a desire to protect their competitive advantage.
[1] http://namcookanalytics.com/wp-content/uploads/2013/07/Funct...
Previously I worked several years in the Java world starting from Jr developer up to technical leader.
We will not use Smalltalk in our company as our main technology again. The Smalltalk technology is the best one I have learned over the years.
No previous experience, but happy to use it, one of the reasons is that code that it's ~10 years old it's still able to be maintained (and changed due to new requirements).
The problem is almost always integration with low level apis, or some protocol missing support.
I guess some of them only support Pharo (an open source implementation) so they have a leverage when they negociate with the commercial vendors (e.g., Cincom VisualWorks, VA Smalltalk, Gemstone).
I have friends who teach it in an academic setting.
Also, in the actual MOOC, for which you have to register at https://www.fun-mooc.fr/, the videos are also available dubbed in English. (Except some that are not part of the "actual" course that give tips on how to use the environment.)
Unfortunately - and I really don't understand the author's rationale - it's published by Elsevier. The price is way out of reach for most students.
I am working on it full time.