Its incredible to me that the guys who lament the fall of Smalltalk always blame Java.
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.
only an anecodote for me but I was on a team in 1997 or so where we exactly were brought in to a financial client to write for them a "thin client" in Java, explicitly using the fact that Java was so strongly hyped that it would allow the team that was hiring us to poke a hole in their existing VB codebase and break up some of the calcification in their technology organization. In the early meetings we were pitted directly against a tech manager there who was very strongly advocating for Smalltalk; we as an outside vendor were allowed to win that argument that Java / "thin client" etc. were all the way, literally verbatim to the article's paragraph:
> 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.
Many such cases. The download & run experience for Java/JRE fat client apps was also awful for so long, at least for mass consumer end users. (Captive corporate userbases could be shepherded through the steps.)
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.
From my seat at ParcPlace 1993-1996, I'd offer the synthesis: ParcPlace's legacy-enterprise-apps-focus prevented it from properly chasing the pure-internet opportunity that Java pursued.
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.
Thats not my recollection of the era. VB was was widely scorned but it was incredibly productive. At my workplace at the time, when smalltalk collapsed as a viable dev environment, it was largely replaced with VB pointing at the sybase databases we had.
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.
I don't think it's the consultancy that's under question -- it's the question of what RAD tools that companies that weren't necessarily "software first" reached for when they were working on stuff in-house. Banks, manufacturing companies, telephone companies, places that decided to roll their own rather than call up IBM or Accenture (well, whatever Accenture's predecessor was). I worked at a place like that in the 1990s, a successful CLEC with a huge IT department that wrote their own custom software for order tracking and sales management -- and they wrote it in Visual Basic and Access. That's a market that Smalltalk might have been extremely successful in, but it really was basically owned by VB/VBA in the 1990s.
My perspective is from the Banks, manufacturing companies, telephone companies, places that decided to call up IBM or Accenture (they already existed in 1990's).
My recollection matches yours. Smalltalk was too expensive and hard to program user-facing apps as quickly as VB or C++ with MFC. So front-ends were either VB or C++/MFC if speed was needed on the front end, and C++/DCOM on the back end.
I can't speak to smalltalk, but I can for Java vs. VB. VB was big in Microsoft shops. Java wasn't anywhere close to as easy or viable for desktop CRUD apps then (could be argued if ever).
Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps.
> Language aside, I could argue that VB6 was the closest the industry has gotten to low/no code for complex CRUD apps.
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).
Great point. In my mind I often lump VB (pre .net) together with Access since so much of the VBA was transferable. A common workflow was to have Access + VBA, until it go unwieldy, then VB + Access, and finally VB + mssql.
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.
Perhaps all the folks who left Smalltalk gave up on it because they concluded it wasn't going anywhere. If so, would that be the "fault" of Java?
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?
Smalltalk started to be generally available (outside research labs) in the mid-80s.
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.
Smalltalk's history seems like exactly what you'd get if you incubated something exclusively in academia, then tossed it out into the commercial world.
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.
> Smalltalk's history seems like exactly what you'd get if you incubated something exclusively in academia, then tossed it out into the commercial world.
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.
When I got roped into using VB at work in the early 90s it didn't even occur to me to argue for Smalltalk (as far as I remember). If I'd had a free Smalltalk to satisfy my curiosity first, that could've been different, though there'd still be barriers like my manager's familiarity with Basic.
But even when it became widely available it still wasn't widely interoperable (with developer tools, filesystems ..). Interoperability is what objects are supposed to be about. The shame is that we have ended up with microservices which is such a crude developer experience (and serverless which is worse again)
> instead of spending thousands of dollars a seat on Envy/developer.
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.
>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.
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.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
My very first paid programming gig was doing Powerbuilder dev for a bank. IIRC it was basically a very rich data table widget with a scripting language wrapped around it.
I am pretty sure it wasn't the case. I phoned Digitalk's Jim Anderson to try to negotiate a license to let me use their image with my 68000 based virtual machine (this was before Digitalk had any Mac versions) so I paid very close attention to the details of their licensing agreement.
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.
No but the only credible source control tool for VisualWorks was envy/developer. Otherwise you were filing in and out classes and trying to share your changes. It was a disaster.
'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.'
Licensing costs were most definitely an issue. The Smallworld GIS system was written using a home grown language and VM because that was more economical than issuing every user with a suitable Smalltalk licence (because in the early days every user was expected to potentially be writing code to analyse their data).
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.