Which Smalltalk?

There is a driver for mongodb as well...

I give bonus points to CouchDB because there is no driver needed, just HTTP.

ORM is weak? What about GLORP?

I agree completely that the ORMs in Squeak are bad, and many abandoned, but as of six months ago, ROE still worked. ROE is not an ORM per se; rather, it's something close to LINQ on a SQL database: you write your queries in relational algebra, building up an AST. The AST is only ever compiled to SQL and sent to the database when you're finally ready to do the query. This allows easily building up a query over many methods by passing around the query object and avoids dealing with an ORM, since at the end of the day you're still just getting back the SQL model, rather than trying to cram it into an object.

A quick overview of Roe is at http://www.cincomsmalltalk.com/userblogs/avi/blogView?showCo... and the current source is at http://squeaksource.com/ROE.html . Note that ROE only supports PostgreSQL, but that's okay, because that's the only meaningfully supported SQL driver in Squeak/Pharo. Supporting other databases is actually quite easy in one front, but useless on another: I ported it to SQLite and MySQL around 2005, but never shared the changes, because MySQL simply cannot meaningfully optimize the queries generated by ROE, and SQLite at the time required a very unstable FFI wrapper that crashed the image constantly. If there's interest, I think I still have that code lying around somewhere.

You don't have distinction between runtime and development time. Which means you can debug live. It's a bit like being logged in an IRB session on your rails application. Except that you have better tools than a plain command line.

Ruby feels closer to Smalltalk than Obj-C to me.

If you're familiar with Cocoa/Obj-C, you can have a look at http://www.fscript.org/

Smalltalk tries to solve the problem of mutable state in a unique way. Where some languages say "mutable state is bad, minimize or isolate state changes," Smalltalk gives you amazing tools for monitoring the state of objects in the system. The level of control at every level of execution is unlike any other language. You can open up live inspectors on any object, edit a method in the debugger and restart the stack frame you are looking at, and persist all of it across programming sessions in the image.

Here's a short description of the debugging process for web apps written in Seaside:

http://news.ycombinator.com/item?id=1887874

For me the key thing about Smalltalk is that its handling of abstraction scales well. On one hand, it's a modern, garbage collected, dynamic language in the same vein as Ruby, Python or Javascript. On the other, it give the programmer a lot more low-level control than any of those languages.

For example, Seaside makes heavy use of continuations. In most languages, you're at the mercy of the language designer as to whether continuations are supported: Ruby has them, but Python and Javascript don't. Smalltalk hasn't traditionally supported continuations, but it provides low-level control of the stack, and Seaside implements continuations as part of the framework.

Here's another, less exotic, example. Smalltalk provides GC-safe ways of manipulating raw chunks of memory, which other dynamic languages tend not to do. A couple of years ago, I needed to implement a specialized type of timestamp in Smalltalk. For my application, there would be many timestamps in memory at once, so optimized for memory usage. Internally each instance stored the number of seconds since March 1, 1980 as a 32-bit unsigned integer.

More recently, I implemented a timestamp object in Javascript. Without the level of control that Smalltalk allows, I ended up just wrapping Javascript Date objects. I don't know what the internal storage of Date objects looks like, but I bet it's more efficient than anything I could implement in Javascript.

You see this kind of thing all over the place in Smalltalk. Here's a comment I wrote a while back on syntax:

http://news.ycombinator.com/item?id=1289177

It's a bit hard to quantify, but I find this scalability of abstraction to be one of the key things I look for in a programming language. I'm not a Lisp hacker, but my impression is that this is one of the primary virtues of Lisp as well.

With Smalltalk? Sure. With Seaside? No, that's not what it was designed for.

I haven't yet convinced Twitter to do a rewrite in Smalltalk ;). But it would be a step up from Ruby, even if only to get a better garbage collector.

You're correct that most Smalltalks have a changes file that keeps a log of everything you've done, but that's now how you do version control or share changes. The changes file in practice is more of a kind of local version control, or unlimited undo buffer. For actually sharing changes, there are two systems that I'm familiar with:

Pharo and Squeak Smalltalk have a DVCS client named Monticello that they use. It works similarly to Git/Mercurial/Bazaar/what-have-you, except that it versions classes and methods semantically instead of the actual changes file. This ends up working fine, and even has some major benefits (you can kiss whole swaths of problems goodbye when you're doing a semantic merge),but it does mean that your Smalltalk code requires its own version control. You can see a quick tutorial of how Monticello handles merging at http://www.lukas-renggli.ch/blog/monticello-merging , and there's what amounts to a command-line interface called Gofer you can read about at http://www.lukas-renggli.ch/blog/gofer . Most people I've seen just use the graphical interface though, which is documented (somewhat) at http://wiresong.ca/monticello/v1/docs/ .

VisualWorks Smalltalk has its own version control system, also semantic, but not distributed, called StORE. I haven't worked with it much, but the general idea is the same: version classes and methods rather than the changes file. I know it can at least import Monticello repositories as well, and possibly work with them natively, but I've never done that, so you'd have to do some more research.

We solve it by building Smslltalk-specific version control. Monticello, which cwp and I built for Squeak, is a Smalltalk-only DVCS that predates git and hg and has become the de-facto standard. Earlier systems include ENVY and StORE. After using any of these, flat-file, language un-aware version control feels clunky.

IBM Smalltalk (now owned / supported by Instantiations) and ParcPlace Smalltalk both had a revision control system called ENVY. It maintained a separate database that contained all the different versions of source for all your projects, and had a system for building up a new image containing the versions you wanted. I used to build a new image from scratch every morning before I started work, so I knew I had the current latest code. It was the best version control system I've ever used.

In general I find that if you ask "Ah, but can smalltalk do Y?" the answer is yes, and better than what's considered standard elsewhere and also 5-30 years earlier.

Whenever smalltalk comes up I'm always surprised that I don't use it more often.

I think the Squeak license changed with version 4.0...originally it was not the MIT one.

Edit: In looking into the history, it seems the license has changed several times.

It's even more nuanced than that: the Squeak project took the time to actually do a full hunt for all of the old contributors, figured out who they were, rewrote their code when necessary, and got signed legal agreements authorizing the relicensing of their code under the MIT license. The Pharo project took a more practical but somewhat more cavalier approach without the lawyers and signatories. So there is actually the chance, though I want to emphasize very strongly a ridiculously tiny chance, that something in Pharo is incorrectly licensed at this point, whereas Squeak is legally unquestionably fully MIT licensed.

That said, unless you wear a tinfoil hat, I cannot imagine anyone seriously not using Pharo due to the above.