The Smalltalk Revolution

When I was even more of a newbie programmer than I am now, I stumbled across Pharo and the Seaside framework. Both of them have excellent tutorials which taught me a lot about MVC, OO, and proper application design. I went on to build a prototype in Seaside and found it to be a very enjoyable experience.<p>For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point.<p>In Seaside&#x27;s dev mode I can toggle viewing all the components that make up the currently displayed page (a page isn&#x27;t a textual template, but is constructed from objects). I could manipulate those objects in the browser and see the effects of those changes immediately. This was useful both in exploring solutions to problems and in debugging code.<p>Having experienced such tools, it&#x27;s hard not to miss them when programming in another language. I used to use Light Table with Clojure and Javascript to kind of recreate the effect, but what the author writes is true: abandoning your familiar textual tools lets you do some really awesome things. It completely changes your development and debugging workflow.<p>I&#x27;d love to be able to program in Smalltalk professionally, but I really couldn&#x27;t find that kind of gig (especially entry level) in my area. But even if you can&#x27;t see an immediate business use case, just spend a weekend going through the Pharo and Seaside tutorials. If learning lisp is important &quot;not because you&#x27;ll use it but because it will forever change you&quot; (to paraphrase) then learning Smalltalk is important in the same way. Just be aware that when you have to go back to another environment, you might be a bit sad. :)

<i>Smalltalk is not the Grand Old Man of programming languages, but the future of software development created 40 years in the past.</i><p>Yup. And that future was realized in systems less monolithic than Smalltalk. The WIMP interface made it to most major platforms by 1990. Objective-C and later Ruby swiped Smalltalk&#x27;s message passing semantics and basic object model and freed it from its all-or-nothing execution environment. And tons of languages (not least of which is C++) have taken Smalltalk&#x27;s cue on object oriented design.<p>What more is there left for Smalltalk to accomplish? That&#x27;s not bad, for a language which basically never made it out of PARC for two decades!

<i>Software developers are human. Therefore, they are also creatures of habit. Once inured to the clumsy use of files and folders and lifeless, non-dynamic programming methods, once they grow emotionally and intellectually attached to their file-based tools and infrastructure, they are incapable of appreciating any other way to do things. They’ve become so efficient at doing things the hard way that it seems, to them at least, the best way to write software. These aren’t stupid people; they are simply habituated.</i><p>Yeah, it&#x27;s the usual condescending &quot;If you don&#x27;t see the stupendousness of our approach, it&#x27;s because you&#x27;re not enlightened yet!&quot; that we also get from Lisp and Haskell types. Spare us.<p>The rest of the article wasn&#x27;t bad, but that one paragraph really turned me off. If I don&#x27;t do it your way, could you <i>please</i> stop assuming that it&#x27;s because I don&#x27;t know any better? It may be because I actually <i>do</i> know better.

What killed Smalltalk was the $10,000&#x2F;seat licenses. There was very limited scope for anyone to &quot;kick the tyres&quot;. But it&#x27;s OK, we have C++14 now.<p>Don&#x27;t get me wrong I would <i>love</i> to use Smalltalk in anger. But that ship has sailed. Fight the battles you can win.

I used SmallTalk for a while and loved it but when I moved on to more traditional programming I never missed the SmallTalk days. I did learn a lot of stuff that I applied later on, though. Exact same experience with Lisp.

First, let me say that I love Smalltalk. It&#x27;s a beautifully language that follows such a consistent design philosophy. It demonstrates the power of orthogonality, generalization, and abstraction in the design of programming languages like few other programming languages have. I studied and studied the blue and green books in the eighties and they provided me with my first look at meta-object level programming.<p>What are the challenges of programming and how does Smalltalk address them? It seems to me that our big challenges are correctness, how we know that our programs meet the specifications; performance, across a wide range of hardware (highly parallel, wide instruction words, low power, embedded, etc.); programmability, this includes expressiveness and ease of learning the language and its fit with the problem domains where it is employed; and finally, maintainability, which entails the life-cycle costs of programs written in the language.<p>Smalltalk was a very important and influencial language in the history of computing. Is it the future? How does it address these important issues? Spinning some user interface component doesn&#x27;t impress me. Work on immutable data and STM (ala Clojure) impresses me. Functional programming (e.g. Haskell) impresses me. Large numbers of useful packages (like Python) impresses me. Highly efficient compilers (like modern Fortran, C++, Ada and JITs like Javascript and Lua) impress me. Being able to modify a running program doesn&#x27;t. How in the world does one untangle the train wreck of all the incorrect intermediate calculations when a program finally produces a wrong answer?<p>Smalltalk was a darling of the Computer Science community decades ago. Implementations have been around for a long long time (I have still have my Smalltalk&#x2F;V 286 manual from Digitalk, it ran on my IBM PC-AT). It would surprise me if a language that has evolved as little as Smalltalk has would suddenly, after all these years, be the future of programming. Hasn&#x27;t it already had it chance?

Dependency management. Source code control. Continuous integration. Deployment.<p>These tend to be challenges, or at least sources of complaint, for image based development environments like Smalltalk and Lisp.<p>Have modern Smalltalks successfully addressed these issues? Even if Smalltalk has its own tools to address some of these, are they as good, as flexible, and as well supported as the tools available to work with plain text source files?

I guess I&#x27;m the exception in that I spent a few years in Smalltalk in the mid 2000&#x27;s and thus never viewed it as irrelevant.<p>Sure, not used by the, &quot;cool kids&quot; in SF, but still used.

hey I know smalltalk. I&#x27;m really good at it and I like it.<p>Does this mean I can get a job now, despite having learned the language in 1996?