
Today’s Smalltalk: A Second Look At The First OO Language - MarcusDenker
http://blog.smartbear.com/programming/todays-smalltalk-a-second-look-at-the-first-oo-language/
======
stormbrew
I feel like a lot of the really clever and elegant things about smalltalk as a
language and an object model got bogged down in the program image execution
model, to the point where it stunted the evolution of those ideas for a long
time. We're getting to the point where such a model is more practical now, but
it still strikes me as hopelessly impractical even so.

It wasn't until OSX made Objective-C take off and Rails made Ruby take off
that some of the fundamental language features entered the mainstream, and
they did so with a gusto that other 'ivory tower' languages wish they could
achieve. But only by leaving the image model behind.

It seems like something like Erlang managed to do what Smalltalk tries to do
with the image better, allowing for easier to reason about deployment,
collaboration, and version control while still letting you deal with a system
of relatively opaque boxes of replaceable code.

~~~
bromagosa

      But only by leaving the image model behind.
    

There are many Smalltalks without an image actually... GNU-Smalltalk,
Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image
and filesystem, so it can't be regarded as a traditional image-based system
either. The only Smalltalks that still use an image paradigm (that I know of)
are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks.

That said, I believe the image is a very valid model, and I prefer working on
a Pharo environment than anywhere else. However powerful text editors, IDEs
and debuggers may be, you can never reach the same level of integration
between tools and system if your tools, your language and your system are not
the exact same thing.

~~~
dfox
Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is
optimized for "normal source code" model, in ST/X it's mostly an artifact of
implementation and file system resident source code is simply a way to store
what essentially amounts to changes file in classical implementations (the
killer feature is that you in most common case can use non-ST specific VCS
without significant issues). In all I haven't seen ST implementation with good
development tools that is not at least partially image based.

The problem I see with ST IDEs is the fact that most advanced features work by
introspecting live image state and autogenerating some source code, which
completely break any attempts to meaningfully define what is (versionable)
programmer-written input and what is derived tool output.

~~~
bromagosa
True, they're partially image-based.

    
    
       In all I haven't seen ST implementation with good development tools that is not at least partially image based.
    

But what about Amber?

------
overgard
Smalltalk is incredibly cool, but I think one of the main things stunting it
is it doesn't have a great free implementation. The only modern smalltalk
environment I've used which felt like a serious environment was VisualWorks,
and to download that you have to fill out a form and you can only use it under
a "personal use" license.

Squeak, despite being impressive, has always felt like a toy. I like Pharo in
spirit, but GUI wise, it looks really off. If I can use a weird metaphor to
describe it: it's like reading a brilliant PhD thesis written in Comic Sans.
That's what the GUI reminds me of. The content is brilliant, but the
presentation really leaves you scratching your head. I know it's not fair to
judge an entire development environment off its aesthetics, but people are
going to do it anyway.

~~~
gecko
I get what you're saying, but it's also really weird to me.

You cannot sanely use Pharo or Squeak to write native apps right now; that's
totally true. You also couldn't do that for Visual Works, except for a very
narrow window when they properly emulated enough Windows XP widgets you could
probably fake it. But Pharo and Squeak proper look (to me) neither more nor
less native than IntelliJ, which people happily use. Both have professional-
looking IDEs that do not look native. That doesn't impact you if you're doing
web work, command-line work, etc.

There are lots of other reasons I would finger instead (C interop was
historically poor, people were historically reticent to use VMware-image-like
language environments, etc.), but Pharo and Squeak have looked fine for most
purposes for awhile.

~~~
overgard
You're probably right about visual works, I haven't used it since 2005 so I
kind of fell in that window.

I don't have a problem w/ non-native looking GUI's in principle, but I just
think Squeak and Pharo are kinda fugly. Bad spacing, weird colors, weird
fonts. If that only effected my development environment I could live with it,
but if the apps I make are also going to look like that? Ick. The only thing
I'd really use it for is writing games where GUI's are always going to be
custom anyway. (I think Smalltalk in general would be great for game
development actually.)

Another thing is that at least in other smalltalks, it generally used OS
windows at least. The controls might look weird, but it does feel like part of
the system. Writing code in Squeak feels like you're either using a VM or
Remote Desktop, it's just totally isolated.

The thing is most of these, in isolation, aren't deal killers, but once you've
added up enough weird points it gets a bit too weird. You could make similar
arguments about Java, but I think the difference is in magnitude: Java's
weirdness is kind of weird, smalltalk's weirdness is really weird.

------
mythz
There are a number of great answers on StackOverflow as to why Smalltalk
wasn't more popular:

[http://stackoverflow.com/questions/711140/why-isnt-
smalltalk...](http://stackoverflow.com/questions/711140/why-isnt-smalltalk-
popular)

------
informatimago
Simula is generaly recognized as the first OO language, so it's a second look
at the second OO language at best.

~~~
bromagosa
Correct. Although Smalltalk is generally regarded as the first one because the
concept "object orientation" was first used in it.

Still, the big thing in Smalltalk are not objects, but messages. That's
something many later OO languages missed on completely.

From Kay:

    
    
      «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.»

~~~
vidarh
I think the reason many later OO languages "missed" messages completely is
because the distinction makes little sense in more static languages that lacks
a way to dynamically call a method/send a message.

~~~
yvdriess
And incidentally, dynamic dispatching is recognised as the key feature of OO:
(Cook 2009)

 _Object-oriented programming is successful in part because its key technical
characteristic—dynamic dispatch-is essential to supporting independent,
interoperating extensions; and because interoperable extension is in turn
essential to the reuse of architectural code (as in frameworks), and more
broadly to the design of modern software ecosystems._

~~~
vidarh
I'm not sure if you're agreeing or disagreeing with me.

Dynamic dispatch _is_ supported by most statically typed OO languages. C++
virtual member functions are dynamic dispatch. So indeed, dynamic dispatch is
one of the key features that makes the distinction between calling methods and
sending messages sufficiently un-important that static OO languages are still
useful.

What was (perhaps too imprecisely) referred to in my comment above is
late/dynamic _binding_.

------
pjmlp
Nice article, but it fails to explain the experience using Smalltalk
environment really is.

Smalltalk, like Lisp Machines, was originally a blend of GUI operating system,
development environment and the first real IDE.

~~~
agumonkey
It's funny. Unix was also meant as an IDE (persistency, logic, machine and
user interfaces). It seems they all were trying to reach the same goal in
their own way.

~~~
pjmlp
I never saw UNIX as an IDE, given its command line interface with ed and vi as
editors.

~~~
agumonkey
it's a different user interface paradigm, mainly it's not graphically
sophisticated (independent streams of text vs dynamic bitmap overlays)and less
time integrated (you have to define how and which script to run when something
change). But at the time it was thought so, that's how I felt reading bits of
this book
[http://en.wikipedia.org/wiki/The_Unix_Programming_Environmen...](http://en.wikipedia.org/wiki/The_Unix_Programming_Environment).

~~~
pjmlp
My first UNIX experience was in 1993 with Xenix, followed by almost all
commercial variants of it.

By then I was already spoiled with GUI environments from Atari ST, Amiga 500,
Windows 3.x and GEM, as well as the typical MS-DOS IDEs from Borland.

So I never saw UNIX that way.

~~~
draegtun
_UNIX is my IDE. perl5 is my VM. CPAN is my language._

ref: [http://shadow.cat/blog/matt-s-trout/but-i-cant-use-
cpan/](http://shadow.cat/blog/matt-s-trout/but-i-cant-use-cpan/) |
[https://news.ycombinator.com/item?id=968757](https://news.ycombinator.com/item?id=968757)

NB. Though I think someone else earlier (Audrey Tang perhaps?) made a similar
quote (something like _CPAN is my syntax?_ )

------
gecko
If you've historically ignored Smalltalk due to its ecosystem or non-native
UIs, I'd like to suggest you take a look at Amber ([http://amber-
lang.net/](http://amber-lang.net/)), a Smalltalk that runs on Node and works
great for web dev.

------
Tloewald
Simula was the first OO language.

