If Smalltalk Is So Good Why Does Nobody Use It

As a haskell user, I would say that you're overstating how amazing it is. The language is certainly fantastic, but the tools are so awful that it almost makes me willing to use go! GHC takes ages to compile code, as well as easily a couple of GB of RAM. When you're longing for the days of C++ because your build time was so much faster, something is seriously messed up. Cabal mostly stinks, ocaml's cabal inspired packager is far better despite being much newer and having fewer resources invested into it.

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.

Don't get me wrong - I'm thankful that I got to use Smalltalk in my career. It was incredibly expressive and productive - maybe the most productive I've ever been. But, time marches on. There are simply more people working today on python / node / to maintain and improve those tools plus making it easier to find a programmer over a Smalltalk programmer.

Smalltalk was and is used for many advanced, super complex and difficult to understand requirements based systems. Much as Lisp and Scheme are. It sprang the ideas of full OO onto the programming community, it's guru's brought us Agile development techniques, Refactoring tools, ChangeSets (Git has this now), Everything is an Object and many other ideas and concepts prevalent in today's languages and tools. Many languages freely admit the inspiration of Smalltalk to their ideas and have expanded on Smalltalk's ideas. Some people have continued to expand Smalltalk itself. Even it's original creator (Alan Kay) hopes for a better system than Smalltalk, but even recently he says he hasn't seen it yet and has called Lisp the "the greatest single programming language ever designed".

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.

The Java HotSpot compiler was originally worked on for Smalltalk before SUN bought the company. It along with the ideas from SELF certainly helped improve JIT systems and dynamic compilation solutions in the late 90's and all thru the early 2000's

> It is 100% certain that GHC contains at least one memory leak that has been unaddressed for years.

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.