

Avi Bryant: MagLev recap - toffer
http://www.avibryant.com/2008/06/maglev-recap.html

======
fendale
All this hype about MagLev, OODBs and Smalltalk that has come out of this
Rails presentation has got me wondering about how some of this stuff works.

As I understand it, coding in Smalltalk involves developing code in an 'image'
that is persisted to disk when you exit (sort of as if it dumps the entire
memory contents to disk in a binary form that can be read back in). What sort
of applications is Smalltalk suitable for? I know Seaside is a web framework,
but a lot of the examples I can find show off more traditional GUI apps.

Does the image approach mean that Smalltalk is not really suitable for quick
and dirty sys admin type scripts that you would use Perl or Ruby for?

I am fairly sure that HN doesn't use a traditional DB - and that if I recall
PG said that Viaweb didn't either. With Viaweb, when a user logged into their
admin console it loaded their environment into a process (and process memory)
and kept it there (I think I read that somewhere).

Does that mean that each user had their own Lisp process fired up and kept
around, and that data was just kept in process memory (and important stuff
persisted to disk somehow)?

What I was thinking then is that if you had a web-app like Basecamp for
instance (ie, an Account with no shared data between accounts), would it be
technically feasible to have a different Smalltalk image for every single
account that is loaded only when that account is being used, with basically
all the account data inside the image? I am thinking memory could be a serious
limiting factor here!

Sorry for the long rambling post - just trying to get my head around this
stuff - hopefully someone on here knows something about it ...

~~~
avibryant
As gnaritas posted below, yes, you could do that, yes, that's what Dabble DB
does, and yes, memory is a serious limiting factor. That's where Gemstone
comes in: unlike the Squeak VM, which we use, the Gemstone VM does not expect
all objects to be in memory at all times, and can lazily load them in as
needed.

~~~
stcredzero
Avi, you guys are seriously going to open up the stuff that's above the VM? I
had been thinking about again picking up my own project to put Ruby on top of
Smalltalk. I'm envious of your approach with working with the VM hackers to
get custom bytecodes. This would be great for getting Ruby to run fast.

What of parallel projects on other Smalltalk VMs? It would be good for the
Ruby community to have options. Gemstone might want to keep some sort of
competitive advantage, however. (Email this userid at yahoo.com. Linkedin is
not letting me send you a message, and so fulfilling their policy of keeping
out riff-raf.)

~~~
avibryant
I think and hope we seriously will, but it's not up to me. Certainly one side
effect would be that, with a little work, you would be able to run Ruby on
other Smalltalk VMs as well, and I think this would be a Good Thing. We'll see
what happens.

~~~
stcredzero
Did you bootstrap a Ruby parser in Ruby into the image? Or did you take
another approach?

------
wallflower
As an undercover Java guy at RailsConf and someone who worked with Gemstone/J,
I am starting to think that Gemstone has finally found the passionate niche
that it's always been looking to find. Rails and Ruby. The only thing Rails
codes dislike more than Java is SQL

~~~
serhei
"The only thing Rails codes dislike more than Java is SQL"

Familiarity breeds contempt, doesn't it?

