SmallTalk

Opinion about Smalltalk language?

Aug 27, 2019 https://www.quora.com//Opinion-about-Smalltalk-language/answer/Phil-Jones-He-Him

It's in the top 5 without question.

The complicating factor with Smalltalk is that the things that really make it great aren't quite the features you think of as "languagey". Its greatness isn't about syntax or semantics.

It's about the whole system. The liveness / the GUI / the development tools / the "everything is always available for inspection and reflection and reuse". The everything (even compilation) happening at "run-time" etc.

That's what makes Smalltalk so amazing. And different from languages that are pretty similar in other ways.

If you don't care about or want that live system then Smalltalk, say in the form of GNU Smalltalk, is not really an improvement on something like Ruby, which copies much of Smalltalk's superficial semantics. In fact Ruby is one of the reasons Smalltalk isn't more popular. It's a "good enough" Smalltalk substitute in many places where people would otherwise hanker after a Smalltalk like dynamic OO language.

But Ruby isn't a "better Smalltalk". Because Smalltalk is so much more than a dynamic OO language. It's a whole world. And it's that world which is amazing.

BTW : these days I'm speculating a lot about what other great ideas / languages could be "cross-bred" with Smalltalk to have that dynamic world.

What if we could have a Smalltalkish language / world with Haskell Algebraic Data Type-like schemas to define assemblages of classes. The language would allow assemblages of objects to be checked against schemas at runtime (much like Clojure's Spec). The whole system would be as live and dynamic as Smalltalk but with a "type-safety" closer to Haskell's.

What if we could have a Smalltalk-like system where mutable state was more explicitly controlled. Eg. only classes inheriting from MutableObject were mutable. (And they would act more like Clojure Atoms) ?

Or, what if we could build a Smalltalkish world out of Erlang Actors or Prolog Pengines. Object citizens of the world would have their own light-weight threads. Would communicate only by passing values to each other. Perhaps Pengine-like objects would be programmed logically.

What if a Smalltalkish world would be "stigmergic" keeping mutable state only in a global blackboard or tuple-space?

The idea of the Smalltalk environment, the integration of OO, of language, and live system is absolutely up there in the top 5 of greatest programming language inventions of all time.

But it would be fascinating to try to improve on that with some of those other top 5 great ideas.

Why did the Smalltalk programming language fail to become a popular language?

Aug 28, 2010 https://www.quora.com//Why-did-the-Smalltalk-programming-language-fail-to-become-a-popular-language/answer/Phil-Jones-He-Him

It's definitely the incompatibility with the existing infrastructure of file system / editors / source-control etc.

One other thought ... this insane insistence on the three coloured mouse buttons. Even as recently as a couple of years ago you saw documentation written in terms of the colours, which expected me to remember which colour mapped to which button (or to paint my laptop). A bit of concession to the emerging Windows / Mac standards for mouse use (and icons on windows) might have done wonders.

Update : In another conversation I developed this meme a bit : SmallTalkUnix

If Smalltalk is so great, why is it used by so few compared to languages like Java and Python?

Apr 30, 2019 https://www.quora.com//If-Smalltalk-is-so-great-why-is-it-used-by-so-few-compared-to-languages-like-Java-and-Python/answer/Phil-Jones-He-Him

As I've said elsewhere. Smalltalk is a wonderful, but "stand-offish" language.

It does best in its own world (its own GUI, its own tools, its own conventions for how to use tools). It really is the "cat that walked by himself"

Javascript was there where you needed it, and when you needed it : in the browser.

PHP was there on your hosting company. As, later on, was Ruby on Rails.

Python wrapped all those science and machine learning libraries you wanted to play with.

Java's pitch was "write once, run anywhere" ie. it was sold as your solution for developing without worrying about the fragmentation between Windows, Unix and Mac.

Smalltalk's pitch was "Smalltalk is better than your other languages. Especially for kids"

"I want to make my web-page interact." "I want a scripting language on the server to talk to a back-end database." "I want to use TensorFlow to classify my data" "I want to write a desktop app. that runs on both Windows and Mac".

These are all real problems people want a solution to.

"I want a better programming language" is something we all agree to in principle. But it feels like a "nice to have". Rather than an urgent, specific problem to solve.

Smalltalk never had a "killer app" or was never the de facto scripting language of an environment or platform that everyone desperately wanted to be on.

Note that the other great languages that Richard Kenneth Eng mentions, like Clojure (my current favourite language) have the same problem. They are better than the languages you use. But they aren't essential for anything that you specifically want to do. They are just A.N. Other option for doing it.

So only those who are really interested in learning new languages, or having better tools, go out of their way to learn them.

Related :

Phil Jones (He / Him)\'s answer to Why isn\'t Smalltalk widely used anymore?

Why isn't Smalltalk widely used anymore?

Jul 14, 2017 https://www.quora.com//Why-isnt-Smalltalk-widely-used-anymore/answers/50436074

Some good answers here.

But I think Smalltalk had already "lost" by the mid-80s.

So some of the talk about what was going on in 1995 - with Java or the rise of the web - are redundant.

Smalltalk "lost" in the mid-80s, because Smalltalk's essence / raison d'\xc3\xaatre was to be a tight integration between language and GUI environment. More than a language, Smalltalk is a philosophy of a live ("living"), always running, dynamic GUI system, which is open to inspection, interference and scripting by the programmer / user. The tools like the inspector and class-browser and transcript and mouse are as much part of Smalltalk's "syntax" as the ^ character.

When GUIs like the Apple's Mac, X11, Windows, GEM etc. took off as independent libraries / frameworks / toolkits that were NOT part of a Smalltalk system, then that ideal was already sidelined. Once traditionally compiled, uninspectable / uneditable / inflexible programs written in Pascal and C could become citizens of the WIMP environment, or to flip it around, once GUI environments became mere neutral containers which could accept programs written in any style and language, then the spirit of Smalltalk was already vanquished. Everything else is just accountancy.

tl;dr : It was beaten not by C++ or Java, but by MacOs and Windows.

Related :

Phil Jones (He / Him)\'s answer to If Smalltalk is so great, why is it used by so few compared to languages like Java and Python?

Why isn't Smalltalk widely used anymore?

Sep 24, 2017 https://www.quora.com//Why-isnt-Smalltalk-widely-used-anymore/answers/57819308

Smalltalk is a fund of really good and interesting ideas. It is historically very important, both for the influence it had and the influence it could have had.

Smalltalk's great ideas are being a "live" collection of interacting objects, a tight integration between language, interface and environment, and being an open, personal, exploratory and creative environment.

At the same time, some of Smalltalk's particular solutions and implementation decisions may be less relevant. Let's talk about this. Not to argue that Smalltalk isn't relevant, so much as to indicate what Smalltalk could do to improve its relevance.

While Smalltalk's GUI desktop metaphor took over the world in the 80s and 90s, it's actually one of the least important environments today, compared to web-servers, web-browsers, mobile devices and the internet-of-things. Smalltalk principles could be applied to these environments, BUT, you'd probably want to throw out the existing GUI framework and start again, bootstrapping (in Smalltalk, obviously), different kinds of (visual and not-visual) interfaces, suitable for each of these places : phones, tablets, browsers, servers, robots etc.

I believe Smalltalk's monolithic and highly stateful and idiosyncratic "image" was one of its problems. The image is particularly incompatible with developing and selling "boxed" software or even mobile apps. The beauty of Smalltalk is that it breaks down the barrier between consumer and producer of software. But this obviously doesn't work for people who are invested in the producer / consumer distinction for their business model.

So Smalltalk needs a better story / metaphor for how developers produce, package and distribute applications for other people. Some of that looks like existing Linux package managers and things like npm / maven etc. Part looks like app-stores. But this metaphor / model should be at the core of the system. A new Smalltalk (eco)system would be built around its package management, much as Debian is built around its package manager.

At the same time, we increasingly want user data to be in a cloud and synced between different environments and shared between different groups. This again needs to be at the heart of a new Smalltalk-like system. Syncronization / sharing / distribution rules needs to be fundamental properties of the objects that make up the system. "Sharing" changes in your work environment with friends or followers should be as easy as sharing pictures with friends on social media. ( See some of Jonathan Edwards's work on "social data-structures" for a hint of this. Croquet / Open Cobalt were also focused on shared virtual worlds. I don't know them but I'd like to see more of their ideas.)

Personally, I think we can do better than the actual Smalltalk language. While simplicity and consistency are wonderful things, I don't really want to live in the Kingdom of Nouns. Supplementing objects and message passing with stand-alone named functions from modules seems useful. (I presume Smalltalk's blocks already act like lambdas). Constraining mutable state to very specific places / situations is definitely a good thing. Macros are handy, and I believe would play well with Smalltalk's piecemeal compilation. I'd even consider types, if you have good type inference. Multithreading / asynchronous communication, actors or go routines could be explicitly part of the core language.

I can imagine a wonderful system for tablets which is partly like a Smalltalk, partly like Hypercard, partly like wiki, partly like a Jupyter Notebook and partly like Slack. It wouldn't bother with windows and icons. But would use GUI elements like cards and pages, Intents and Actions. It would be hooked to cloud storage, and cloud-based communication streams, and a package repository. Flows of notification cards would be fundamental. And writing bots to watch and process them. Or daemons / actors / stand-alone processes to watch and interact within the system would be trivial.

Is Smalltalk a compiled or an interpreted language?

Feb 6 https://www.quora.com//Is-Smalltalk-a-compiled-or-an-interpreted-language/answer/Phil-Jones-He-Him

It's compiled to bytecode, which is then interpreted by a virtual machine. Though some versions of Smalltalk might have a JIT to compile some of the code to real machine-code.

Having a byte-code and virtual machine is not uncommon. It's how Java works. And how Python works. Etc. What's unusual about Smalltalk is that the compilation happens on a method by method basis. So every time you edit a method in the Class Browser, that method is recompiled into the bytecode.

So there's no big distinct "compilation" phase. You are recompiling every method as as when you edit it.

Quora Answer : Why don't colleges and universities use Smalltalk?

Aug 27, 2019

I learned Smalltalk at college.

In fact I learned Smalltalk on Eliot Miranda's BrouHaHa.

But that was when Smalltalk was still the standard-bearer of "Object Oriented" programming.

Since the world went to Java and Python etc. as mainstream OO languages, Smalltalk doesn't really give a good idea of that. (In fact, in some ways it messed me up, because I was expecting C++ to be like Smalltalk I actually didn't really get to grips with how C++ and Java SHOULD be written. And the self-discipline needed to work with them.)

Today I suspect colleges don't teach it because they assume that it isn't representative of the OO that people will meet in real life. And that unlike Haskell and Prolog which are also "not real life", the lessons Smalltalk has to teach are nevertheless available from Python and Java. The first of these assumptions is true. The second isn't. But it is kind of true that the virtue of Smalltalk is holistic, and doesn't really carry across piecemeal to other languages and platforms.

If you really grok Haskell well, you'll probably HATE Java. But your knowledge might still help you use the Java type system more effectively than you otherwise would. If you really grok Smalltalk, I'm not sure that helps much at all when you come to Java. You'll just hate it more.