On Smalltalk

I'll start by saying that I am a hobbyist programmer who eventually would like to become a professional programmer someday. I really like Smalltalk, I learned it about 10 years ago in a introductory university course but never built anything of significance in it. I kept my old Smalltalk textbooks but somehow I having a hard time translating MVC to the Morphic interface in Squeak. As for Seaside, there are either incomplete or missing documentation on the internet. I've tried the tutorials on http://www.shaffer-consulting.com/david/Seaside/ which are very good but they are still incomplete. I always seem to screw something up beyond repair when I try to adapt the examples to new programs. If possible, I would like to see a simple but complete tutorial on how to build a dynamic web application in Seaside i.e. an Address Book application or a Reservation System either integrated to an Object Database such as Magma or an RDBMS such as MySQL for persistence. That's my $0.02.

Can't help you with Morphic, never really got into it since I mostly build web apps.

As for simple applications, I'm sure there are quite a few on SqueakSource you could download. MagmaTester includes the Sushi store example using Magma. How about my mapping a blog to Postgres posts, did you not find them helpful? I've posted on persistence several times, as well as put up the SmallReddit sample app for just this purpose.

Some things I'm interested in learning/doing:

• How to do simple driven development in squeak
• How to do TDD in seaside
• How to develop REST based API using seaside
• Creating ATOM and APP Feeds
• Getting data out of the corporate datastore i.e. Oracle

Biggest problem is understanding squeak and smalltalk. I can program in java, ruby, python etc. but not in smalltalk. I have tried several times to do something in sqeak but for some reason i simply cant get done anything serious. Smalltalk is too complicated for me.

Tutorials and documentation! Those are what I see missing from Squeak and Seaside. The things that are out on the net are, as the anonymous commenter before me said, are either incomplete or missing. I would also add that many of them are dated -- for many releases ago of the environment/framework. Personally, most of what I read about Smalltalk and Seaside in blogs is geared towards someone that's way over the beginner level I'm at.

What I'd love to hear, if you can recreate it, is how in two or three years you went from a beginner to the obviously advanced level your at? What books did you read? What websites? What mailing lists? Etc. Basically, help those of us either new or newly returning to Smalltalk to follow the path you've traveled (cue "Kung Fu" theme music...).

I think the biggest challenge for Smalltalk newbies is the environment. Anything you write to help overcome that hurdle would be great.

Here is a challenge for you: how about writing an entry titled "Smalltalk for Emacs Users".

Best Regards.

[...] reprend ses billets sur son blog et demande aux nouveaux utilisateurs de Smalltalk et de Seaside : quels sont les barrières pour commencer avec Smalltalk ou Seaside ? Quels sont les difficultés que vous avez rencontré et sur lesquelles vous aimeriez avoir plus [...] ]]>

I come from a mostly Java background and have been trying Smalltalk/Squeak on and off for a bit since the language is extremely interesting.

However, Squeak is ... different to say the least. I spend my days editing/coding/debugging/versioncontrolling in Intellij, Eclipse, emacs. Here are the bits that trouble me the most: - source code editing: the class browser feels horribly inefficient for moving around source code and editing. This may be due to me not knowing all the keyboard shortcuts, maybe. Items: editing per method (with no visibility for the other methods) is painful; Squeak implements its own font rendering, is own windowing, its own everything: sadly this means that almost none of it is as polished or useful as the specialized bits I normally use (cleartype rendered fonts in Windows, emacs editing mojo, etc etc) - version control: it was not obvious, nor discoverable how version control works in a Squeak image. Or rather: I couldn't figure it out. - deployment and interaction with the outside world: none of the tutorials/guides I came across discussed this at all. That is bewildering because in any real project there has to be I/O and it has to run somewhere somehow.

These are the most glaring things I can list off the top of my head, I hope I get some time again soon to give it another try.

I agree with most comments above, however I would say the barriers of entry to Squeak/Smalltalk/Seaside are; * the environment, image based development concept is weird to most people * installation, squeak and seaside should be packaged. People who use seaside are not interested in Morphic, so all non web development items should be stripped out. * extremely ugly and weird looking squeak (Seaside could maybe use a striped down version from Pavel) * hardly any documentation on how to use a (OO)DB with Squeak/Seaside * missing documention on team development, version control, deployment

I've just started actively playing with Seaside and Pier and I'm starting to feel a little comfortable with it. But I am lucky enough to have someone who is quite experienced with seaside on my IM list to ask questions of so I've hit a few less road blocks (or rather I've found ways around these road blocks).

Personally, I don't think the environment or the lack of documentation is a huge problem. Once you get a few tips with squeak (like being told about command m and command n) I find it only took me about an hour to get comfortable with it. And seaside (largely because it is written in smalltalk/squeak) is pretty good at being self documented once you start digging in.

What I really think is missing, and wasn't missing for me, is a place to ask stupid questions. This could be through irc or a beginners mailing list; it is just important that it has an archive so that it can be searched.

A package or a prebuilt image would be nice (though aren't there a lot of prebuilt seaside images already) but I think an up to date install tutorial would be even better. Digging through and installing seaside with monticello was a great learning experience.

And finally, there seems to be a big lack of accessible problems. That is a place where new comers can find things that others need, contribute their solutions, and then have their contributions critiqued and corrected by members of the community. The drupal community is excellent for this sort of thing because you have a lot of end users using it creating simple requests that a new developer can approach. Where as in the seaside community, most people seem comfortable with solving their own problems.

I think it would a great stepping stone if there were some public list of problems, even if some of these problems are doctored.

OK, plenty of good feedback. Seems Smalltalk itself is biggest problem, I'll see what I can do.

My primary concern while writing Seaside applications is about scalability. In other words, how to configure a system to work for a hundred simultaneous users? It is already clear for me the incredible productive boom if we use the image for transparent persistence or the Magma database, but it´s enough?

Maybe some reports about your experience, if you already configured apache to do load balance and reverse proxy and how to do this would be very useful.

Another concern is about internet hosting. We have today the http://www.seasidehosting.st to host our applications for non-commercial use. What about a commercial one? How can we contribute to make this dream come true?]

I wouldn't say that Smalltalk itself is the biggest problem, but rather, the Squeak implementation of it and lack of completeness in the documentation is. The Squeak environment is my largest hurdle in becoming comfortable with developing Smalltalk programs.

Squeak is too closed off from its host environment, and that itself really limits the scope of application in using Squeak for development work.

The seemingly unfinished GUI interface that we get in Squeak (the incoherent Trash bin interface, inconsistent GUI theme, context menu options that spawn DNE errors ... etc.), makes exploring the system somewhat frustrating at times. Developers need to pay more attention to the fit and finish of the GUI. Don't just let your high standards stop at programming designs, follow through and deliver the complete package.

While the various browsers are very useful in code exploration, it quickly became painful for me to toggle between 5+ browser windows when I try to code my own project while looking at examples from other projects. Just because the browser UIs were designed this way in the beginning, it doesn't mean that it has to stay that way. Code navigation still needs improvement. Romain Robbes's Browser Booster should come standard (and work with the newest OmniBrowser)!

The lack of project overview and developer's manual (message protocol documentation) in many of the Squeak projects also makes it harder to understand how to leverage the various community contributions to our own benefit. Developers need to make use of that wiki function in SqueakSource! And when there is documentation, please try to be as complete as possible! It is very frustrating to only "kind of" know what you're doing!

Over-reliance on the mailing list to provide documentation is a problem. Mailing lists contain a lots of discussions, and it takes a lot of time to filter through those information to actually find what one is looking for. Again, documentation should be put in a format that is more easily search-able and navigable. A search-able wiki is preferred over mailing lists.

The lack of dependency resolution tools also can make updating software packages a pain in the rear-end (wait, the latest Pier depends on Seaside 2.8? Is there a place where I can count on to find information whenever I need it?). The Package Universe is nice, but it doesn't work well with the rest of the software repository tools (Monticello, SqueakMap). There needs to be one tool that can deal with loading/removing software packages reliably, if that tool can do version management, that's even better (ie., adding dependency resolution function in Monticello).

The Smalltalk language is beautiful. But there are a lot of things that the Squeak community, in particular, can do to bring that beauty from the inside out, so that we, the newcomers, can walk into that beauty with less tripping and falling.

Currently my biggest barrier to entry is time; I've gotten to the point where I can get in there and hack with it a little, but not to the point of building anything interesting. However the thing I've found confusing with Seaside in the past is the whole stranger in a strange land factor. Being unfamiliar with the language, the idioms, the user interface, the source control, everything. There's just a whole "where am I?" thing going on at first. Finding a good dev image was difficult, finding menus, shortcut key commands, everything.

Squeak is just not as compatible to Unix/Linux environment as python or ruby. A couple of things can greatly help:

1. Porting Seaside to gnu-smalltalk;
2. Ajax based smalltalk browser;
3. Stripped down images, core+GUI, core+seaside+webUI, etc.;
4. Packaging.

Some crazy ideas:

1. Implement a squeak image file system so you can mount, explore and change methods/objects with linux/unix/plan9 tools;
2. (this probably has been done) Redirect Transcript to unix/linux console;
3. Emacs mode/Eclipse plugin for smalltalk browser;

For some reason, i get the sense that squeak hackers look down upon the unixy way of doing things. But why can't they co-exist?

Many of those things have been done, or at least been prototyped. For example..

http://www.cincomsmalltalk.com/userblogs/avi/View.ssp.

http://wiki.squeak.org/squeak/708

The problem, btw, is that Linux/Unix is based on the philosophy of files, everything is a file, while Smalltalk is based an idea that goes even further, everything is an object. Should Smalltalk give up everything that makes it great to conform to the Unix way... No! If you want that, use Ruby, that's exactly what it is, a file based Unixy Smalltalk. What does that get you? A cool language with really shitty tools. Smalltalk isn't just a language, it's an environment, just like Unix, but with a different philosophy at its core.

Anyone who actually wants to do Smalltalk in Emacs/Eclipse, IMHO, doesn't really "get" Smalltalk, because they don't see how crippling such a thing would be to the Smalltalk way. Gnu-Smalltalk is the exception, not the rule, to quote Kent Beck, "Source code in files. How quaint".

Wanting to edit Smalltalk in a text editor is like wanting to edit your spreadsheet in a text editor, text is dead, and you'd be missing the whole point of the environment and the dynamic nature that comes with it. It makes no sense.

I don't think Smalltalkers look down upon the Unix way of doing things, they just balk when people want to take away their advanced tools to force Smalltalk into a Unix mindset. Smalltalk can interact and live in a unix system without having to become Unixy.

An Ajax based Smalltalk browser, already implemented as a prototype in Seaside, but no one in their right mind would use it. Squeak is far more powerful and completely cross platform. Yes, Squeak is a bit weird, the price you pay for being totally cross platform and totally acceptable for building Seaside apps because only the developer ever need work in Squeak.

The whole WebUI to a Smalltalk image however, is just an incredibly bad idea. A web page will never have the power or speed of a real IDE, I sure as hell wouldn't want to work in one nor would I see any logic in reimplementing from scratch all of the existing fantastic tools that exist in Smalltalk to a less capable UI.

If you want to write desktop apps, Squeak isn't for you, but if you want to write web apps, Squeak is the place to be because that's where Seaside lives. Seaside is developed in Squeak, other Smalltalks will always be waiting for the latest port, which will always be out of date.

"Stripped down images, core+GUI, core+seaside+webUI"

Those all exist already, one only has to look or ask, http://damien.cassou.free.fr/

The Unix way is cool, but there's room in the world for more than one way.

Hi Ramon,

I have been reading your blog for while - great stuff! In my first post I will have to disagree with you about the AJAX WebUI - I would use it. Why? Other than not being in "my right mind" :-) here are a few reasons:

1. Squeak's GUI is very slow and eats a lot of CPU cycles. I have AMD Sempron 3000+ with 1GB of memory and I can't even play YouTube movies (just listening to the music) in the background when I use Squeak. Properly developed AJAX front end will be faster than the Squeak GUI - period.

2. If my application is deployed on remote server - I don't want to deal with VNC to work with it.

3. The fonts you get in a regular text area in a browser are more readable that the somewhat fuzzy fonts in Squeak. I went through the trouble of importing my own font into Squeak. Most people don't care about this but there are still plenty that do:

http://joelonsoftware.com/ Check the front page and forums if you haven't done this already.

Five months ago I spent couple of week playing a bit with Seaside and building a small Morphic app:

http://itstartup.com/aquarium.zip

The problems I found - slow Squeak GUI and resulting application. In just two week of playing with the environment I had to fix 2 bugs in the image (Morphic related). Very inadequate and antiquated documentation. Reading various newsgroups I realized that people don't care about Morphic - there is some talk about Tweak replacing it. Multiplatform issues - keyboard events are not really handled the same way on the different platforms. I could not get them to work on the Mac OSX at all, on Windows if you want to handle the event when user hits the 'A' key you have to listen for 'A' but on Linux you have to listen for 'a' (or vice versa - I forgot)

Having said all that - Smalltalk and Morphic are an amazing technologies and I had fun playing with them.

If somebody really wants to develop a desktop application - they should look into Dolphin Smalltalk:

http://www.object-arts.com

Just for the record I really like the Seaside approach of generating xhtml and using CSS to style it. I think I am in the minority though.

Keep cranking out those articles!

Best Regards,

--Eugene

Hi Engene, let me address those points really quick

"Squeak's GUI is very slow and eats a lot of CPU cycles. I have AMD Sempron 3000+ with 1GB of memory and I can't even play YouTube movies (just listening to the music) in the background when I use Squeak. Properly developed AJAX front end will be faster than the Squeak GUI - period."

I don't see such issues, Squeak is quite snappy for me, even on my laptop, nor do I find myself trying to watch YouTube videos while programming ;). Secondly, a properly developed AJAX front end won't ever happen because they'd have to recreate a vast number of tools to be able to compete with the tools available in Squeak, and that's just not going to happen. Squeak isn't just one browser, there are many.

"If my application is deployed on remote server - I don't want to deal with VNC to work with it."

Seriously, that's just not how things get done anyway. If your application needs more than 4 or 5 concurrent users, you'll be running 10, 20, or more Squeak processes to handle the load and take advantage of multiple processors on the server. That being the case, interacting with those images is rare, it's more likely you have a local image you use as a deployment build and simply copy it out.

"The fonts you get in a regular text area in a browser are more readable that the somewhat fuzzy fonts in Squeak. I went through the trouble of importing my own font into Squeak."

I haven't use Squeak's native fonts in years, I use Win32 native fonts in Squeak, they read just fine.

As for Morphic and desktop apps, that's just not where Squeak is useful. Users aren't going to use Morphic, Squeak strength is in building web applications in Seaside and experimenting with language design because you can modify the VM or mess with things that other Smalltalks don't allow. Seaside for example, was implemented in Squeak because adding continuations to Squeak was trivial.

If you want to develop "Windows" desktop app, then Dolphin Smalltalk is certainly a great way to go.

Ramon,

Your post has generated some very interesting comments and has given me some food for thought.

I have worked in Smalltalk for over 20 years and I am still somewhat mystified that Smalltalk hasn't caught on more than it has. The language and the development environment puts incredible power in the hands of any developer who "takes on the language."

I have always felt that the development environment was a major part of the appeal and power, but to hear people complain about the browser and ask for a text-based interface makes me wonder...

Back in the early days of Smalltalk, the barrier to acceptance seemed to be the fact that you needed to think differently to program effectively in Smalltalk, that you needed to think in an "object-oriented way". If you thought and wrote FORTRAN in Smalltalk you weren't going to be very happy.

The proliferation of C++, Java, and Ruby seems to shoot down the theory that thinking in an "object-oriented way" is a barrier.

On the other hand, I refuse to believe that making a prettier browser would actually improve the popularity/acceptance of Smalltalk. All of the other languages thrive in text-based environments.

Perhaps the browser is the problem. The browser does force you to think and program in a certain way. We're talking barriers here and I think that learning to think in the way required by the browser just might be the barrier. There is a knack to using the browsers in Smalltalk, just like there is a knack to using keyboard shortcuts in text editors. The difference here is that in Smalltalk, you can't just "type code", like you can in a text editor - you have to learn the knack, before you can do anything.

I spend my days switching between EMACS, VI, Squeak and VisualWorks, Linux and Windows and I'll tell you that the shift in gears for me is the greatest when I drop into Smalltalk mode. Once I'm there and hitting stride, I am most productive, but there is a noticeable "hitch in the giddyup."

I'm not necessarily proposing that a file-based Smalltalk is the solution. I am suggesting that perhaps some thought and effort should be put into combining the best of both worlds.

Off the top of my head, I can imagine a flattened code browser, that uses a grep-like interface for finding chunks of code to read/edit.... This approach would lower the barrier for getting introduced to the language and the browser (where perhaps the real power in Smalltalk lies).

I can think of other things that are "wrong" with Smalltalk, but none of these things become problems until you've been at it for awhile. What I've been hearing from the other posters is that getting started is the problem.

First of all the squeak environment is unfamiliar; secondly it is genuinely not that easy to use. An example is that if I want to know the complete protocol of an object, I need to create an instance, inspect it, then in the inspect window right click to get the menu item to open a window that shows me the protocol. That won't show me the whole protocol as one list.

Secondly, there's no complete class reference or design document. The classes themselves don't have embedded documentation either.

Finally, many tutorials are old.

So far, your quick guide has been the most useful thing I've seen, along with the outdated "FruitTree" example, which I managed to update.

Actually Marcin, you just need to right click the class and say "browse protocol".

"Secondly, there's no complete class reference or design document. The classes themselves don't have embedded documentation either."

That's also not the case, or rather, it's not so much in the latest Seaside sources. The developers have been adding class comments to the classes constantly due to feedback from the mailing list. You just need to load up the 2.8 sources in a spare image and explore the classes a bit.

But you're right, documentation and especially examples are sparse, such is the nature of small volunteer communities that haven't yet gained the kind of critical mass that brings in the writers and teachers. Right now the community consists mostly of builders.

@Dale, you have some interesting points which I'll address in a post.

Ramon, when I middle-click (right click activates the halo) anywhere in the class browser, I do not get that option. I am currently using seaside 2.7. I'll upgrade to the latest version of everything possible, and see where I get from there.

[...] What are the Barriers to Entry for Smalltalk and Seaside? [...]

Marcin, are you on a Mac? I think it's different, in any case, the hotkey is alt+p or cmd+p on a Mac. Check your preferences and change your mouse settings until right clicking brings up a context menu and middle clicking brings up the halos. I find this the best feel.

Oh, and while trying to customise my environment, it's possible to put squeak into a state where it just hangs around recompiling classes. This is likely to be something annoying which I'm going to have to work to undo. I've still not worked out how to add things to the tools flap.

In summary, I'm going to add the big annoyance that the environment is not slightly self-documenting.

No, I'm on Linux. I can get a context menu. It just doesn't have that option for the browser in the version of Squeak 3.9 I was using. I've upgraded to an even more recent image, and it's there.

"it's possible to put squeak into a state where it just hangs around recompiling classes"

I have no idea what you're talking about there. As for the tools flap, if you have the preference systemWindowEmbedOk enabled, then you can pull up the halos, and use the black halo to pick up any morph and just drop it onto the tools flap.

Yes I have no idea how I did that either - I was trying to rename a tile. Squeak became unresponsive for about 5 minutes. Because it's purely graphical and menu based, there's no audit trail for what I did. I'd much rather have an emacs-style interface to access the functionality (something like Slime). Right now about the only good thing that I can see is that there is a browser, but it doesn't seem to be a very good implementation of that concept - for instance no way to right-click and choose to add a method. It took me long while to work out that I was supposed to select a category, then replace the "template" shown with code.

Sure there's an audit trail, just look at your recently logged changes. You can find changes on the world menu.

Sure you can right click and add a method, it's in the method context menu. Replacing the template is just faster, as is realizing all methods are templates, changing the name always creates a new method.

No, really using the squeak-dev-123 image there isn't an option on the context menu to add a new method to a class in the browser.

Another barrier is that upgrading to the latest version with the comments is broken "out of the box," and that the upgrade process is incredibly slow, possibly because of file IO.

As for "changes" it doesn't tell me what I've done in the UI, how I triggered it, or what the effect was. It's the classic problem with UIs - they don't have an accessible, continuous transcript of operations.

Sorry, not "UIs," "GUIs."

@Mark: Make sure you have selected a class in the browser. Then bring up the context menu in the class pane. You should be able to see an option called "browse protocol (P)". The context menu is long, so you may have just missed it. Try this, after the context menu shows up, type "browse" on your keyboard, that should gray out all the other options that doesn't start with "browse", and you should be able to find the "browse protocol" option easily.

@Ramon: BTW, the Omnibrowser in squeak-dev-123 image is a bit slow. When you select a class, sometimes you will see a dialog box flash by, going through multiple messages indicating that it's parsing some changes or something like that, but it's too fast to actually read what the actual messages are. However, the delay is there (feels like 1 to 2 seconds).

I actually like the Smalltalk environment, the ideas are sound, but I don't think Squeak has them implemented well enough. Some context menus are way to long, and again, many context menu options don't even work. Squeak seems to be an environment full of experiments, while this keeps Squeak on the cutting edge in many aspects, it's also its weakness. Many users want a development environment that is more complete, organized, and polished.

One gripe I have with working with images though, is that a lot of times I tend to screw up some object state and I don't know how to identify whether it is undoable or not. It would be nice if you can write up a blog entry about using the debugger and how to identify when an image is screwed up beyond recovery.

"No! If you want that, use Ruby, that's exactly what it is, a file based Unixy Smalltalk. What does that get you? A cool language with really shitty tools."

In this case, Unix is Ruby's IDE, which works across several languages out there. Squeak insulates itself from its environment, which some see as a benefit, but most see as a liability. There is an entire universe of tools that have been carefully designed and tested to which Squeak raises it's nose at and says "Not Invented Here".

"Anyone who actually wants to do Smalltalk in Emacs/Eclipse, IMHO, doesn't really "get" Smalltalk, because they don't see how crippling such a thing would be to the Smalltalk way."

Some get it: some just plain don't like it. To them, maybe not having adequate access to the host and all of its power is a crippling thing.

See how most of this is subjective? See a pattern here? There are plenty of people that have tried Smalltalk, understood it, yet decided against using it for whatever reasons. The same can be said about every language. Bringing other languages into an advocacy post is a silly thing: it doesn't accomplish anything.

"There are plenty of people that have tried Smalltalk, understood it, yet decided against using it for whatever reasons."

Which is fine, there's a difference between not liking something, and not using it vs trying to make it into something it's not. There's nothing subjective about it, if you don't like Smalltalk, don't use it, but don't whine about how it doesn't work with your favorite tools.

The people who choose not to use it aren't the people I'm talking about. BTW, have some balls and stop posting Anonymously.

I am currently looking into Squeak/Seaside for inhouse development. My last encounter with Smalltalk was VisualAge/Smalltalk back in 1997 and I feel that it is all coming back to me pretty quickly.

My main gripe right now is that the Seaside docs are out of date - it took me a while to find out about WARenderCanvas being the new default canvas for example.

Docs are always out of date, that's the nature of documentation. Far better to look at sample applications found on SqueakSource, or here. Once you understand the basic design (see my Terse Guide To Seaside), and how to look at the tag classes, you won't need docs, the Smalltalk browser and the source are a far better reference than any doc could or will ever be.

For me, a newby to ST, the biggest barrier to entry is Squeak's GUI. The other options are worst or commercial.

Squeak's GUI is horrible, expecialy when talking about aderence to de-facto norms and keyboard navigation...

I think the lack of documentation is a minor issue. Most code is quite auto-documented compared to rails' or any other piece of software i've ever read.