Why Smalltalk
By Ramon Leon - 3 April 2007 under Lisp, Programming, Ruby, Smalltalk
As always, I enjoy reading what someone thinks of Smalltalk after a proper demonstration. I find Edwards thoughts on Smalltalk typical of that aha you get when you really see what Smalltalk'ers can do.
Edward was lucky, he had a Smalltalker handy to show him the ropes, few have that opportunity. I'm still amazed by how many people think they can grok Smalltalk by seeing syntax examples. Smalltalk isn't its syntax, it's its environment. Smalltalk is a living world of running objects, there are no files, no applications, just what's running. To understand Smalltalk, you have to either actually use it for a while, or have a seasoned Smalltalker demonstrate it to you. Reading sample code just won't cut it.
For better or for worse, Smalltalk is a world unto itself. It's much more an operating system than a programming language. When Steve Jobs stole the idea for a windowing system and mouse from Xerox (not that they invented it), it was Smalltalk he was seeing. Even he readily admits he was so dazzled by the GUI he didn't even notice Smalltalk, or the fact it was all networked with email, things we take for granted now but didn't exist widely back then.
Sure, we package code and use source control, but our methods aren't file based. Our source control systems are language aware, they can diff and merge code at the method level, auto merge and allow you to select, method by method, which version you want to keep. Smalltalk is different, top to bottom, it's just different. Everything is live, code changes are live, applications don't start, they're simply always running. Object oriented programming means something entirely different to a Smalltalker than to someone doing OO in another language.
Ruby comes very close to Smalltalk. It's a nice introduction to many if not most of Smalltalk's ideas. It's very pragmatic, fits in with the world around it, it's based on files, works with your favorite text editor, etc. etc. But Ruby still isn't Smalltalk. I use Ruby, I like Ruby, but Smalltalk is more productive when I'm working in unknown territory. Smalltalk is better for prototyping ideas quickly. A read eval print loop and hyper-linked documentation just doesn't compare to a real Smalltalk workspace and a real Smalltalk browser where the code itself is hyper-linked and navigable and objects are things you can actually pick up and shake.
Smalltalk doesn't have to be pragmatic, because it's better than its imitators and the things that make it different are also the things that give it an advantage. Its syntax isn't weird, C's is. Weird isn't even the right word, because what's weird is totally relative and very dependent on your background experience. Smalltalk's syntax is simply better.
Window window = new Window(0, 0, 800, 600);
Simply isn't as expressive as...
window := Window top: 0 left: 0 width: 800 height: 600.
And this is a trivial example, the more complicated the code gets, the more of an advantage Smalltalk has. Ruby chose to go with a C'ish syntax, but by convention, mostly tries to fake the Smalltalk style anyway because it's simply better.
window = Window.new :top => 0, :left => 0, :width => 800, :height => 600
So, if you still haven't tried Smalltalk, and I mean really tried it, by writing an application in it, give it a go. You'll never regret it, because everything you learn, and you'll learn a lot, you'll be able to bring back with you to whatever language you call home. Smalltalk will change the way you think, no matter what language you're coming from. Whether it changes it for better or for worse is of course entirely up to you. If you're afraid to try Smalltalk, then at least try Smalltalk Lite... uh, I mean, Ruby, you'll enjoy it and still be able to use your existing tools. You can work your way up to the real thing.
PS: Lisp and Haskell are two other equally mind bending languages that I think everyone should learn, however, neither of them can touch Smalltalk's development environment. That being said, learn them anyway.
Comments (automatically disabled after 1 year)
Well put Ramon, as always. No "news" here but it needs to be said over and over. :)
And responding to Sean: As you note the image-ness is a very notable strength of Smalltalk. And also the fact that Smalltalk normally is written largely in itself (compiler, tools, environment etc).
In fact - a late conclusion of mine is that the fact that Squeak (for example) is its own environment which is malleable under your fingertips makes all developers contribute to the same "IDE". Given a smaller community this is very important - in the "script world" on the other hand (Ruby, Python etc) all developers are scattered around different "islands" of IDEs - in Squeak we all share and improve the same one, and regardless of underlying OS.
An image world does of course make some things less "conventional", but IMO there are almost always good ways forwards.
For example, source code management - Monticello in Squeak just rocks so the need for external files and tools like Subversion/Darcs etc is a null issue.
Another example is interacting with the OS and in Squeak we have an excellent package called OSProcess that can do almost everything like accessing stdin/stdout, spawning other processes and reading their outputs etc. And we have very simple FFI and a plugin architecture for doing harder stuff.
Most people don't know it but you can actually use Squeak just like Python or Perl to execute a script headless using the #! convention.
regards, Göran]
I'm afraid that the following phrase: "You'll never regret it, because everything you learn, and you'll learn a lot, you'll be able to bring back with you to whatever language you call home." isn't totally true. I mean -- it will always come to hacking. The languages, environments and such, all of them will finaly appear to have to be hacked. And, as Edward Povazan says: "But hacks are hacks." I always regret to know how much better the experience of programming would be if only the environment and the language were a little bit closer to Lisp or Smalltalk...
Well to the development environment. What you wrote about Lisp is not fully true. They are remarkable close and if you take into account Genera then they are beyond the Smalltalk environments. Because the whole Operating System is a Lisp image. I know nobody but a very few today have got their hands on it. but if you really insist you could ;-)
Regards Friedrich
Nit:
window = Window.new :top => 0, :left => 0, :width => 800, :height => 600
Use correct syntax if you want to capture the Rubyists ;-)
@Sean, the only way to do it, is to just do it. Pick up Squeak and start playing. Keep a workspace open and find reasons you use it for stuff. The way to get your head around it is to put it up on one monitor, full screen, and just consider that the operating system for that monitor.
@Goran, appreciate the comments, and I'm looking forward to scripting with it as well now that I've moved to a Linux environment. Seems OS process is more capable there. Want to find a reason to use that fork another image as a child of this image and do some work thing for multi core cpus.
@Piotr, sshh, I don't want people to know they'll hate their language when they go back. ;) Everyone needs to take a trip to Lisp and Smalltalk land for a while, however temporary, just so they can see where things will eventually go. Hopefully, more than a few decide to stay.
@Friedrich, well, when talking about Lisp I was of course referring to emacs and slime (which I believe is the modern popular lisp dev environment). The Lisp machine of course, is very much like Smalltalk, an OS unto itself with windows and all. Certainly as good as a Smalltalk image.
@Jules, you're so right, my bad, it was late, forgot to use symbols. dang that publish button for being so easy to hit.
Ramon,
I am also an armchair Smalltalker but the reason I haven't seriously moved to Smalltalk has more to do with Squeak and less to do with Smalltlak itself. Everytime I try to use Squeak I am struck with the jarring sense of using a toy. It's not that the power isn't there but the UI is so... colorfully jarring. Your dev image goes a long way to remedying that but still it is a bit of a dissonance jumping in and out of Squeak (especially from the OS X UI). Add to that the fact that I hace to jump in and out of Squeak all the time to deal with other things (email, IM, web) and it gets very tough.
I wish I could make native OS X Smalltalk apps that. I know Ambrai goes a long way to that but I Ambrai is SOOOO easy to crash and burn right now and their OS UI integration is very rough. If only I could get the stability and power of Squeak in an environment more "embedded" with my OS. I don't want to jettison the Image concept or the dev tools in any way I just want to be freed from the restriction of the "one-UI to rule them all" that is the current Squeak world.
Any hope that someone will free Squeak from it's containment anytime?
I doubt Squeak will ever change, being a non commercial open source Smalltalk aimed at kids (Silly rabbit, Squeak is for kids), it just doesn't seem likely. I wish it'd change too, but my guess here is if you want something that doesn't look kinda like a toy, use a real commercial Smalltalk that is aimed at the correct target audience.
I however, am a web developer, and Squeak's intended audience matters little to me. I can tolerate the look and feel, and honestly, have even grown to like it, as long as I can build web apps with it and use it on the server where the client doesn't know what the back end is.
Server based apps are the one place where we can still choose whatever framework we like, Scheme, Lisp, Smalltalk, Ruby, Haskell, etc. for the back end, they can all generate HTML. ;)
We hear a lot that Squeak is an environment for kids, hence the angry fruit salad color scheme and other things that hurt its credibility. What's interesting is that I hear from a number of people, including from Viewpoints Research Institute itself, that kids actually have a hard time using Squeak! The controls are too small for them to operate without errors, the text is small to read easily, using the scripting UI doesn't go smoothly, so they easily get tired an lose interest. So whom is the current Squeak UI designed for?
My frank opinion is that nobody, because it was never designed to begin with. Like many Unix application, it was put together by a bunch of people over many years without the benefit of a plan, direction or coordination in the interaction design aspect of it. I don't know how or if this can change without a core development team having resources to do non-trivial amounts of work that building native UI hookups would require--similar to Squeak Central of old, but with attention to the UI issues.
I wouldn't doubt it a bit. Fact is, I think few of Squeaks actual users are kids, Squeak is "THE" open source Smalltalk. It should be fixed up and made for adults and the whole kid argument dropped. The problem is, every time anyone suggests or attempts any serious change, like gutting out broken Morphic code and fixing things, a small vocal minority screams bloody murder that Squeak needs that stuff. Like the recent arguments about stripping out code that is only used in Squeakland.
That crap doesn't belong in the core Squeak image, isn't maintained, and should be removed. I have high hopes for 3.10 and Ralph getting things cleaned up. Eventually I'd like to see a fork and see a real adult oriented, business oriented Squeak emerge, I think the Seasiders would like this. Damien's images are a good start, as are Pavel's mini images. Ralph's idea that code that isn't tested doesn't exist and shouldn't be included sounds great to me. What better excuse to remove old bad code than "because it isn't tested or maintained".
The name Squeak needs to go as well. It's hard to take anything named Squeak seriously, and even harder to sell. There needs to be "one" core open source Smalltalk, that is modular enough to build distros from. Ruby and Python didn't gain mainstream acceptance by having 50 flavors each, nor will Smalltalk.
I have to agree with Vassili. I find the UI of Squeak to be pretty horrid. I don't like the fact that I have three different ways of clicking each gui object. Even after a month of regularly working in Squeak, I had a hard time remembering which button to click. The problem was probably compounded by the fact that I'm using a single button Mac.
The ugliness of the UI is an oft-cited problem of Squeak, but the haphazard lack of usability is a bigger problem for me.
Not that I consider myself a professional programmer, though I have been paid to create apps from time to time...
Way back, in the Win 3.1 days, I used Smalltalk/V to write a video post production "app". It would crash about once an hour, but I had it backup after each video edit log commit, so it was manageable.
When Win95 turned out to be less than what I had with my amiga ten years earlier, I moved to OS2/Warp for a year, then on to Linux where I've been ever since.
With Linux, it was perl in the beginning, but has been ruby in the last few years, where my current "app of the day" is a ruby app that calls a gazpacho created ui to provide the interface to a postgresql database.
But I always fondly remember smalltalk... and every eighteen months or so I decide to take a look at the current smalltalk situation, install some incarnation of Squeak... and choke, cough, sputter, and !#*&@.
Fixing the Squeak UI probably would be the most positive thing that could happen to smalltalk. It's hard for people (think OSS community) to think positively about smalltalk, to take up its banner, when their first exposure to it is Squeak. . .
It seems like most people here agree that Squeak looks awful and is far from user friendly. When looking back at the core design principles behind Smalltalk, especially where is says - "Because visual presentation overlaps heavily with established human culture, esthetics plays a very important role in this area." - it appears that Squeak is not doing so well in this area.
Usability and aesthetics are very important, and I don't think Smalltalk needs to look or behave like OS X or Vista or whatever, but the user does need to feel comfortable, and Squeak currently fails at both.
Since previous efforts to change this in Squeak have failed I would like to see a fork too, however I wouldn't call it an adult version. I would look at it as an opportunity to bring the 1980's Squeak up to date with today's usability, including Seaside (as most people would be interested in creating web apps), some sort of database (Storage Management) and removing all unnecessary the crap.
So, who is going to drive this project? :)
And that's the real core of the problem. Such a task would require a core team with the ability to work on Squeak full time, meaning they need to be paid. I haven't a clue how this will happen.
Would it really be that much work that it would require a team working on it full time? I'd say it would be mainly improvements to the interactive programming environment and removing unused code. Pavel has been removing unused code, if only I knew how to improve the programming environment :)
I don't know, maybe it wouldn't, but I think it might. I think it's moving in the right direction, maybe not as fast as I'd like, but I can't really complain unless I'm willing to get in and do the dirty work myself. Not that I wouldn't, but time is a consideration as well as I'm not particularly qualified to do said work. Of course, what's great about Smalltalk, is that whatever image I use, is my image, I'm in charge. I've fixed the things I felt I needed to have fixed to feel comfortable and at this point I find my image very comfortable.
It would be great if you could write a wee tutorial on how you customized your image as I have no idea where to start!
I would love to change the look of those weird looking tooltip balloons, remove the text and have good looking icons in the Tools pane (how about clicking on them rather than dragging), ... anyway, my list if pretty long but I have no idea where to start.
To Ramon Leon: Well Emacs itself it this image. So I'd argue it's very very close but in debugability.
To Joe Jones. What probably comes close is LispWorks.
Regards Friedrich
@Friedrich, of course, Emacs is the very incarnation of a Lisp image, and I'm working in it daily lately, but I have much to learn. But Emacs, in all its glory doesn't feel to me like it could replace my windowing system and be its own OS, though I'm sure some would say otherwise. Smalltalk does feel like this, SqueakNOS even makes Squeak a system unto itself for real. Overlapping windows and all, Squeak feels like an OS.
The best I've seen of Emacs are some of the Slime videos. I have a long way to go before I can claim to be a Lisp guru, but I'm going to work on it. I want all the great languages in my toolbox.
There is another alternative for those who want still want a more "professional" look in Squeak, check out Pavel's website at: http://www.comtalk.net/Squeak/87 and load the changeset.
I found it to be very usable. As far as I can tell, it has 2 minor bugs in it. I even loaded the changeset into Pavel's minimal Morphic image and it works fine.
Another note on ruby, in 1.9 you can do it even more like Smalltalk ;)
Smalltalk: window := Window top: 0 left: 0 width: 800 height: 600.
Ruby: window = Window.new top: 0, left: 0, width: 800, height: 600
It's still a simple Hash though, so will not work exactly the same, but close enough for most cases.
Still doesn't change that i deeply envy Smalltalk for its total reflection, having all the code directly in the image where you still have to lookup files/docs in ruby.
Smalltalk is really perturbing but wow it's great, and all the magic is inside :):) double wow. I learned A LOT with it and so, no doubt it's good even to go back to a mainstream (object) language.
I'm still impressed by the relative small size of the system. As you said squeak is more an OS (a 30mb one :) ) than a language (you can try squeakNOS with VMMaker).
Concerning, the UI... I'm pretty sure a web UI can be done relatively easily. Of course it won't be a "real" UI, not so responsive etc... I know people are reluctant with this idea ! But it will be a good place to experiment new "code browser" vision. We already have a browser... but we can go really really further !!! CSS+Javascript+Comet+Seaside...... We can even reinvent code browsing ;) ... The hardest part are things on the fly like syntax coloration I guess... Also bringing the debuger in the web page... Maybe the best way to do would be to have an independant UI image that can "web browse" a development image... etc, etc... If the web UI crashes, you still have the morphic debug mode ;) Someone already did something with a workspace, an inspector and a code browser, that were popping and were positionnable... (Dimitry Dorofeev -> mmm.seasidehosting.st/seaside/liveweb. Sorry, not working right now). I have plenty of idea...but no time at all... :(
Cédrick
ps: Just to give an idea, Javascript+CSS-> http://andrewcavers.com/ gives idea.]
I'm not a fan of the web UI approach, and I'm a web developer. Web UI's are good for simple interfaces, but I wouldn't want to program in one. The web sucks, browsers suck, browser widgets suck, flash sucks. The only successful use of JavaScript and HTML for building "real" user interfaces, IMHO, is XUL from the Mozilla project. Firefox rocks, all the apps built upon the XPCOM platform rock. If there's a new cross platform component system that's worth of using, XPCOM is it. If Squeak needs a new native looking UI, or close to it, XUL is the only way to go, IMHO.
Hooh, no 1 seems 2 like Squeak UI here :( . I love Squeak UI because it looks colorful and so simple that nothing distract me while coding. I do feel 3.9 look very boring, i love 3.8 with OutOfTheBox theme :).
BTW do any one know how to unload LookEnhancements in 3.9 ? I haven't used 3.9 much yet, so don't know much, but it seems that LookEnhancements are hard-coded. I have unjoined squeak-dev since several months so don't know if there is any discussion or patch-up for that.
It's not the colors people don't like, it's gawky ugly over sized windows that look childish and badly designed, and mostly, the compete disregard for standard UI conventions established by Windows and Mac.
Like it or not, standards are important and when things like copy and paste, double clicking the title bar, minimize and maximize don't work as expected you become so frustrated with the user interface you forget you fired up the image to see Smalltalk, not someone's bad interpretation of a windowing system.
Squeak's UI completely sucks, but I love Squeak. I'd never write an app in Morphic, but I can live in Morphic because once you become accustomed to the quirks, Smalltalk is the most productive development system in existence and Squeak is the Smalltalk where cool stuff is happening.
Morphic's one great advantage is that it freed Squeak from cross platform problems. Squeak runs on tons of platforms as is. Squeak looks exactly like Squeak, no matter where you run it, which also adds to its operating system feel.
I ran into Squeak a couple of weeks ago, the first Smalltalk environment I've got my hands on. Kind of humbling, frankly. Yes it's ugly, and confusing in places, and packaging and versioning are a bit of a nightmare, but considering we're stretching the 1980's into the 21st century this is not too surprising. What amazes me is that practically every genuinely interesting idea I've come across in programming is already there. Idiomatic programming, envelopes & handlers, refactoring, lazy initialization, template & hook etc etc etc.
I keep trying out things from my bag of "things I write when I learn a new language" - Conway's life, anagram solvers, that sort of thing - and finding that by the time I've stubbed it our I'm already done. It's so bloody consistent!
So, much to learn, but I'm loving it. This is the simulation language I've needed! Embarrassing I've taken so long to get to it. One of the obstacles seems to be that because it's a language writing language, there are lots of micro environments kicking around inside it, often doing the same thing. However - fabulous stuff. I can't believe people got so excited about "native java machines" - where's my native smalltalk PDA?
Exactly. People underestimate the value of consistency. Virtually anything can be done with a message send, little else is needed.
They key for me was that messages are not functions scoped to objects. I kept looking for the function name - then I realized why you don't need one. The fact that Smalltalk doesn't need boolean logic really makes the case for expressiveness.
I don't know if I'd go that far. First, let's call them methods, not functions. Functions depend only upon their inputs, methods don't since they access an objects private state. And they do have names, #ifTrue:ifFalse is a valid method name. #ifFalse:ifTrue is a different method name.
It may be nice conceptually to think of them as messages, but they're implemented as methods, and are only reified as real messages when a method isn't found. A message would be created and passed to #doesNotUnderstand. To reify every method call as an actual message object would be unnecessarily expensive.
Hi Ramon. I would've participated earlier, but I've been on a trip, which is winding down. To me, just the fact that Squeak has a GUI at all is impressive. How many dev. environments can claim this? So the aesthetics don't really get me down. The real beauty is in the language and the object model. Why are some developers so hung up on the aesthetics? I agree that the look and the name of Squeak probably causes developers to underestimate its abilities. It kind of had that effect on me at first, but what wows you is when you see someone do something amazing in it and you think "Now, how hard would I have to work to get that to work in what I'm using now?"
Writing code in Smalltalk for me is almost like writing, which is another activity I enjoy. I can think in terms of nouns (objects) and verbs (messages). Very nice.
It's true that the UI is disorienting at first. I went through that. I was wondering, "Where's the Start menu?" (I'm a Windows user). What's amazing to me is after I've learned Squeak more, if I look at one of the old Smalltalk-80 demos Xerox produced, I can still do everything in there with Squeak.
What really helped is I got a couple of Mark Guzdial's books on Squeak used off Amazon. For the edification of others, a good starter book is "Squeak: Object-Oriented Design with Multimedia Applications". It's a small book. He gets you started with the UI, some of the tools, and covers some of the Smalltalk language, getting into Morphic and such. He uses an older version of Squeak, but many of his examples work in 3.8 (if some don't, just try them on the version of Squeak that comes on the included CD). Guzdial uses the "constructivist" teaching method in his books, which can also be disorienting to some. He explains this up front, but some Amazon reviewers didn't like it. It doesn't lead you "down the garden path", giving you all the answers. Instead he covers concrete examples first, and encourages his readers to explore Squeak to find their own answers to problems he poses. It's important to do the exercises, otherwise you'll get little out of the book.
As for the Morphic/eToys discussion, I understand it. I was alarmed with talk of removing eToys from the standard Squeak image late last year, because I think it's an amazing technology, particularly for educational environments, and simulations. I've come to understand the desire to take it out though. IMO it's fine if some want to fork the project. Have one version for Squeakland (the kids), and one version for professional developers, though I suggested there be two versions on squeak.org: one w/ eToys and one without. I suggested the name "Open Smalltalk" for the "professional" version.
Good discussion on here.
I agree it should be about the language, but the UI does matter, specifically because with other languages you're allowed to use your existing tools, your favorite text editor, while Squeak "forces" you to use its UI. I'm accustomed to Squeak's quirks, but were I a newbie, I'd hate it, and most do.
I like "Open Smalltalk", and I'd like it even more were such a thing more pragmatic and aimed at developers of today, rather than future generations of children. Squeak and Squeakland should be separated and Squeak stripped down to a clean core of minimal code. Squeak imho, would do good to think of itself as the "Open Smalltalk" standard library. Goofy UIs, unmaintained projects, and experiments for kids don't belong in the standard library.
I see the future of Squeak in things like Pavel's mini images, or Lex's Spoon. Squeak needs to play better with the rest of the world, I shouldn't have to write shell scripts in Ruby because firing up a Squeak image for such a thing consumes too much resources. I'd like to be able to script in Squeak, as standard practice, but right now bash and Ruby scripts are far more practical.
The only pure scripting Smalltalk I know of is Vista Smalltalk, which runs on .Net 2.0 and is targeted at making WPF-type UIs.
On second thought you might want to try GNU Smalltalk. You can find it at http://www.gnu.org/software/smalltalk/smalltalk.html. One thing it says about it is, "An uncommon feature of it is that it is well-versed to scripting tasks and headless processing."
After taking a look at it, I realize I may have been mistaken when I said in the past that I had worked with it. The Smalltalk implementation I remember working ran on Unix, but it came in two pieces: a compiler, and a VM. The compiler would produce a bytecode file, which I would execute on the VM in a separate step. According to the description, GNU Smalltalk typically runs in an image, like Squeak, but it has a command line option where you can just have it execute Smalltalk code in a script file. If you just invoke it with no options it loads whatever is its default image file and brings up an interpreter prompt on the console, rather like Lisp.
Looking through what's termed the "obsolete" manual, they talk about a GUI and web framework as well, though when they say "GUI", they're talking about it interoperating with something like Tcl or Gnome.
Avi Bryant's site mentions GNU Smalltalk as a possible platform that would run Seaside, though it doesn't sound like he's tested it.
Follow-up:
I went to http://savannah.gnu.org/projects/smalltalk. Here's what they said about it.
"GNU Smalltalk is a full implementation of ANSI Smalltalk, including a graphic class browser, a high performance virtual machine, and class libraries for networking, windowing, testing, numerics, and XML processing."
I'll look into it, it'd be nice to be able to do real shell scripting in my favorite language.
"I see the future of Squeak in things like Pavel's mini images, or Lex's Spoon."
Did you meant Craig Latta's Spoon (http://www.netjam.org/projects/spoon/)?
Yup, my bad, Craig Latta's Spoon!
good one
The angry smalltaker...
This article comes across as a bit angry, but mostly I think he' s right....
Squak is only one kind of the Smalltalk system. Now I'm using Dlphin Smalltalk from Object Arts ltd. This system is fully integrated with Win32, so it's UI is familiar to you. The tools contain many productive tools and it generate compact code.
Please use Dolphin Smalltalk. The Community Edition of the Dolphin is free. You'll find very difference with Squeak.
As someone who has studied Smalltalk quite in depth, I agree wholeheartedly. Unfortunately, though, I'm sort of an armchair Smalltalker - I've not really been able to fully appreciate it by actually using it for anything serious. (Although I have used and enjoyed Ruby - and the first thing I thought of at the time was, "Hey, this is like a lite Smalltalk!") The biggest stumbling block with Smalltalk for me is also likely its greatest strength - it's the image-ness. I'm so used to thinking of small apps and isolated tasks that load/run/exit that I have a hard time wrapping my head around how to even toy with Smalltalk in a way that blends with the rest of my world. It's a very hard language to bridge into. Any suggestions?