Hacker News Reader

Comment by pjmlp | Hacker News Reader

It was certainly Java, as many early adopters were former Smalltalk vendors, e.g. IBM.

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.

As one of the original developers of VB, what you wrote here really touched me.

What you're describing was exactly what we hoped to facilitate.

Your counterargument applies to your work place only though, do you know of other companies that did the same?

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.

cries in Delphi tears

> 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.

And a lot of the time you could just as well embed pieces in other languages in your Access application connected to MSSQL (or oracle or whatever)

I used VB 3, VB 6, Delphi 1.0, and C++ Builder.

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.

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.

This certainly doesn't prove your case.

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?

IBM and Oracle were early Java adopters, and IBM repurposed all their Visual Age products on top of Java.

I doubt that was the reasoning from upper management.

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.

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.

> 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.

Guido wrote Python (and worked on its predecessor, ABC) while working at academic research institutes -- CWI, and later CNRI.

> exactly what you'd get

Really?

You'd expect "Ubiquitous Applications: Embedded Systems to Mainframe" ?

https://www.davethomas.net/papers/ubiquitous1995.pdf

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)

Reply on news.ycombinator.com