You don't know objects if you don't know Smalltalk

merlyn on 2006-09-22T14:17:47

I've often argued that a programmer who says "I know objects" without having touched one of the "pure object" systems like Smalltalk or Eiffel, doesn't really know "objects". When people would ask "what is smalltalk?", I'd point them at Squeak.

Well Keith Fieldhouse has gone and done the next good thing: he's written an article for OnLAMP about Squeak that gives far more handholding than I've been able to do quickly. Yeay Keith. That one's going into my bookmarks.


seaside

slanning on 2006-09-22T14:56:05

I read an article (increase URL number from 40 for more pages) in GNU Linux Magazine / France recently about Seaside, which is web framework in Smalltalk. I found it very interesting, since I think that it (finally) abstracts away (in principle, at least) the HTTP session / webpage crap that you always have to worry about with web app programming. I was a bit disappointed by the syntax, though; not sure if that's due to Smalltalk itself (which I'm not familiar with) or what.

For example, this stuff for making HTML elements. I don't want to even know it's HTML. Just a Qt-like interface that happens to drive a web app. Signal, slot, connect. Widget, add to window. Seaside does get something right with how you don't care about submitting webpages (see also, for example, this tutorial, esp. the sections on forms, call/answer, and tasks).

Smalltalk syntax

ferreira on 2006-09-23T01:50:24

The point of Randal was that objects are the realm of Smalltalk. Objects, classes, methods, messages, blocks/closures, metaclasses, collections and other tens of concepts and tools we know by heart (maybe with other names) for the sake of our knowledge of OO. But Smalltalk is surprisingly minimalist in semantics and syntax. Some things are weird: for example, 1+1*3 evaluates to 6 = (1+1)*3. Other things are just easy: like playing with objects with expressions like message cascading. Smalltalk urges for small methods due to that superficial nature. I think its grammar should be as small as the ones of Lua, TAP and other little useful languages. In Smalltalk, everything is an object and everything else didn't make it into the language (which means no syntactic sugar we are used to).

Squeak is a Horrible Environment

Shlomi Fish on 2006-09-22T22:30:53

See what I wrote about my encounter with Squeak when the topic was raised in the Joel on Software Forum. I also ranted about it a bit in a mostly-Hebrew thread in discussions@hamakor.org.il. Generally, I feel that Squeak is so unconventional that an old dog like me can never get used to it without losing his sanity in the process.

Squeak looks like a Smalltalk Environment

ferreira on 2006-09-23T01:34:43

I am not quite sure - because of my limited experiences - but I think Squeak is quite a decent Smalltalk environment. Of course, it doesn't care if you don't get the point of a Smalltalk environment. You have to educate yourself with the operational hocus-pocus of the system to appreciate it. (Just like you need to get familiar to the weird ways of Perl - for those who come along from all other languages: be it C, Scheme, Prolog, Pascal, etc.) Books like "Smalltalk 80: The Language" and "Smalltalk 80: The Interactive Programming Environment" may give you clues on how to use it. Indeed it is very different. It is a personal choice if the effort seems worthy or if you're curious enough to learn/absorb something before quitting.

Re:Squeak looks like a Smalltalk Environment

Shlomi Fish on 2006-09-23T17:08:58

I am not quite sure - because of my limited experiences - but I think Squeak is quite a decent Smalltalk environment.

Maybe it is. But it still does not play nicely with the other kids on the block, and has its own (antiquated and obnoxious) ways of doing things.

You have to educate yourself with the operational hocus-pocus of the system to appreciate it. (Just like you need to get familiar to the weird ways of Perl - for those who come along from all other languages: be it C, Scheme, Prolog, Pascal, etc.)

Sorry, I disagree. I've learned many diverse and different languages in my time. But they all required writing text, and running the program from the command line, and did not default on using the mouse, or using the GUI for creating new classes, or whatever.

Why does Squeak has to do all that, and not give me a way to write everything I need in text? Why does it still export and import files whose lines are terminated with CRs (not LFs or CR-LFs, mind you). Why can't I create new classes by writing good-old text? And why do I still need to use the mouse a lot in it?

Sorry, but all these things are major usability problems, and I (and many others) would not be willing to tolerate them. If the Squeak hackers wish to make their environment more popular, then they should work on overcoming these childhood diseases of it. Otherwise, they'll lose most prospective programmers, who cannot stand Squeak's stupid misfeatures.

Re:Squeak looks like a Smalltalk Environment

Aristotle on 2006-09-23T17:33:11

No, they’re not problems. Be careful. You are stuck in your comfort zone.

Smalltalk just doesn’t work the way everything you know works. It’s a different world view, and it’s self-consistent, and doing things the way it does provides opportunities that your traditional approach does not give you. That is part of why Smalltalk has had trouble gaining traction – it requires complete buy-in to its world view, which it then rewards richly.

Remember, a language that doesn’t affect the way you think about programming is not worth knowing. Smalltalk definitely is.

Re:Squeak looks like a Smalltalk Environment

Aristotle on 2006-09-24T00:18:23

After the last reply, where I wasn’t very specific about why the Smalltalk way makes sense (which bothered me), I went running errands, and on the way back home it occured to me how to explain it: basically, developing in Smalltalk means using a graphical read-eval-print loop. All your code is live, all the time, and you use the browser to tweak and prod while it keeps running in the background.

When you’re finished, the running VM instance is your program.

The source code you see is a mirage – it only exists while you’re viewing/editing the particular method.

Obviously, that is very different from all the other languages you know, but it also truly is a valid approach. Give it the benefit of the doubt for a while and see if you can get used to it, because if you can, it’s a very powerful way in its own right. You’ll never look at IDEs in the same light again.

I agree; which makes me puzzled

Aristotle on 2006-09-23T03:57:48

What amazes is that, knowing you are an old-time Smalltalker, you say stuff like CGI parameter parsing and form generation need tight coupling. It just makes no sense coming from someone who I know understands OOP really well.

I’m not bringing this up here to ridicule you or anything; it honestly bewilders me that you would make (and then, in fact, fervently insist on) such a claim.

Re:I agree; which makes me puzzled

merlyn on 2006-09-24T16:53:12

Perhaps it's inconsistent to you because you don't realize that while I believe objects are the key to larger programs, I'm also very practical.

In the thread you cited, I'm arguing for tight coupling only for small programs, but since many programs are small programs, the tight coupling will help many and harm no-one. Clearly, once the "CGI Application" gets above two or three pages of forms, you'll want to go into "big program mode", and use a proper templating system and all that. I'm not arguing against that. I'm just arguing on behalf of "the right optimization for the right job".

Version control

jplindstrom on 2006-09-23T15:40:36

With everything in the image, how is source/version control handled?

Re:Version control

Aristotle on 2006-09-24T00:11:14

The live objects are versioned within the image. I didn’t get that far so I don’t know specifics, but every Smalltalker I’ve listened to raves about how versioning in Smalltalk completely leaves text-based source control in the dust.