
Smalltalk: Swimming with the fish - gabordemooij
http://simberon.blogspot.nl/2013/01/swimming-with-fish.html
======
ddfreyne
The analogy given in the article is pretty accurate. The Smalltalk environment
is unique in that it allows very easy access to the libraries, the IDE and the
language’s internals (including the compiler!). The Smalltalk debuggers are
among the best ones I have ever used.

(I’m mostly speaking out of my experience with VisualWorks, a commercial
Smalltalk implementation, but other implementations are similar.)

I would greatly recommend everyone to give Smalltalk a try. The IDEs are
pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of
the minimalism of the programming language and the pure form of object
orientation. Dig through the code of the standard library — it’s quite easy —
and check out the implementations of TrueClass, FalseClass, BlockClosure etc.

Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make
Smalltalk a very poor choice of environment to use for production code.

Smalltalk lives in its own little world, and the tools that you’d normally use
during day-to-day development are integrated in the IDE, and there is
virtually no possibility of using external tools. The text editors are pretty
bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are
particularly horrible. For version control, you need to use systems such as
Monticello or Store, both of which make me cringe just thinking about them
again.

I also feel that Smalltalk coders get locked in into their environment. Many
Smalltalkers that I have met are quite unfamiliar with what is happening in
the outside world. Most of them have never heard of git, for example (and
quite a few did not know what Subversion was). When an interesting technology
enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk
(yes, there is STON — Smalltalk Object Notation).

These were the main reasons why I quit my Smalltalk job. A sad decision, but
one that was unavoidable in the long run.

Smalltalk is a nice language and has IDEs with some very nice features that I
would _love_ to see in other environments, but it is also severely lagging
behind in many other areas. I would like the Smalltalk community to be more
aware of what is happening outside and build bridges. Without that mindset, I
feel Smalltalk will simply fade out completely.

Source: I used to be a professional Smalltalker for almost three years.

~~~
fractallyte
_> many parts of the Smalltalk IDEs are horribly outdated_

My opinion is the opposite: I find the IDE in Pharo to be simple and very
elegant, far more human-friendly than any I've seen in 'mainstream' languages.
And this version of Smalltalk is under heavy development, with a push towards
even greater cohesion. This small corner of computing is seething with hot,
cutting-edge activity.

 _> The text editors are pretty bad_

Well, you ought to know that Smalltalk is focused on relatively small snippets
of code, held together in consistent OO structures. There's hardly any point
in fancy text-editing features when your methods are generally 8-12 lines
long!

~~~
bromagosa
> Well, you ought to know that Smalltalk is focused on relatively small
> snippets of code, held together in consistent OO structures. There's hardly
> any point in fancy text-editing features when your methods are generally
> 8-12 lines long!

This! And also, in Pharo 3.0 there's being a huge push towards better text
editing, although I've never ever needed more than what Pharo 1.0 did already
provide...

You don't work with text in Smalltalk.

------
chimeracoder
A while back I backed an IndieGoGo project dedicated to bringing Smalltalk to
the JVM: [http://www.indiegogo.com/projects/redline-
smalltalk-v1-0](http://www.indiegogo.com/projects/redline-smalltalk-v1-0)

I really hope this project pans out, because I would love to be able to
program in Smalltalk for practical purposes.

(In fact, even the _thought_ of being able to write a single application in
both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a
long ways from this dream, but perhaps it'll be possible one day.)

~~~
endlessvoid94
It is cool, but redline doesn't have the environment of smalltalk, just the
language. Which, arguably, misses a LOT of the point of using smalltalk.

~~~
fusiongyro
That isn't true.

[http://www.redline.st/discover/is-it-
smalltalk.html](http://www.redline.st/discover/is-it-smalltalk.html)

------
gamache
Articles about how great Smalltalk is usually remind me of articles about how
great the Lisp Machine was. And there is a lot of merit to an entire system,
hardware and software, designed to operate in a high-level language.

My complaint is that neither of these things is coming back in a relevant way.

Perhaps the biggest shift in software engineering in the last decade or two is
the fact that no one writes entire systems anymore. We've moved to a system of
(somewhat!) interchangeable parts. If your thoughtfully constructed,
delicately handcrafted utopia doesn't play well with tools the user is used to
and libraries the user needs, no one will use it in the real world.

Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with
computing progress. Most of its best features made it into other languages
(Ruby and Obj-C are the premier examples), languages which aren't so
opinionated about what OS you run, what IDE you're using, what language
adjacent programs are written in, etc.

Much like Lisp Machines, the rest is left to rot, and incite wistful blog
posts by old hands. And pretty much everyone else ships code in other
languages.

~~~
rbanffy
There is great danger in learning OOP with Smalltalk. Everything fits together
so elegantly, the first time I opened a book about C++, I closed it in disgust
(after seeing the bit-shift operator being used for console output, wtf?!),
only to give the language a second chance 8 years later. I even learned Java
before giving C++ a try.

When a young programmer asks me for advice about the next language to learn
is, my advice is to go for the language that feels most alien. C++ won't
enlighten a Java programmer significantly. Forth will.

~~~
rimantas

      > I even learned Java before giving C++ a try
    

I must admin from all the stuff I saw on the internet I am now scared even try
to learn C++. I think it is the looks as a least desireable language to learn
for me. Which sucks a bit because there is position at a company I wouldn't
mind work for.

~~~
nnq
Learn C first! You'll understand why C++ is what it is and you'll also get the
skills needed to contribute in a lot of open-source projects.

~~~
pjmlp
Please don't! Learn Modern C++ instead, otherwise you will be damaged with
Cisms in C++ land.

~~~
rbanffy
Would you like to elaborate on that?

~~~
pjmlp
There are lots of C constructs that are considered bad practice in C++

\- null terminated strings

\- plain vectors

\- manual management of resources (memory, files, db connections, locks...)

\- C style casts

\- pre-processor instead of using inline/const/templates

\- the C subset of C++ it is also not 100% compatible with C, there are a few
cases with different semantics

\- since C99, new language constructs are added via macros, instead of
keywords

\- no use of namespaces

\- lack of safety of parameters that can be changed (pointer vs reference
parameters)

The best way to learn C++ is to read books like "Modern C++ Design",
"Programming -- Principles and Practice Using C++" and the recently published
"Tour of C++".

~~~
swift
I have to take issue with your inclusion of "Modern C++ Design" in a reading
list about learning C++. If you're new to C++, that is exactly the sort of
thing you _shouldn't_ be reading.

"Modern C++ Design" is really intended for advanced C++ programmers only. I
don't feel it gives a very good impression of the language to new developers -
there are so many awful hacks in that book.

It's the sort of thing that you should hold off on until you have the
experience with the language necessary to be wise about when such techniques
are appropriate.

------
gabordemooij
I have been facinated by Smalltalk but the language drives my kinda crazy. I
have read the 'Blue book'
([http://wiki.squeak.org/squeak/64](http://wiki.squeak.org/squeak/64)) and
tried Pharo ([http://www.pharo-project.org/home](http://www.pharo-
project.org/home)), Amber ([http://amber-lang.net/](http://amber-lang.net/))
and GNU Smalltalk.

While I really like Smalltalk, for some reason it does not work for me as a
web development platform (and the web is my platform), or maybe I just don't
grasp it.

I tried Seaside ([http://www.seaside.st/](http://www.seaside.st/)) but the
URLs it generates are not acceptable (unfortunately) and I find their
component system quite complex. I hope someday I will find way to use the
techniques behind Smalltalk (live environment, object model) in a browser or
web environment. Maybe Amber will develop into something I can work with. I
really hope so. Any suggestions anyone?

~~~
fusiongyro
There are two other web frameworks in use, and I think one of them is more
about generating clean URLs. Illiad?

I love the idea of Smalltalk, but it also never stuck for me. I think I just
prefer to learn from books than through milling around in the image. All the
great minds in Smalltalk seem to be self-driven autodidacts. I'm not.

I'm pretty good at Haskell and Prolog though, so I think it works out in the
end. I'm also not good at Lisp or Forth. :)

~~~
bromagosa
Yep. AidaWeb and Iliad (plus many other smaller ones).

Although Iliad is not about generating clean URLs (it can, though), but more
about being small and understandable, plus having Ajax for free and being
pragmatic.

------
pavlov
Based on the title, I assumed this would be an article about how Smalltalk has
been murdered:

[http://www.usingenglish.com/reference/idioms/swim+with+the+f...](http://www.usingenglish.com/reference/idioms/swim+with+the+fishes.html)

~~~
aaronem
I'd like to see their source for that!

"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose
presence in the common vernacular originates with its use in Puzo's "The
Godfather"; in my entire life as a native US English speaker, I have never
once heard "swim with the fishes" used with anything remotely resembling the
same meaning. (It doesn't even make _sense_! Dead things don't swim; they
can't, because they're _dead_.)

------
tieTYT
I've got a bit of the blub paradox going on here so this story is lost on me.
Can anyone give me a concrete example of what he's talking about instead of an
abstract analogy?

~~~
seanmcdirmid
In Smalltalk, you can manipulate objects directly rather than just indirectly
via code that operates on them. The state of your manipulation is made
persistent in smalltalk's image facility. Also, the whole object graph is
supposedly better exposed accordingly then what you could get sigh just a
plain old debugger.

At least I think that is what the author is trying to convey.

~~~
rprospero
This is where my Blub programmer life bites me. I don't understand what you
mean by "manipulate objects directly". I can't figure out the right
abstraction level to put it at.

For instance, let's say I have an Employee object that throws an exception.
Clearly, if inspect that object and change the name member, Bob from
accounting's name doesn't suddenly change to Gary. So I'm not acting directly
on the object, but a representation of the object.

However, then it just sounds like Smalltalk lets me play with a set of bits in
memory that represent the Bob object. Most debuggers I've worked with already
allow me to do that in some fashion. Yet, this is always touted as one of the
great, unique features of Smalltalk. There must be something that I'm missing,
but I can't see what.

~~~
aaronem
What you're missing is that, in Smalltalk, the representation on which you're
acting is indistinguishable from the object; in your example, when you change
the name member, Bob from Accounting's name _does_ suddenly change to Gary;
not only do future accesses of the name member on that object return "Gary",
but, for example, if you have an HR management frontend open on Bob when you
make the change in the inspector, you'll instantly see the effect there as
well.

If all your experience and knowledge is born of Unix and the web, you don't
really have available the necessary concepts to think about how a Smalltalk,
or even a Lisp, actually works -- I know this because all of _my_ experience
and knowledge were born of Unix and the web, until recently, when I took it
into my head to learn Lisp and also to gain at least a passing familiarity
with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS
Handbook, written mostly by veterans of the Lisp years at SAIL, our modern
computing environment is described thusly, by Ken Pier of Xerox PARC:

"I liken starting one's computing career with Unix, say as an undergraduate,
to being born in East Africa. It is intolerably hot, your body is covered with
lice and flies, you are malnourished and you suffer from numerous curable
diseases. But, as far as young East Africans can tell, this is simply the
natural condition and they live within it. By the time they find out
differently, it is too late. They already think that the writing of shell
scripts is a natural act."

Which I thought was hyperbole, too, until I spent some time discovering what
sort of environment Pier and the SAIL folk took for granted. I don't
unreservedly recommend the experiment; I earn my living in Pier's "East
Africa", and sometimes I think I'd be better off if I didn't know how bad I
have it. But I can certainly say that if you haven't tried it for yourself,
you don't begin to know what you're missing.

~~~
rprospero
I understand that changing the name member of the Bob object to Gary will
cause it to be Gary in every subsequent member access. Perhaps I've grown
spoiled in my old age, but I'd be shocked at any system which didn't have this
property. However, if I called out "Hey Gary!" down the hall, would he
respond? Would his driver's license still read Bob?

The last time that I tried to learn Smalltalk, it was drilled into me that
Smalltalk works directly with objects and not just their representations. For
instance, the collection of black pixels on the screen was the Mouse object
itself and not just a manifestation of a Mouse object somewhere in memory. A
large amount of my confusion has possibly come from those lessons.

I agree that Lisp is an enlightening experience. I spent two years using
Scheme as my primary programming language at work. Then again, I may just be
stuck as a Blub programmer. I spent a year focused on Common Lisp, but never
found any use for SLIME, despite using Emacs exclusively.

~~~
aaronem
> However, if I called out "Hey Gary!" down the hall, would he respond? Would
> his driver's license still read Bob?

Yes and no, respectively.

Perhaps a heavily contrived example might help: Consider a system in which
there is exactly one representation of an object member's value, which is
stored in that object; when you call an accessor method, what you actually get
is a reference, which is instantiated with an observer attached that listens
for a notional "change" event, fired whenever the referred value is modified,
and whose event handler updates whatever context exists around the reference,
regardless of its nature, so that the displayed value matches that newly
assigned to the object member.

...and now perhaps you can see why people familiar with Smalltalk think so
highly of it; what in, for example, Javascript, would require an enormous
amount of manual infrastructure and completely fail to generalize, in
Smalltalk happens entirely transparently. It's not so much that you don't have
to think about it; it's that there's _nothing there to think about_.

> I spent a year focused on Common Lisp, but never found any use for SLIME,
> despite using Emacs exclusively.

And now _you 've_ lost _me_. How can this possibly be the case? What was your
Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if
you're just talking to the REPL and not working in an actual Lisp
_environment_ of the sort you get with Emacs Lisp or SLIME, but I have trouble
understanding how anyone could work with those tools for a year without
recognizing their potential.

------
maliki
One benefit that a lot of commenters here have pointed out is very user-
friendly inspection of running code. Kind of a super-REPL. I find that in
Python I'm most productive in iPython's browser-based notebook interface (or
Mathematica, but I find Mathematica difficult for writing things that go into
web-facing applications), which offers similar features.

These notebook interfaces are REPLs, but they're a little more user friendly
in the sense that you can edit history in place instead of doing a history
completion and then evaluating an additional line.

Has anybody had any experience with these notebook interfaces as well as the
smalltalk environment and can give a rundown of the differences?

------
do-it-good
You can swim with the fish or grow up and play with the big boys (Lisp >>
Smalltalk).

~~~
aaronem
Symbol's function definition is void: 'Lisp'

------
nsxwolf
So, it's a language for doped up hippies. That's what I got out of that. I
recalled Jerry Garcia's stories about scuba diving and how it was better than
LSD.

I have no clue what it means to live amongst your objects and touch and feel
and turn and taste them. That article didn't really explain what that means,
but I'll take him at his word.

~~~
zeroflag
Here is a concrete story what happened me few weeks before, while I was
working on a Nintendo emulator in Pharo. I was playing with Super Mario, and
at the end of the 3rd or 4th level my emulator crashed because of some index
miscalculation in a sprite drawing method. When this happens in smalltalk, a
debugger window pops up, and the cursor is on the problematic line. I fixed
the bug in the debugger and pressed proceed then continued my journey to save
Princess Peach :).

In a live environment it is easy to make experimentations because you can get
very quick feedbacks, and there is no need to switch between modes like
development to execution or execution to development. Catching and fixing
certain bugs is also easier as I showed before.

I think there is a need for this kind of development, that's why people try
implementing code hotswapping and class reloading capabilities in various
programming environemnts. But still most of them are just limited workarounds
compared to smalltalk where live coding works fine for decades.

~~~
nsxwolf
If the original article had contained something like what you just wrote, it
would have been an interesting and worthwhile article.

