Smalltalk: Swimming with the fish

http://simberon.blogspot.nl/2013/01/swimming-with-fish.html

by gabordemooij • 13 years ago

87 81 13 years ago

simberon.blogspot.nl

A while back I backed an IndieGoGo project dedicated to bringing Smalltalk to the JVM: 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.)

zeckalpha• 13 years ago

You could also do http://amber-lang.net/ and ClojureScript, no?

endlessvoid94• 13 years ago

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.

fusiongyro4• 13 years ago

That isn't true.

http://www.redline.st/discover/is-it-smalltalk.html

DanielRibeiro• 13 years ago

Redlines smalltalk on the JVM is cool. You can also use Smalltalk on the web browser through Amber: http://amber-lang.net/

pavlov• 13 years ago

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

dllthomas• 13 years ago

Fish vs. fishes... and I think "sleeping" is the more common form (at least in media), but yeah, I was wondering, too.

aaronem7• 13 years ago

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• 13 years ago

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• 13 years ago

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.

radiowave• 13 years ago

It's pretty rare that you'd actually make ad-hoc changes and then rely solely upon persistence to preserve those changes. Ultimately, you'd want to write code to produce the outcome programatically. It's more the case that you play around and do little "what ifs", which helps you crystalize your ideas about what you're trying to implement.

The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.

Still, using Python to pay the bills isn't so bad...

rprospero3• 13 years ago

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.

fusiongyro4• 13 years ago

The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved.

Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.

An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).

To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.

agentultra• 13 years ago

That's roughly how one works in Common Lisp as well (though most implementations don't ship with a graphical environment, so ssh is typical instead of VNC).

It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.

ddfreyne• 13 years ago

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.

EdwardCoffin• 13 years ago

With respect to version control systems, I notice you didn't mention ENVY. I can't comment on Monticello nor Store, never having used them, but I still miss ENVY. Best version control system I ever used.

Source: professional Smalltalker for about four years (fifteen years ago)

fractallyte3• 13 years ago

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!

bromagosa4• 13 years ago

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.

tikhonj• 13 years ago

Just because you have shorter methods does not mean you would not benefit from Emacs-like power. I use Haskell--which has even shorter functions, often half that length--and yet I still find Emacs exceptionally useful.

Any amount of text is still text, and Emacs excels at text editing.

shurcooL• 13 years ago

I problem I ran into when giving it a try. I couldn't easily find a way to print to standard output. All I wanted was to print some strings, numbers and manipulate them. Instead, it was easier to have a red ball on the screen.

klibertp• 13 years ago

There is no stdout, but if you want, you can print to something. Just open up a Transcript window and use 'Transcript show: ' method.

gabordemooij• 13 years ago

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) and tried Pharo (http://www.pharo-project.org/home), Amber (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/) 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?

fusiongyro4• 13 years ago

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. :)

bromagosa4• 13 years ago

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.

gamache• 13 years ago

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.

pjmlp5• 13 years ago

Yes they are gone.

However, the main point is that back then you haven't got HN, Reddit and the blogs of today.

As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.

loup-vaillant5• 13 years ago

Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore.

That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf

roarroar2• 13 years ago

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

Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.

solarexplorer• 13 years ago

This is true of any new system. There is a huge complexity in supporting even the standards that most people would consider basic. Just to surf the web you need TCP/IP, HTTP(S), HTML, JavaScript, JPEG, etc. Implementing all of these from scratch is a huge pain.

rbanffy3• 13 years ago

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• 13 years ago

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

epsylon• 13 years ago

Have you ever tried Eiffel? I've always found the approach taken by Eiffel as OOP done right (compared to C++). I wonder how Eiffel and Smalltalk compare together.

silentbicycle• 13 years ago

At the same time, so much recent tool development has focused on virtualization. Vagrant, chef, puppet, packer, ... and yet, Smalltalk has decades of experience with whole virtualized machines to we can study.

Perhaps systems like Smalltalk still have something to teach us?

cabalamat• 13 years ago

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

Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?

aaronem7• 13 years ago

From its documentation, it looks more like an attempt to expose the kind of REPL/runtime integration Emacs offers, through an interface which won't scare people off the way Emacs tends to do.

bromagosa4• 13 years ago

Yes. And seriously, when I saw the first Light Table demo and everyone was so amazed with it I thought "man, that's how we code every day in Smalltalk... what's so new about it?"

e12e2• 13 years ago

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

I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.

And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".

Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.

The exception might be the one-laptop-per-child project.

So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".

If anything, it seems these systems keep being reinvented.

Ygg23• 13 years ago

Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.

Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.

[1]http://en.wikipedia.org/wiki/Worse_is_better

[2]http://en.wikipedia.org/wiki/Xanadu_Project

bromagosa4• 13 years ago

I've worked with Smalltalk for four years now, and for what you write, I guess you haven't been keeping up with our progresses. Take a look at:

http://amber-lang.net

http://www.redline.st/

http://pharo-project.org

Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.

masklinn• 13 years ago

Most of its best features made it into other languages

No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.

do-it-good• 13 years ago

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

aaronem7• 13 years ago

Symbol's function definition is void: 'Lisp'

nsxwolf3• 13 years ago

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.

nsxwolf3• 13 years ago

Sure, downvote me. This article says nothing. You have to be a Smalltalk lifer to get it. It's all metaphors that have no meaning to anyone outside the author's bubble.

Crap article.

fractallyte3• 13 years ago

Apologies for throwing these quotes in, but they just seem so appropriate in this context:

"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."

"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."

Try the red pill... (And think of turtles rather than rabbits!)

zeroflag• 13 years ago

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.

nsxwolf3• 13 years ago

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

maliki• 13 years ago

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?

Smalltalk: Swimming with the fish

Related Stories