Maybe the next Tim-Bernes Lee could use it to develop new protocols + a browser and create a safer and secure WWW-alternative?
Maybe the next Tim-Bernes Lee could use it to develop new protocols + a browser and create a safer and secure WWW-alternative?
1. The image-based paradigm [1] holds it back. Using Smalltalk, there's quite a change in development style, the existing development tools (text editors, version etc) mostly don't work [2], and deployment is at least slightly different.
2. The unfamiliar UI (mostly Morphic) looked very different.
3. The different (but incredibly simple) syntax looks strange to newcomers.
There are paid tools that fix some of these, but they never quite caught on with lots of momentum, and they were used mostly in bigger enterprise shops. The biggest might have been IBM VisualAge (for Smalltalk), which later morphed into IBM VisualAge for Java and then Eclipse.
[1] The image-based paradigm is really really great. If you haven't experienced it before, give it a go. It's worth it even if you are never going to use Smalltalk. [2] There's been effort to get git to work. I haven't been tracking it, but this was only in the recent few years.
[1] There was in fact an article written by someone who was an expert which did the rounds of /r/programming back in the day. But good luck finding it now of course.
Eclipse to this day still has a Smalltalk like code browser for Java code.
Also in the early days although the JDK was free beer, all good IDEs were commercial, Eclipse and Netbeans only came a few years later.
[1]https://en.wikipedia.org/wiki/Inferno_(operating_system) [2]https://en.wikipedia.org/wiki/Limbo_(programming_language)
Java was web, Perl was web, and ST wasn't ready. Java and Perl were free as in beer, ST was expensive. I think ST hardware was expensive too. ST is very different from C & C++. ST had multiple vendors too.
I'm pretty sure that late-'80s/early-'90s ST was largely run on commodity (or fairly-commodity) hardware: PCs, Macs, Unix workstations. It was commercial Lisp that tended to be tied to dedicated hardware. IIUC Smalltalk did have a then-expensive appetite for RAM though.
The commercial STs of the time weren't good as CGI languages like Perl and PHP for the same reasons they weren't suitable as Perl-style scripting languages in general. Meanwhile, behind the hype it soon turned out that Java applets were not ready for prime time either, while servlets were something that could probably have easily been replicated in ST (and for all I know, likely were).
site:www.reddit.com smalltalk leoc
one of the results is:Bambi Meets Godzilla - "I watched Smalltalk die."
https://web.archive.org/web/20080706101400/http://www.oreill...
It holds it back because it's a bad idea, otherwise Access/VBA apps would rule the world by now. It's a great environment for single developer RAD tools but it's horrible when you're trying to scale the team up because tools like git don't work well and you often don't want data to be shared between instances.
git is great in many ways, especially how it lets multiple developers to work more effectively on the same code base. But native version control tools on Smalltalk, while they might not work as effectively for large groups of developers, has native support — it can support things like versioning at method level.
Rather than arguing Smalltalk is the best or that it is bad, I rather focus on what I think — it has many great features, it's just that it's so different that it can't ever be popular, at least not for the foreseeable future.
And while the code is exposed in code browsers (some kind of IDE/text editor window) in the image, and not exposed as text files, they certainly can be. So I'd imagine it's just a matter of exposing those into files (or still classes and methods as separate "entities") and commit those into git with a bit of markup.
Saving the development image and deploying it directly is also not done that often because the development image contains things that can stripped off, e.g. development tools or object instances you use during development. Squeak and Pharo is usually distributed in various flavours, loosely — full and minimal images (I might not get the names right). So you take the former and install packages for development and the latter + packages for deployment, or you can build your own from the minimal image.
But through this you can see how different it is and while it's great in many ways, some of the differences make it harder for newcomers to start and harder for everyone to use it in production.
I forgot to mention Dolphin Smalltalk http://www.object-arts.com. It used to be a paid product, running on Windows. It has been open source for a few years now. I think product sales wasn't sustainable for the owners. But for several years, it is was the best Windows thick client development tool. It's a great example of Smalltalk well-done. You have the same image-based approach, but the windows are all native and familiar looking, so basically a multi-window development IDE. There's a deployment tool that helps you to strip down your image and build it into an exe (which was basically the Dolphin Smalltalk image + the shrunk image). It might still run, maybe it looks a bit outdated, it was actively developed until 2004 or so. If it still works, it's a wonderful way to experience Smalltalk.
1) Smalltalks have a text output format for code chunks
Aside from the code, all other user data is message sending, so it could also be serialized (if needed).
For a more "traditional" smalltalk for js, see:
>Live, immersive environment: Immediate feedback at any moment of your development: Developing, testing, debugging. Even in production environments, you will never be stuck in compiling and deploying steps again!
That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps.
Yeah, that wasn't it. Maybe you weren't there? This sounds like a third hand experience of the era.
Functional languages have been used in major programming projects (and had popular apps, from Eclipse and AutoCAD) for decades before Ruby, not to mention AI work.
Besides, PG's company used CL to build one of the first web stores way before Rails was even a thing.
>That doesn't appeal to me at all. I don't want to be debugging in live environment, I don't want users or testers having that power and I don't get stuck in compiling/deploying steps.
That's because you haven't used it.