The Rise and Fall of Commercial Smalltalk (2020)
wirfs-brock.com
wirfs-brock.com
Seeing how smaller companies like to follow FAANG's technology choices today, combined with the profession following free-as-in-beer options, this also seems like an alternative plausible explanation.
EDIT: I'm not blaming IBM or Java, I've just used this to inform my own technology choices for my knowledge portfolio.
I've never fully experienced Smalltalk, but the few posts that came by on HN always fascinated me, since there's a whole interactivity element to it. And I've noticed when it comes to programming, I like interactivity.
1. being able to catch an exception, and injecting a sensible return value so the underlying code could continue. Its incredibly powerful although a lot of inexperienced smalltalkers used it as a crutch for poor design. I.e. I won't handle the error or do bounds checking, I will put a try/catch block around it and send back some value the code can handle.
2. The interactive debugger was truly fix and continue, not the pale imitation you get in .NET or Java. Your code crashed, it threw up an exception window, you fixed the method and restarted the thread of execution like nothing happened. You can kinda do this in .NET now but its slow and doesn't always work right.
The rest of the environment goodies like variable inspectors and live expression evaluation are largely as good or better in java and C# than the classic commercial smalltalks.
And this is the best we currently have, other languages are even more behind than those two ones.
Haha, no... have you heard of Lisp?
I have certainly heard about Lisp, in fact, many haven't heard about Allegro Common Lisp or Lisp Works, the only ones that matter, which the FOSS usually ignores.
This doesn't change the fact that sadly Lisp and Smalltalk are almost nowhere to be seen in 2021 (in large deployments).
As Guy Steele puts it, Java is half-way to Lisp, even if you put Clojure on top, it isn't the same deal as 100% Lisp.
You should take a look at hot reload in Dart and Flutter:
It drank the OO koolaid complete with multiple derivation.
For GUI I switched to the MS windows C-toolkit. Event driven and very easy to manage. The OO solutions from Borland and MS (MFC if memory serves) were very hard to use
When I had the choice I switched to using the C-SDK and an event loop.
Twenty years ago now, but I can still recall my frustration. So much work (by Borland and MS) to make things so much worse
To do what? Compared to what?
> verbose
Definitely! By design. It was supposed to be readable.
> couldn't integrate with CVS
Could use integrated configuration and version control
https://www.google.com/books/edition/Mastering_ENVY_Develope...
> required you to use their editor
An IDE that allowed you to evaluate code and make structural edits.
> a UI which was completely non-native
Depends which Smalltalk implementation -- both native and emulated cross platform.
> cost a small fortune
Depends which Smalltalk implementation and what you wanted to do.
Java was the succesor of Smalltalk as deemed by Big Blue.
Update: interestingly, Java Swing/JFC, used by IntelliJ IDEA for its GUI until this day, is based on a SmallTalk OO design, though it originated from Sun not IBM I believe
I'm not sure which UI VisualAge Java used but I remember that working much better than the median Java program too.
We moved off that to IBM Websphere Development Studio. We were a big IBM shop at the time (Websphere + DB2).
I'm interested whether anyone here who worked on it knows whether it was a representative program for large scale Smalltalk applications? I remember the "frames" used to crash nearly continually, and keeping one open for a few days (often necessary on complex trades) used to be a real pain.
It wasn't Java that killed Smalltalk, it was a combination of ParcPlace's hubris and Visual Basic.
In the end, replacing those "green screen" CRUD apps was much easier in Visual Basic. For starters you could collaborate much easier with VB and visual source safe instead of spending thousands of dollars a seat on Envy/developer.
Second, the guys at ParcPlace simply didn't understand how quickly the pentium PC would decimate the workstation market of Sun etc in financial institutions and how good VB got in a very short space of time.
Yet here we are with another article blaming Java. An easy and lazy target to cover up for that elitism that pervaded the Smalltalk community back then and still does today.
It wasn't the cost of Smalltalk that was the problem, as there were low-cost implementations of Smalltalk, such as Smalltalk/V available on PC from the mid 80s onwards.
'Digitalk’s Team/V unobtrusively introduced a non-reflective syntax and versioned source code using RCS. Team/V could forward and backwards migrate versions of Smalltalk “modules” within an running virtual image.'
Magik
https://sworldwatch.blogspot.com/2011/08/smallworld-technica...
Smalltalk/V on DOS (1980s) had extra runtime royalties payments which was too expensive for deployment. So other 4GL languages like dBASE/Clipper/Foxpro or even C Language without those costs were more attractive.
The later Smalltalk/V for Windows did eventually remove the royalties but the base dev package didn't include ODBC database connectivity for free. (I think you had to pay extra for the Digitalk PARTS Workbench with db drivers?) In contrast, Microsoft Visual Basic had free ODBC drivers to connect to Oracle, Sybase, etc.
Of the dozens of companies I interacted with for LOB (line-of-business) applications, Smalltalk was never even a consideration. In the early 1990s, there was modest hype and popularity with Powersoft PowerBuilder which was more of a competitor to MS Visual Basic for internal corporate apps than Smalltalk or Java.
It's amazing how long enterprise software lives.
https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=...
That's something i don't recall (it was a long time ago).
Smalltalk/V was distributed as a nearly empty v.exe file plus a list of .dll files. As you developed your code it would get added to the v.exe so your stuff would always be clearly separated from Digitalk's. The .dlls were divided into two groups: basic system and development. The license allowed you to freely redistribute all files except for the development .dlls. If a client of yours wanted those for some reason they would have to buy their own Smalltalk V/DOS from Digitalk.
Except for the source to bytecode compiler, which was secret, the rest of the development system's sources were available. That meant that I didn't actually need Digitalk's permission to do what I wanted since I mostly wanted their sources (I had no idea how much Xerox would charge for the "real" Smalltalk but supposed it would be a lot more than what Digitalk might agree to). But I didn't want to take advantage of their not so well thought out license and upset them. Jim said he didn't think I would be able to port their stuff to the 68000 and didn't give permission for me to try, so I just went in a different direction.
"ODBC 1.0 was released in September 1992."
https://www.easysoft.com/developer/interfaces/odbc/linux.htm...
The smalltalkers scoffed, but the speed the VB guys got things done killed everything else. I ended up moving to a team that built a distributed trading system on DCOM, c++ and VB and while the tech wasn't lovable, it sure worked better than corba and java.
Its easy to forget what a monster VB was. Java took forever to mature in comparison. That websphere nonsense was a huge distraction for people who just wanted a crud app.
What you're describing was exactly what we hoped to facilitate.
Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps.
cries in Delphi tears
Access (with integrated VBA for what code is needed, and the whole market of similar desktop databases Access ended up dominating and eating, like FoxPro, Paradox, etc., each usually with their own proprietary language) is and were much closer to low-code/no-code for that than VB6; you could generally do simple CRUD completely no-code and complex CRUD much lower-code than with VB6 (since they generally included not only code-free UI design tools but also code-free and low-code DB modeling tools).
My first VB experience was porting a MS-DOS Clipper application to Windows 3.x.
So I also have some recollations of my own, like using Smalltalk/V and Oracle Forms with a VB like environment based on PL/SQL.
Yet, most consultancy being done by the likes of IBM and friends wasn't based on VB.
Smalltalk had been around for a long while (1972?) by the the time Java came on the scene, and if it hadn't become popular in ~20 years, was it worth sticking with it at that point?
I doubt that was the reasoning from upper management.
I think it started to be widely available with Squeak in the 90s -- at least, that was when I picked it up. I'd been interested before but couldn't really afford it.
That's an underappreciated and hard transition in requirements.
Academia doesn't know or care about so many things that are critical in the commercial world. And the commercial world doesn't care much about many of the computing philosophies academia argues incessantly about.
I think that's why you see a higher "win rate" from things that are seeded into actual commercial use ASAP: they evolve features important to their end users. See: VB (1991), Python (1991), PHP (1994), Ruby on Rails (2004)
There are some counter-examples, but it's really hard not to have glaring blind spots if you're not working in at least a commercially-adjacent domain.
Hmm, interesting. Your comment made me see the similarity between Pascal vs C and Smalltalk vs Java. Both Pascal and Smalltalk (and Basic, for that matter) gained some traction but ultimately faded in the face of more pragmatically-focused languages.
Really?
You'd expect "Ubiquitous Applications: Embedded Systems to Mainframe" ?
Alternate quite plausible explanation: Vendors of Smalltalk started realizing that Smalltalk just wasn't it, for whatever reason (the comment you're replying to posits that it was VB's existence vs. the high-cost, big-iron workstation more elite-based outlay that pervaded the Smalltalk community). When they realized this, they started looking to pivot to something else. VB was microsoft-owned and writing an entirely new VB-esque environment seemed like a daunting exercise, and didn't mesh with the strengths of the company (given that they went all-in on smalltalk, it's a self-selecting argument). It's not weird nor indicative of much that java was good enough that they all ended up there. It was simply the easiest thing to switch to once a vendor decides to ditch smalltalk.
I guess if java didn't exist, it is theoretically possible that e.g. IBM would have stuck with smalltalk, but then positing that this would mean smalltalk would have survived and thrived is _quite_ a reach.
More likely IBM and co would continue to believe smalltalk was a dead end and instead they'd all have gone with python or objC or some such, or a bunch of them would work together to make a java-like language of their own, or one of them would have and the rest would join in a few years later, or they'd all start publishing competing languages.
Who knows - but "they'd have stuck it out with smalltalk and smalltalk would have outgrown its problems, or the dev community at large would outgrow their obsession with VB / low-cost entry more blue-collar stuff and gone back to smalltalk" seems like a bizarre conclusion here.
ParcPlace had a successful 1994 IPO based on the high-price, deployment-licensing enterprise/legacy-apps market, & had configured itself with sales force & execs having a particular kind of seasoning. From there, how do you reconfigure, & bet the company, on another hypothesized future markets? (It's nearly impossible.)
And yet, ParcPlace soaked up so much of the Smalltalk expertise/mindshare, & even more after the Digitalk merger. IBM's VisualAge offering had a similar high-end focus. So no Smalltalk team of critical mass could fully chase the markets, & positioning, that Smalltalk's cousins Java (& later Ruby via Rails) did.
When Smalltalk needed a champion with the resources to develop it into broader & newer markets, the potential champions – both technical & business – were all distracted, diluted across projects, or (quite rationally) pursuing other lower-hanging fruit that offered more immediate legibly-capturable value in the mid- to late-90s.
Something like an inspired, before-the-curve embrace of open-source & shared-standards might've earned Smalltalk, the language, a bigger future through to today. But those actions might not have earned the then-extant relevant actors enough, soon enough, for them to have thrived or even survived.
> The World Wide Web diverted enterprise attention away from fat clients and suddenly web thin clients were the hot new technology. At the same time Sun Microsystems’ massive marketing campaign for Java convinced enterprises that Java was the future for both web and standalone client applications.
my anecodote continued to match what this article says:
> Even though Java never delivered on its client-side promises
you can say that again, within one dev cycle the original idea of delivering a web-based servlet was gone, as there was no support for any local machine / file / upload / etc access, we then delivered a fat java client where I ended up having to write basically all of Swing UX which hadn't quite been invented yet as the native checkboxes/ textareas / etc all performed like crap on the little 486/pentium machines we were deploying towards.
There was Visual Basic and Microsoft's COM. (e.g. when Microsoft adds a new API to Windows it adds a COM interface.)
Everything from TCL, Perl, Python not to mention LISP and Forth added ways to write object-based if not object-oriented code.
Smalltalk won the battle for ideas even though the exact syntax and runtime didn't win.
Elements of it left now, but the very bad bits (like derivation hiding implementation Dog knkows where) have thankfully gone extinct
Ideas from functional programming languages are now becoming mainstream.
I like it how pattern matching turned up in both Java and Python at the same time. If people quit hating on Java for a moment they'd see it was getting "ML the good parts."
Once people get past "A monad is like a burrito" and "this is the 20th blog post I've written about monads and I almost understand it now" that idea might get some traction too.
No, the article blames
- hardware requirements,
- problems with application deployment,
- technology choices by large companies,
- the demanding and fickle green screen to fat client niche,
- Smalltalk vendor blindness to the emergence of web browser as a business platform,
- AND Java marketing.
The Rise and Fall of Commercial Smalltalk - https://news.ycombinator.com/item?id=23397560 - June 2020 (137 comments)
Yes, C++ could be said to be much more concept-heavy but there is a difference: you can sit and crank out C++ code without first absorbing the huge pile of concepts that make up C++.
For Smalltalk or Lisp you need to first "get" the paradigm.
Isn't this true for all languages? It's just that usually people are getting experience with Fortran-like languages first, and it's not until later they get exposure to other paradigms.
I think it'll be exactly the same with C++ for someone who learned lisp first, the amount of concepts you'd have to learn seems impossible, just in order to read the code.
But I 'got' java. It's possible this is related to having dabbled with QBasic on a commodore 64, PowerBasic on an IBM-PC, and some x86 assembler, but my classmates without any experience universally just didn't really 'get' CAML or LISP and I kept catching them at thinking up the answer in an iterative way, and then dreading the 'hard part' of figuring out how to re-imagine that as functional.
Even when the exercises were designed specifically to be easy to write and understand in an ML variant.
I think the conclusion is that either society / community at large somehow prepares you for 'the paradigm' of iterative languages (I don't mean the IT world, I mean _all_ of society), or it's just easier to get it and start writing basics, vs. functional.
First, it's not the definition most people use for "functional programming". From Wikipedia:
> In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
> In functional programming, functions are treated as first-class citizens, meaning that they can be bound to names (including local identifiers), passed as arguments, and returned from other functions, just as any other data type can. This allows programs to be written in a declarative and composable style, where small functions are combined in a modular manner.
Second, aren't all languages based on lambda calculus, if you squint hard enough?
Literally Lisp.
(defparameter *my-var* 0)
(dotimes (i 10) (incf *my-var*))
You've probably seen the Y combinator given similarly to:
Y = λf.(λx.f(x x))(λx.f(x x))
Instructions for non-programmers are also imperative - "if this, then do this", "go to point 2.", "repeat if necessary".
IMO a more likely cause is (quoting grandparent) the lack of integration with standard versioning systems and the monolithic nature of the Smalltalk image concept.
So perhaps there's something to the argument that the difficulty of the language paradigm affects adoption.
https://www.tiobe.com/tiobe-index/
"Adoption" by the way is your word and does not appear on that page.
The next step for enterprise programmers is being a PM or an analyst or nowadays an Scrum Master.