I worked on one of the larger Smalltalk project in the late 90s, an application of the HP OpenView Network management suite. Using Smalltalk was in principle very productive,non-Smalltalk people were always amazed seeing us changing code in the debugger and just continuing running the application without a restart. The problems were rather coming from the lack of integration with standard versioning systems and the monolithic nature of the Smalltalk image concept. Later on when ruby started to become popular, which in my opinion was very similar to Smalltalk, but had a module concept and not a monolithic image concept.
Several years ago, I had lunch with a former Smalltalk dev who gave me his perspective on what happened. He recounted it as IBM's entrance into the Smalltalk world, which wold be today's equivalent of a FAANG member deciding to compete in your niche. This caused several major Smalltalk providers to believe they had to unite in order to compete. Internal conflict within the Smalltalk providers eroded development and when IBM changed to push Java ("which falsely claimed to do what Smalltalk already did, like be able to run on a toaster" is the quote I roughly remember), this led to the collapse, when others followed IBM's lead.
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.
Should discussions about the history of Smalltalk mention Objective-C? Was it the most successful Smalltalk-inspired language after Java? Ironic that because of the quirks of corporate decisions, both became the initial languages for the most successful smartphone platforms- previously most mobile systems from Palm to Symbian were developed in C++.
I think so, yes. My impression is that Smalltalk fans lament the loss of the tooling around the language more than the language itself, so they're not as likely to focus on Objective-C's success -- but I suspect there's a case to be made that the underlying object and message-passing concepts Obj-C borrowed from Smalltalk enabled a lot of NextStep's rapid interface builder technology to be as good as it was in the 1990s, and that technology kept them alive long enough to be bought by Apple, rejuvenated the Mac, and laid the foundation for iOS.
Not really? JavaScript doesn’t have conses so it’s not very lisp like in practice. What is gets from scheme is closures with lexical scoping (real closures). It’s closer in style to self, but js is textual instead of image based so that’s very very different. The other aspect of js that’s very different is it’s massive commitment to a synchronicity, which smalltalks generally don’t have
The time I spent doing commercial Smalltalk development was some of the most productive and enjoyable of my career. Couldn’t stand the company I was at, but loved the work itself. Later did some consulting with a company that was moving everything from smalltalk to Java because they didn’t feel like they could find devs or stay current if they didn’t. I still feel like we lost something or like other languages haven’t quite caught up in their own way, even though I know the world won’t go back.
As a counter-point, I did some Smalltalk development back in the 90s. It was slow, verbose, couldn't integrate with CVS, required you to use their editor, and produced a UI which was completely non-native. The development environment was a world unto itself (like Java actually), and cost a small fortune. We migrated to C++ pretty quick.
Same here, I loved the language and the concepts behind it but the companies that populated the eco-system were terrible and users did not like the end result due to the lack of native interfaces. We too went the C++ route (specifically, Borland C++ Builder, which was very fast and easy to develop with) and never looked back.
"Borland C++ Builder" I remember that. It was awful.
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
Compared to the alternatives it was great, it compiled super fast and was very reliable. The MS windows C/C++ compiler drowned you in boilerplate, Borland just got out of the way and got you to focus on the job. I never did any deep dives into the OO solutions, for me it was just a way to get an Irix application ported over to Windows with minimal hassle.
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.
The only two things I miss and they are closely related:
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.
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).
What are the innovations brought by Allegro and Lisp Works, relative to Clojure? Just asking as I haven't heard about those, I only have experience with Clj.
Before Eclipse, IBM had Visual Age for Java until early 2000's, repurposed from Visual SmallTalk. There were no source files and no VCS in the usual way, it was all integrated into a "database" giving you modal development experiences and anything not anticipated by the Visual Age devs was impossible :shudder:
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
Smalltalk is still technically used in a commercial setting at JPM , though mostly due to the incredibly long timeframes banks work on. I was tangentially involved with it last year via an upstream application that fed into it and don't have particularly pleasant memories of it (probably mostly due to the massive amount of cruft attached).
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.
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).
What if there was a free open source version of Smalltalk (with an option for using script source files instead of a GUI) for Unix in the early 80s? Could it have become the defacto Unix scripting language instead of Perl?. Might Netscape have put it in the browser? Would there have been a raison d'être for Python or Ruby (as more OO options to Perl)?
Did my final year project in SmallTalk-80 on the SUN systems. Was that really thirty years ago? I recall the funky UI that you could edit from in the UI itself so it was like self-modifying code. Very freaky!
To me the simplest explanation is that Smalltalk is just too concept-heavy for the average developer, just like Lisp is.
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.
> 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.
That's a fairly non-standard definition of functional programming, for two reasons.
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?
Also lisp isn't actually based on the lambda calculus (for one thing the lamdba calculus doesn't have recursion!! (besides through the Y combinator). Lisp is also evaluated in a very different way than the lamdbda calculus. Lisp has a syntax to declare function literals which takes its name from the lambda calculus, and you can express the lambda calculus relatively cleanly in lisp (i.e. you can write lambda expressions in syntactic lisp) but that's really the only connection.
I don't think that's true when lambda calculus is regarded as a "library" of certain objects and concepts added to mathematics. Then the assignment operator is available.
You've probably seen the Y combinator given similarly to:
Y = λf.(λx.f(x x))(λx.f(x x))
where this Y = business isn't part of lambda calculus per se, but it's available because this is mathematics; existing mathematics notation that doesn't conflict with lambda calculus, like being able to equate a symbol and expression, hasn't gone out the window.
Yes, the conceptual framework is pretty minimal (especially compared to C++). Still you need to "get it" to write even a simple conditional or a loop (I mean sending a block of code to a boolean or a block of code).
It's like "high-concept" in film, which is a fancy way of saying "weird". Those who "get it" get it, but most do not, and that is true of Smalltalk, necessitating the rise of Java.
I'm not sure this is true. Sure the syntax of the lanuage is simple, but smalltalk is useless with just its syntax (it doesn't even have ifs or loops!). You only have a real smalltalk with a class hierarchy defined, and then suddenly smalltalk becomes uber conceptual. MVC (and its infinite variants), meta-object protocols, object-relational mapping, smalltalk loves is high concept stuff.
By that argument, Rust would never have seen the rate of adoption it has.
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.
I started to write a list of reasons why no one should use TIOBE for anything, but suffice to say according to same web page you got your figure from, Javascript has 2.66% "adoption":
Smalltalk failed because at your typical enterprise there rarely is any incentive to do better than doing pseudo procedural code in java/c#/python/whatever which in smalltalk is possible but hard.
The next step for enterprise programmers is being a PM or an analyst or nowadays an Scrum Master.
