
The Smalltalk Revolution - horrido
https://medium.com/@richardeng/the-smalltalk-revolution-ee245c281f51
======
muraiki
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.

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.

In Seaside's dev mode I can toggle viewing all the components that make up the
currently displayed page (a page isn'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.

Having experienced such tools, it'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.

I'd love to be able to program in Smalltalk professionally, but I really
couldn't find that kind of gig (especially entry level) in my area. But even
if you can't see an immediate business use case, just spend a weekend going
through the Pharo and Seaside tutorials. If learning lisp is important "not
because you'll use it but because it will forever change you" (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. :)

~~~
current_call
_If learning lisp is important "not because you'll use it but because it will
forever change you" (to paraphrase) then learning Smalltalk is important in
the same way._

Learning Common Lisp is like learning Smalltalk in another way, Common Lisp
shares some of Smalltalk's features.

 _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._

This is also true for Common Lisp. When I hit a bug, I can edit the broken
code, reload it, and resume execution from where the program stopped. I can
load edited code and freeze the program to inspect objects at any time. It's
enjoyable to edit some opengl code and see changes in real time.

 _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._

If anyone was wondering why some people don't like Clojure being described as
a modern Lisp or the future of Lisp, this is one reason.

------
gamache
_Smalltalk is not the Grand Old Man of programming languages, but the future
of software development created 40 years in the past._

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'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's cue on object
oriented design.

What more is there left for Smalltalk to accomplish? That's not bad, for a
language which basically never made it out of PARC for two decades!

~~~
i_am_ralpht
Smalltalk as a live environment blurs the boundaries between runtime and
editing code. There's a video on ThingLab[1], a constraint solver, from 1978
where Alan Borning draws constraints graphically and then switches view to
show the code that was generated. When he manipulates a constraint the runtime
creates and compiles a new method based on the system that was graphically
defined. That kind of thing would still be pretty awesome today (who generates
JS at runtime for performance?).

Your comment reads a bit like "we cargo-culted the things we could see in the
Smalltalk environment, but didn't understand the underlying philosophy or
elegance of what had been made; what's left to learn?" (I know that's probably
not what you meant, but I feel like there's a lot left to learn from Smalltalk
and the tools that were built with it).

[1]:
[http://en.wikipedia.org/wiki/ThingLab](http://en.wikipedia.org/wiki/ThingLab)
(see link 4 for the video; it's really fun to watch).

Also check out:
[https://github.com/cdglabs/thinglab](https://github.com/cdglabs/thinglab) \--
there's a link to a St-78 image with ThingLab. Also interesting to note
proportional fonts, text selection (by Larry Tesler) and popup menus, all of
which I thought came later...

~~~
gamache
_Your comment reads a bit like "we cargo-culted the things we could see in the
Smalltalk environment, but didn't understand the underlying philosophy or
elegance of what had been made; what's left to learn?"_

Seeing features you like and porting them to a system where you can use them
isn't cargo culting. It's progress.

~~~
jbergens
Unless you miss the bigger picture. Of course you can use any part you like
but if the main value comes from a combination which you are no longer using
while you still thinks you're using the same method/idea it might be seen as
cargo culture.

------
AnimalMuppet
_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._

Yeah, it's the usual condescending "If you don't see the stupendousness of our
approach, it's because you're not enlightened yet!" that we also get from Lisp
and Haskell types. Spare us.

The rest of the article wasn't bad, but that one paragraph really turned me
off. If I don't do it your way, could you _please_ stop assuming that it's
because I don't know any better? It may be because I actually _do_ know
better.

~~~
cbsmith
> Yeah, it's the usual condescending "If you don't see the stupendousness of
> our approach, it's because you're not enlightened yet!" that we also get
> from Lisp and Haskell types. Spare us.

Alternatively, it's the recognition that the switching costs to unfamiliar
technology are non-zero.

> If I don't do it your way, could you please stop assuming that it's because
> I don't know any better? It may be because I actually do know better.

It may be, but there is a pretty huge in between space where you don't know
any better.

I think you'll find people will believe that if you put in enough "escape
effort" to pull yourself out of the habit. If you don't, you can't really
know, which makes it condescending for you to assert you know better.

So there's this big space where neither party is in a position to judge, but
the advocates want you to _try_. Somehow, that always seems to get
internalized as, "they think they know better". They don't. They've found it
to be a big win for them and other people, and they have an educated guess
that therefore it'll be better for you, even if it initially doesn't seem like
it. That's really not unreasonable.

~~~
AnimalMuppet
> So there's this big space where neither party is in a position to judge, but
> the advocates want you to try. Somehow, that always seems to get
> internalized as, "they think they know better". They don't. They've found it
> to be a big win for them and other people, and they have an educated guess
> that therefore it'll be better for you, even if it initially doesn't seem
> like it. That's really not unreasonable.

That's fine. There's a totally reasonable case to be made for that, for
Smalltalk, Haskell, and Lisp (at least). The advocates just need to express it
in a way that doesn't come across as "I'm enlightened; you're ignorant. Once
you're enlightened, you'll do it my way." That's counter-productive. It turns
people off rather than encouraging them to try it and see.

~~~
cbsmith
> The advocates just need to express it in a way that doesn't come across as
> "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my
> way."

But I think if you look at what they say, it really is as much the
responsibility of the listener whether it is interpreted that way. Even the
above quote, which I'm sure someone didn't say to you, can be interpreted as,
"don't knock it until you've tried it".

------
gaius
What killed Smalltalk was the $10,000/seat licenses. There was very limited
scope for anyone to "kick the tyres". But it's OK, we have C++14 now.

Don't get me wrong I would _love_ to use Smalltalk in anger. But that ship has
sailed. Fight the battles you can win.

~~~
sebastianconcpt
Well niche is not bad. There are gigs in Smalltalk:

[https://smalltalkjobs.wordpress.com](https://smalltalkjobs.wordpress.com)

~~~
gaius
5 jobs a month, in the entire world?

------
zwieback
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.

~~~
k__
In terms of OO it is kinda awesome, with its class hierarchy and that
everything is an object, even classes.

But the whole IDE-entanglement was awful.

I have the feeling, that this is a big problem, we have in many places today.
You can't always have syntax A in system B and programm with IDE C. Often you
have to use what is available...

------
todd8
First, let me say that I love Smalltalk. It'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.

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.

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'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'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?

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/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't it
already had it chance?

~~~
horrido
BTW, functional programming does not impress me at all...

"Programming with the Object Oriented paradigm is creating a program by
identifying and modeling the Problem Domain Entities as objects, and then make
them collaborate between themselves to solve each problem instance.
Programming with the Functional paradigm is modeling the problem as a
mathematical problem, and creating a mathematical function (by composing other
functions) that for each problem instance, computes the problem solution."
(From [http://goo.gl/K4U0Nh](http://goo.gl/K4U0Nh))

It is unnatural for humans to model the world in a functional way. The world
consists of objects, not functions. That's why I've never liked FP.

------
jimbokun
Dependency management. Source code control. Continuous integration.
Deployment.

These tend to be challenges, or at least sources of complaint, for image based
development environments like Smalltalk and Lisp.

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?

~~~
lispm
Lisp is a family of languages and literally hundreds of implementations. Lisp
is not a 'development enviroment'. Many Lisp implementations support 'image
based development'. But most also support 'file based development'. A few even
support only 'file based development'.

~~~
hga
I would go so far as to say that the "MIT style" of using Lisp is file rather
than image based. Saving and restoring an image is purely for minimizing
startup time, and in development would only be done when you're at a point
where that makes sense. And you'd start from a fresh band, LOAD all the
relevant files, and then save. If you're doing an application, it might not
make sense to ever go to the trouble.

Or so I remember as of the early '80s.

~~~
lispm
On the Symbolics Lisp Machine it was common to create incremental Worlds. From
an incremental image one could write a new incremental image.

For example I used to save a minimal site-configured incremental image with
some OS patches first. From there I would load the software I use and dump the
next incremental image. Into this image I would load more software and the
stuff under development and make another incremental image. Based on this I
would load additional patches as necessary...

The reason why these images were saved is not startup time. The reason was
that loading code (-> applications) was quite slow on most Symbolics Lisp
Machines during the 80s.

If you develop on a Symbolics Lisp Machine it first looks into the running
image for many types of information, not the file system: documentation
strings, arguments, who calls, ... even the documentation database needs its
index to be loaded into the image.

------
__abc
I guess I'm the exception in that I spent a few years in Smalltalk in the mid
2000's and thus never viewed it as irrelevant.

Sure, not used by the, "cool kids" in SF, but still used.

------
MichaelCrawford
hey I know smalltalk. I'm really good at it and I like it.

Does this mean I can get a job now, despite having learned the language in
1996?

