Winging it

There's one big area that we, as Smalltalk developers, have tended to gloss over. Unfortunately, not only is it the hard problem, but probably of most immediate concern to new adopters. I speak, of course, of database connectivity, or, perhaps I should say object persistence.

Experienced Smalltalkers have been through the wars on object persistence, be it OO databases or object/relational mapping, and there's just no clear, simple answer. We know the value of an OO database, especially something like GemStone, which offers both objects and the ability to push object behavior onto the database server. On the other hand, we also know how important it is for some companies to have their data housed in a standard corporate data warehouse, which, whether we like it or not, will be DB2, Oracle or some similar relational database.

Developers just approaching Smalltalk may already have a relational database, or have some other application that needs to talk to that data. At this point, the great discussions vis a vis OO and OR mapping are of no concern whatsoever. They just want to persist some data somewhere so they can back it up or look at it with some other familiar tools.

Ruby on Rails has done this right - they've removed a significant barrier to adoption. It doesn't matter if it will scale or if the developer will have to do significant refactoring down the line. When that point is reached, the developer is probably invested deeply enough in the technology to bite the bullet and do the necessary work. In the meantime, the developer can quickly build a nice, safe MySQL database without the discomfort of actually having to do any SQL, mappings or any of that stuff, and know that all the data collected can be accessed using a plethora of third-party tools.

By contrast, the Seaside (the closest Smalltalk-based offering) adopter's options for persistence are "save the image", Goods, OmniBase, GemStone, or start up the object/relational mapping path. The first of these is fairly simple, but the knowledge requirements for the remainder start to expand fairly quickly, and, until we hit OR mapping, I don't have a clue how to connect a third-party tool such as a report generator. I'm not thrilled by these choices, and I've been using Smalltalk for just about sixteen years!

For the new adopter, RoR presents a fairly gentle initial slope that may or may not run into a steep mountain or cliff. By contrast, Smalltalk tends to offer a fairly steep climb right out of the box. No developer is smart enough to see whether the other side of the rise leads to another nasty climb or an easy downhill slope, but if they never start the climb, it doesn't matter.

We need to coax those new developers up the slope by offering our own gentle incline, and seducing them with the panoramic vistas beyond, not showing them a 10-metre rock face, and telling them that it's downhill after that! From my years in Smalltalk, that 10-metre face is persistence, first and foremost.

My friends, some of them Java developers some other VB and PHP like, wants a simple thing: Mainstream. I guess they want that because the kind of systems they build are "mainstream" systems, nothing crazy, nothing hard to do (and maintain) with other technologies. And I think it's the 90% of the systems are very "common", in the sense of not having anything technologically different.

 Here's what I noticed as I started looking into Smalltalk (and that's not so long ago):

• It's difficult to find out what is in the base libraries. I often implemented stuff just to notice some time later that the exact same thing is already there. I'm not sure how to solve that "overwhelming information" problem. Also, a lot of the documentation is of the "read the source"-style: there's an awful lot of source to read through.
• In a similar vein, there's not all that many how-to kind of guides. I'd like to have a quick cheat sheet for "send email -> look at class FooBar, query SNMP -> see SnmpThing>>example", some kind of higher level documentation than just the base libraries.
  
• A well organized and maintained goodie-repository. Sure, there is the public repository, but have a look at Perl's CPAN -- you can't really search for specific functionality in the public repository (unless you know the name), many goodies have non-obvious names, many are undocumented, many don't even have a comment what they are actually good for.

 I guess my biggest problem is #3 -- the repository as it stands is pretty unusable for the casual user, you've got no chance to find anything unless you know what you want.

    mjl

Well I'm a full-time .Net/SQL developer, but I would dearly love to develop websites with Seaside. But good relational database support is a must, and here's why: the whole point of websites at my company is to be front-ends to our relational databases. Our business is managing relational databases for big corporate clients. But gosh, asp.net is nice and all, but I get kinda tired of manually passing around a bunch of session variables just to get the back button working right. Seaside is pure beauty. If it came with something like Rails' ActiveRecords, that would be nirvana. One thing I'm unclear on though, is what happens when you go back to a stored continuation, and you've already put changes in the database. Is that problem the reason things are as they are?

    I think what killed Smalltalk in the 90s was the lack of a clean path for producing a shippable app. If there was a brain dead simple way to prune all the unnecessary classes/etc from the image, produce some form of executable, and have a generator that could build an installer, i think it would be easier to adopt Smalltalk.

[Found this page via Reddit. Don't know if I'll remember to come back, so I can be contacted as geeksam at gmail.]

[Comment doesn't appear to have posted the first time; trying again. Sorry if it shows up multiple times.]

As a student who's written at least a little bit of code in 8-9 languages over the past few years, I took an OOP class in Squeak last term. While Smalltalk-the-language was definitely impressive and fun, Squeak-the-UI really annoyed me. (Disclaimer: I haven't looked at any other Smalltalks; if any exist that, in particular, don't force you to work in their UI ghetto, I'd love to hear it.)

I already switch back and forth between the Mac and PC and have a hard enough time remembering which key commands I'm supposed to use where. Squeak adds a third set of keystrokes, mouse behaviors, window metaphors, and UI bugs to the mix and, well, my brain is already full, thank you. That Squeak's approach to its host platform appears to be "LA LA LA LA LA I CAN'T HEAR YOU" was, to me, the biggest barrier; Squeak forces the user to adapt to its conventions because, well, that's easier for Squeak. And talk about fragile: I got in the habit of saving my image every five minutes because I never knew what was going to crash it. When Windows ME looks stable by comparison, there might just be a problem.

Most especially, I found editing code to border on nightmarish. Small methods loosely coupled ==> lots of methods ==> lots of jumping around the code to figure out what's going on ==> lots of windows open ==> an extremely cluttered 1024x768 desktop (I have an iBook, at least until I replace it with a MacBook), with no keyboard shortcuts for navigating between windows and no click-through to controls on windows that don't have the focus. Even worse, Squeak's text-editing capabilities basically amount to Notepad with syntax highlighting. With such a wide variety of incredibly powerful editors available, forcing users to manually reindent code with arrow keys and Tab is just criminal.

I hated Morphic, too, but my opinion probably shouldn't be trusted there because my GUI development has been limited to VB and a few pokes at wxPython. (=

So, um... that's all pretty negative, not to mention outside your control. To reiterate, I really did like Smalltalk as a language, and I'd definitely rather write Smalltalk than Java. (One exception, though: adding code to other packages just feels dirty.) I found myself trying to figure out how to name a Ruby method something like replace:with: yesterday, so clearly I'd find something of value in Smalltalk... but as long as Smalltalk won't leave its apartment, I simply don't have a use for it.

Richard, I haven't looked recently, but Dolphin smalltalk has a very simple executable creator for Windows. But yes, creating a runtime application should have been made easier from the get-go.