This is cool. For those who may have seen Smalltalk before and are wondering where all the colons went in the example code snippets: The language discussed in these articles appears to be Smalltalk-72. Modern Smalltalks are based on Smalltalk-80, which is quite different in some respects.
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.
Sounds similar to what in Lisp is called a FEXPR. A concept which was widely used in the 70s and what has mostly been replaced by macros. Fexprs get the arguments unevaluated at runtime and then do runtime parsing/transforming/evaluation.
Does anyone on here program in Smalltalk professionally? Not to get off topic, but I'm curious and would like to know how it stacks up compared to what they did previously.
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.
None whatsoever. This is the worst thing about Smalltalk (with the exception of the open-source ones) - there is almost no useful documentation freely available.
I was forced to buy "Mastering ENVY/Developer" by Pelrine, Knight and Cho. It is well worth the money though.
I know of Pharo (have used it a little bit) as well as Dolphin, Squeak, and VisualWorks. I've only talked to someone who has actually made money from a Smalltalk app once before, although I'm sure it's not that rare. I'd like a little more information on how efficient they are...etc besides just seeing a few success stories. Thanks for the help though, always nice!
For the past 10+ years I was working professionally on a Visual Smalltalk application, maintaining and enhancing it over time.
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.
In my professional work I use Smalltalk, Pharo to be exact.
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.
Interesting and thanks! Follow up questions: 1.) What was the university project? 2.) Did you look for a company using Pharo, or join a company and convince them to let you use it? 3.) What kind of applications do you make at work and is deployment a problem? Thanks!
1) It was a project of multiple choice questions management with an administration part, a user part and a statistics part.
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.
I made a fulltime living between 1993 - 2005 using VizualWorks which is the original descendant Smalltalk from ParcPlace which came out of Xerox PARC. Systems are still in production across industries. It was a particular favourite with banks and Wall St for decades and some like JP Morgan still use it http://www.cincomsmalltalk.com/main/successes/financial-serv...
I saw JPMorgan on the Pharo Consortium list. Any idea how they use it? I get the feeling large banks use almost EVERYTHING as they even have a lot of APL language use in house with A+ & kdb+.
Actually I was surprised to see JP Morgan there. I don't watch it closely but they seem a recent addition. Their "Kapital" system is based on Cincom Smalltalk. I wouldn't speculate they are porting it. Facilitating a viable open source Smalltalk alternative may just for negotiating power with their incumbent Smalltalk.
http://www.cincom.com/pdf/CS040819-1.pdf
I met the International Product Manager for Cincom in a Smalltalk meetup once. She was complaining about the aggressive Pharo folks "badmouthing" Cincom and taking their business. One of the chip fabs previously running VW Smalltalk got taken by Pharo. I heard somewhere else that JPM were unhappy at the steep consultancy fees Cincom was charging, and the lack of VW Smalltalkers out there, but still wanted to keep things in Smalltalk. So it seems these rumours may be true if JPM has joined the Pharo Consortium.
I was wondering the same thing as I figured they already used Cincom. I know Cincom is very expensive, but surely it's negligible for JPMorgan? Maybe they feel Pharo has more momentum and have started doing some projects there to steer it where they want it to go?
I have been using Smalltalk professionally almost exclusively since 1991. Over the years, I have dabbled with Java, but every time I do, I feel like I am poking myself in the eye with a rusty spoon.
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.
Thanks for sharing this! I first read about the "secret sauce" from Paul Graham referring to his use of Lisp with Viaweb, but have been somewhat suspicious. Yes JVM performance & scalability is necessary for some applications like twitter, but surely the industry should see 90% of standard business software is fine in other languages. Is everything really driven that much by market hype? I guess hiring is critical too.
Yes. I am using Smalltalk since 5 years for professional work and paying all the bills. I work as an independent consultant/engineer and I had 6 different clients so far, to which I worked remotely to all of them. Mostly I use Pharo and GemStone but also a bit of VisualWorks and VisualAge.
Previously I worked several years in the Java world starting from Jr developer up to technical leader.
Yes I did this 20 Sears ago in VisualWorks, ViasualAge and Visual Smalltalk. Then we went to mainstream technology and for the last three years we have entered the Smalltalk community again by using Gemstone.
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.
Almost 5 years developing financial products with VA Smalltalk.
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.
14 years and counting working on a medium-sized company that uses Smalltalk only, to develop financial applications.
Also, 3 years and counting using Smalltalk to develop a commercial game rules application as a personal side project.
I'm only a hobby Pharoer (my day job as electrical power engineer is not programming) but on the mail-list I see newcomers describe Pharo as "fun" and as "a breath of fresh air" compared to their day job. You would get a better first hand answer on pharo-users mail list (lists.pharo.org). But in the meantime, you can see commercial funding for Pharo an growing -
slide 7...
https://www.slideshare.net/esug/pharo-consortium-v20
Mostly construction and commissioning for industrial/mine site 11kV distribution through to MV/LV motors; and a stint in asset management at a 400MW generation plant. Haven't touched transmission.
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'm going out on a limb here, but Objective C (specially modern versions, post Lattner facelifts including blocks etc.) shares a huge amount of syntax, philosophy and general ideas with Smalltalk 80. Essentially everybody doing iOS apps in ObjC is doing some sort of Smalltalk development.
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.)
It is a bad idea to reuse project names, though since the older Smalltalk Express (freeware version of Smalltalk V/Win) was from back when the web was new there won't be too many search results about it to get in your way:
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.
[0]: https://paulhammant.com/2017/09/01/smalltalk-envy/
[1]: https://www.amazon.com/gp/product/0521666503
I was forced to buy "Mastering ENVY/Developer" by Pelrine, Knight and Cho. It is well worth the money though.
https://pharo.org/
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).
[0]https://en.wikipedia.org/wiki/Satellogic
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.
http://www.andreadrian.de/smalltalk/09-11-96.htm