If Smalltalk Is So Good Why Does Nobody Use It
c2.com
c2.com
* Numerical computation was too slow. Numbers used to be objects and all numerical computations followed object messaging. Ouch! This was eventually remediated but not before we'd dropped Smalltalk.
* Garbage collection was S-L-O-W. Your workstation would randomly freeze 30-60 seconds. It was that bad.
* The built-in windowing environment was an albatross in the early days of Windows and OS/2. Customers wanted a native look-and-feel not the weird (to them) Smalltalk window manager.
* Not everyone had yet bought into object-oriented programming, much less making everything an object. This was really bizarre at the time - even code was an object. Makes sense now, but few people were thinking that way then.
* It was strange. C++ seemed safer since everybody at the time knew and was comfortable with C programming. Little did we know the pitfalls awaiting us when using C++! :)
In the end I think the Smalltalk experience left such a bad taste in everyone's mouth that when these issues were resolved no one was interested in going back and giving Smalltalk a second look. Nowadays Smalltalk lives on in Objective-C. In fact one the shops I was in abandoned Smalltalk for Objective-C, which is one of the few instances I know of people using Objective-C outside of the Apple ecosystem.
Back in the 90s we were developing sales force automation software in VB3 (ugh!) which was by no means wonderful. Our stuff ran far faster on modest hardware than similar Smalltalk software running on (by the standards of the time) ludicrously powerful hardware. Delphi, when it came out, was far, far better still.
Smalltalk also seems to have accumulated annoying cruft faster than it got useful. Another large Smalltalk project I was involved in (as a UI designer) suffered from multiple incompatible class hierarchies. I wanted to make different controls that did similar things look similar, but it was impossible because some controls inherited from a 1-bit graphical library and couldn't be rendered in color, others from a 4-bit graphical library and couldn't be rendered in 256 colors, and others didn't respond to certain events in certain ways (e.g. action on mousedown instead of mouseup). It was an absolute nightmare.
The language may be fine, but the implementations of it were slow and bloated, and the class libraries were a disaster area. (Of course, the main company pushing Smalltalk at the time was IBM, which probably says something.)
They are both quite different languages, but both very heavily influenced by smalltalk.
ObjC is mainly popular because it's the language you have (or until recently had) to use to write for iOS -- although many developers come to like it for itself, and it certainly has been succesful at Getting Things Done. (I believe iOS itself is written in it as well, if not OSX too?)
Ruby had no such vendor lock-in, so the only reason to use it originally was if you liked it, although at this point the large library of open source available for it encourages it's use. (Of course people had to like it enough to write that open source for it, something got the ball rolling and kept it rolling)
Both ruby and ObjC take different things (with some overlap), but there are some things that _neither_ takes from Smalltalk. Looking at the things neither takes from smalltalk (eg the "program as image" that means you can't just use a text editor to inspect or use effectively in a generic version control system)... probably suggests some possible answers to why smalltalk hasn't been more successful.
I am not familiar enough with Smalltalk to be confident in my suspicions, but comparing to the more popularly succesful languages ruby and ObjC is probably a fruitful avenue to answer that question.
I think today the concept of the Smalltalk image and workspace has pretty much killed it, not the language itself. I use git for version control, I use GNOME as my desktop environment and IntelliJ as my IDE of choice, trying to do anything in smalltalk requires I transport myself back to the 90's.
GNU smalltalk is the closest we have to a smalltalk implementation that works well in modern computing environments, but there's a big lack of interest in the project.
Deleted comment
I figured if someone had built a VB like environment for Windows and priced it at $99, it would have done well. Closest I saw was Dolphin, but they did the old "database connection extra" crud. I wonder how many development environments have died due to that one pricing checkbox.
Smalltalk could be fast. Smalltalk/X was pretty speedy.
(PS - totally ignoring the native platform look and feel was foolish in the extreme)
And for both Delphi and now .NET, there is significant market for third party components that look purposefully non-native.
I know a lot of enterprise apps go off into the weeds, but their success is driven by external factors. Successful tools really need to appeal to a broad group of developers.
I really think a native widget version of Smalltalk that included the database access could have done a fine job, but it always seemed with Smalltalk that the NIH syndrome was so high and they could build their own things better. Its like they didn't respect any platform they were running on.
Because Smalltalk is an enclosed runtime (similar to Java, but much worse). We had to tell them how many users would be using non-developer editions of the runtime and they charged us for that.
Open source kind of killed this way the industry used to work forcing companies to find other ways of revenue, except for big corporations that kind of still work this way.
When you look at the market of tools today. Historically speaking, they were par for the course.
Anytime you need to "call for pricing", you know its going to cost.
I am currently doing mostly Objective-C-programming in Xcode, which is a rather simple IDE in this respect.
In the past I used more java, but at this time only simple changes were possible live (using Eclipse back then), for a lot of others I had to compile and restart anyway.
I recently tried out Pharo with a simple, achievable goal in any language worth using these days: fetch a document from a website, parse it, and display all the href's with titles. It was a very pleasing experience!
I basically evaluated the code I'd expect to use to fire up this application in a scratch area. Naturally it didn't work. It dropped me into an interactive debugging session. From there I just started writing and compiling the missing methods and objects. I kept doing this until my original evaluation just started working. No recompilations or context switches between editors and compilers and the like. Best of all I could just close down the image and take a break. When I booted it back up everything was right where I left it.
If given the opportunity to use it on a project I'd give it a shot. It was one of the most refreshing computing experiences I've had since I got hooked on Common Lisp.
The technical issues people cite are not so different with the dynamic languages that were much more successful (Perl, Python, Ruby, Objective-C, etc).
However, I do want to point out that adoption and quality need not be correlated. Haskell, for e.g., was relatively obscure till recently (and even now I would say very few people use it). But it is absolutely amazing compared to most mainstream languages.
The article linked makes some excellent points about business and other considerations and how it influences adoption of any language/tech (other than the quality itself).
The question itself can be reframed either as "Is Smalltalk good?" or "Why does noone use Smalltalk?"
The community is borderline insane when it comes to style, so you basically have to use a huge complicated emacs setup with a bunch of plugins just to be able to produce code that meets the bizarre style guides without manually messing with spaces all the time. That last point shouldn't matter since for your own code you can just pretend it is a normal language, but as soon as you want to make a change to an open source library you're stuck.
Much of this is similar to smalltalk, where the language itself was good, but trying to use it would drive you mad.
IMO, that's only true if what you get out of the compiler provides the same or less value as what you get out of the compiler for competing options. OTOH, the whole reason people choose Haskell over other languages is value-add from Haskell's compilation process. Spending some clock cycles at build time for that is, IMO, worth it.
That's clearly a problem.
> Simply put, absolutely nobody has put any effort into making GHC fast. Only into making it produce fast output.
OTOH, as annoying as it may be to developers, on the assumption that code will be run more frequently than it will be built, that seems like priorities being in the right place.
C++, Java, Objective C, Ruby borrowed OO ideas from Smalltalk to varying degrees. Eventually, you could get most of the benefit of Smalltalk OO ideas without actually using Smalltalk.
Swift, Rust, Scala borrow functional programming ideas from Haskell (and ML) to varying degrees. My hunch is many programmers will encounter and use functional programming constructs in those languages, without ever programming in Haskell.
To complete the comparison, Smalltalk is still arguably OO in its purest form, as Haskell is probably the purest embodiment of the functional programming paradigm. But in both cases, most programmers are happy to adopt some subset of those features in languages more similar to the onese they already know.
Meanwhile, a lot a people hate on C++, which they're only able to do because they learned its nuanced spec, which they only did because it had already reached critical mass in the wild, because it worked everywhere and was, despite the complaints, comprehensible, if hard to get perfect in the language-lawyer way.
(I don't have any particularly strong opinions on Windows myself; it just seemed an apropos example for the Hacker News crowd. There are a million other examples of the same type, of course.)
To my (C-tainted ears), the affirmations of support generally tend to sound something like, "It's better because its (modern|buzzword|safer|buzzward|technobabble|compact)."
I am not suggesting that these languages do not have tangible benefits, but I do wish their supportors would be a bit more concrete while describing them.
Something that isn't used at all (or much) has very low utility.
Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell programmers that want their library to be widely used may start greenfied projects in Rust instead of Haskell.
You are looking at it from a Haskell -> Rust conversion cycle, when that isn't really important from either a numbers standpoint or how Rust is positioning itself.
Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturity and library ecosystem that Haskell currently has.
One might catch a few people who absolutely need manual memory management, I guess, but my experience is that this is often an excuse and those who are seriously interested in using another language find ways around the problem. For OS kernels and the like Rust has an advantage, but again that's a tiny niche. Rust's C FFI might be a bit better, but honestly Haskell's is rather good; I can't see that making the difference. And if you find the safety or the type system compelling, surely you've already moved beyond C++.
I'd like to be wrong - I'd like to see C++ programs moving into better languages. But I think a need for manual memory management is very rarely the real reason people are still using C++ - and if it's not that, what can Rust offer that wasn't already available?
Rust has emphatically never been "Haskell with manual memory management". That conception is entirely incorrect, typeclasses or no. If you must frame Rust in terms of prior languages, consider it to be an ML with an extreme focus on zero-cost abstractions and pervasive, memory-safe concurrency.
When will Rust be pushed by an OS vendor?
That seems to be the main selling point for Rust, anyhow. Zero cost abstractions, predictable data sizes, well defined memory scopes, etc.
Java should never have reached where it is today. Im not hatting on java btw. Just historiclly speaking, java was a embeded language that was pushed for the internet. At the same time Sun had the well advanced Self project in devlopment. One of the major reasons that java was selected was its small stack based bytecode.
Self was the hotbed of compiler research and could run rings around java. Self is a small language and you need less lines of code then java. Self would probebly not have been much heavier on the wire.
So why did the people at sun push Java and not Self? I can not explain it. The only explaition, is that they just did not know what they have. Anybody has a better idea, is there something I completly misunderstand?
A lot of the people behind Self went on to work on the JVM JIT and later the Chrome V8 engine. Self produced many influential ideas in the JIT space like polymorphic inline caches and deoptimization and stack rewriting. Some of the papers published by the Self group at UCSB are fascinating.
Many of the people that worked on Self later worked on Strongtalk, that was bought and is the bases for the current JVM, and yes now everything that was in Self is in the JVM.
So my point is, why not just start where they ended up anyway. In one of David Ungars talks he said something like "they probebly just didn't know what they had". Thats about the only thing that makes sence, but maybe somebody knows more then me.
Sure hardwar got faster as well, but im talking quality of the VM.
Using Squeak as an example, it is very-much a virtual machine. If I want to work on a new project, I might have to create a new VM image or something. It's like an OS and language boiled into one thing, which simply doesn't work.
There are more classical approaches to SmallTalk these days, but most of the literature on the language is oriented toward the Squeak approach; dedicating half the bloody book to working within the OS! Just let me use Vim, I don't want to use your shoddy editor!
But there are some other really interesting alternatives that IMO keep with the spirit: Io (io-lang.org), Ioke (defunct now, ioke-lang.org - some awesome ideas IMO) and Squeak which is being actively developed.
I'd recommend checking out some of these, I think you can easily install io via brew on Macs and used to be able to install joke as well. They improve syntax and/or add significant language features.
One of the answers could be that almost every OO language borrowed some concepts form Smalltalk and implemented them in a less "cryptic" (or esoteric) way. Take a closer look at that Objective-C. Erlang's (non-OO) modules and message-passing primitives were also influenced by Smalltalk.
Company's like JPMorgan (Currency Trading), Booz Allen & Hamilton (Currency Trading), Sprint (Network Topology and Configuration), Digital Switch Corp (now Alcatel) (Digital Cross Connect), TenX Technologies (C source code maintenance and analysis tool), American Express (Full IDE for a custom in-house Credit processing language) and Nortel (Meridian PBX line Configurator as well as Configurator for the Nortel Wireless Modules used in cell towers) have used Smalltalk to great ends and gotten competitive advantages and accomplished great things with Smalltalk.
There were lots of others projects that used Smalltalk to create systems that they had failed at previously or did not want to tackle due to the enormous complexity. OO and specifically Smalltalk gave them a way to implement these systems in an Agile way, long before Agile Manifesto was dropped onto the world. Remember ST at the time embodied the most mature implementations of the OO paradigm and it's power was not meet for many years. No other language gave the bang for the buck overall. C++ was still being standardized thru the early 90's. At the time and up until Borland shipped their Turbo C++, most compilers were incompatible with one another and/or generated C code because they were based on ATT's C-front system, which itself was being fluidly developed.
I worked on those examples listed above for those companies and knew of many others working on other projects. I also happened to work with C++ from 1989-1993 while porting tools such at SUN Tooltalk and SUN Net License to IBM's AIX boxes as well as Porting the Mentor Graphics ECAD products and core libraries to AIX and DEC Ultrix and OSF/1. We had 14 hour compile times, even with 128 Meg of memory (which at the time was huge) using the $150K box on my desk. I had also worked with Obj-C on the NeXT systems and IBM RT system and several OO Lisps including CLOS.
Each of those systems had good points and enabled different things, but Smalltalk and the tools it provided and the amazing productivity that we were able to accomplish was amazing. Fixing bugs in the debugger, stepping back one call on the stack-trace and continuing on (no stopping the whole program and starting again) [Fix and Continue that worked every time, not just some of the time like the C++ and Java versions), adding capabilities to the system itself, being able to inspect and see anything at any time, seeing all the code for the system and adding to that were amazing and still are.
The title is misleading in that "Nobody" is not the right word for the title. It's safer to say "few" people use it. But those that do have reasons as diverse as why there are so many languages that programmers use now and why the number of languages being created is going up. We as programmers use languages for many reasons, including their relative power, alignment with our own thought processes, libraries available, community, religion, syntax preference, etc.
Don't buy into group thought when looking at any language. I also think that no one language is going to solve all your problems. Much like we have AWK, SED, etc. we can use the language that helps us in that moment. Smalltalk is just one of those languages that is available and for many uses it still is very applicable.
Sam Griffith Jr.