As I wended my way home last night, I was listening to this “week’s” FLOSS Weekly and just about had to pull my car to the side of the road, due to my sheer astonishment. Leo and Randal had a developer on who was promoting Seaside, a web development framework for Smalltalk (particularly the Squeak implementation). Smalltalk. Perhaps only you other CompSci folks out there will get just how insane a proposition developing for the web in Smalltalk truly is. No RDBMs. Everything’s an object, even, say, the number “5”.
Me, I’m of the opinion that I’d be happier being punched in the face. Repeatedly.
Then I’ll go develop a web framework for Ada. With all the business logic in COBOL. Oh, and I’ll host it on a 386 running Minix.
22 Comments
Add YoursSeems just as arbitrary as Ruby to me.
No RDBMS? You clearly haven’t looked at a Smalltalk implementation in the last 20 years if you believe that. Every Smalltalk system out there can work with pretty much any RDBMS – in Cincom Smalltalk, we are integrating our Object/Relational mapping framework with Seaside to make web/DB development easier.
You might want to actually investigate things before you heckle – why not download Cincom Smalltalk and take a look?
It would seem you have no freaking clue what you’re talking about. Smalltalk is a legitimate language that invented most of the things Ruby and other “modern” languages have since grown to bastardize.
So here’s where you’re wrong, Aron:
A) Ruby doesn’t have a bloated VM backing it, packing in not only the source of every. stinking. class. but also a web browser, telnet and IRC client and full up GUI debugger.
2) Ruby at least allows for look-alike
functionalprocedural programming, allowingCPerl veterans the ability to at least gain a foothold.D) It has a compiled bytecode VM version called “Rubinius“, which should be a special kind of awesome, given your last name. *grin*
Sean:
Smalltalk did indeed invent them. It was then passed by in terms of performance, ease of use and widespread acceptance.
James:
You may be right. My experience with Smalltalk arises primarily from classes in college and the Squeak implementation post-college.
Re: RDBMS. Except for the client libraries to PostgreSQL, MySQL, SQLite and so on. Hell, there’s also a package for doing B-trees and the other bits you’d need to IMPLEMENT a database if you really felt like it.
A) That’s not part the virtual machine in the sense that you mean it’s the class library. In, say, Java terms, the image is like a jar (except that it’s not, the image is exactly like a VMWare image)
2) (2? ) You mean Procedural Programming. Functional Programming is what you get with languages like Lisp and Haskell. Also Perl, but that’s more a side effect of other things. In any case, who cares? Smalltalk and Ruby aren’t procedural languages so treating them as such is a waste of time.
D) Smalltalk has had one of those for nigh on 20 years, maybe longer.
You know, there actually is an Ada web framework and you’d be amazed at the amount of business logic implemented in COBOL.
Byron:
In re: A, 2, D:
See Alone, Home for the joke.
A) Image file, right. I stand corrected. I was mainly referring to DabbleDB’s use of Smalltalk in their web development efforts. As the guest on FLOSS Weekly described it, they’re not using a back-end database, but rather each customer has their own Smalltalk image that contains all the data, etc.
2) Procedural. Right. I’ll correct that.
D) ‘Twas a joke riffing on Aron’s last name.
Full disclosure: Aron and I know each other from way back and his disdain (and mine) for Ruby is a known joke between us.
In regards to Ada and COBOL: just ’cause they’ve been there for years doesn’t mean that they shouldn’t be replaced, nor are they necessarily things I would like using.
In fact, I’d rather stick shrimp forks into each of my eyeballs before undertaking any large scale web development task using Ada, COBOL, BASIC, Smalltalk, Pascal, x86 assembly code, etc.
On the “web development in assembly language” subject, I’d like to point out that I had the same reaction (but callously neglected to post) when I heard Steve Gibson claim on Security Now that he does all development for his GRC website stuff using assembly. Windows assembly. To be compiled as .dlls for running on IIS.
Now, that may sound fun to a certain segment of the population. Me, I value my free time more than that.
As I said in comments over on my blog, you might want to look at Seaside, and then reevaluate your notions of velocity. As to performance – if you think Ruby or Python or Perl have surpassed Smalltalk in performance terms, you couldn’t be more wrong – feel free to try some benchmarking.
As to the size of the image, I’ll say this: Why do you care? Seriously – on a server with multiple gigabytes of memory, worrying about the difference between a 5MB runtime and a 10 MB runtime are fairly absurd – it’s no longer 1995.
On databases – running without one is not as nuts as you seem to think. The Cincom Smalltalk website – all the blogs and the main site itself – are Smalltalk powered, with no database usage. It’s very reliable, and I can modify the running system without taking it offline – including live changes to the shape of objects that are in memory.
Your notions of what Smalltalk can and can’t do are at least a decade out of date, possibly more.
James:
I think we’re talking about different notions of “performance” here. You’re talking about speed of development for an experienced Smalltalk developer. I’m talking about speed of use for experienced [other language] developers, with preexisting vendor-supplied packages, etc., ready for deployment.
And, while it may make sense to talk about doubling runtime sizes being “absurd” if you own your own gear, if you’re a small-to-middlin’ hobbyist or OSS developer who happens to host on a shared account (*cough*), then that’s no mean jump to commit to.
I’d also like to see the looks on the DreamHost support techs when I ask about supporting Smalltalk on their gear. (They still won’t do mod_python with any great frequency…! Makes running Trac a real bear.)
Doug,
You must have missed Amazon’s last couple of years. You can start up your own web app using EC2, S3, and now SimpleDB at the cost of owning a laptop and a broadband connection. You don’t need to get anyone’s permission to host a Smalltalk image; you just put it there.
It’s not as if they are the only service with that level of access, either – you can rent root server access from various outfits at a cost of well under $100/month – and Amazon’s services are going to drive those costs down, not up.
It’s never been a good time to discount the cost of developer productivity. Those support techs won’t be laughing for long; mostly, they are going to end up out of work.
Ah, see, you’ve missed the lightbulb moment. The whole point of the DabbleDB model is that the Smalltalk image lets you do things that would be incredibly difficult under a non-image-based model (Smalltalk as a language rather than as an environment is actually rather unimportant. BTW, you realize that ‘5’ is also a first-class Object in Ruby, right? A Fixnum in fact).
The key “ah ha” moment for me was actually the fact that since the data doesn’t live in a back end it is now much more difficult to have data leakage from one users’ environment to the other. Simply put, Alice cannot access Bob’s data because it lives in a completely different image running in a VM that Alice’s image knows nothing about. Alice’s account isn’t even available to Bob’s image, as far as it’s concerned Alice doesn’t exist. When the data are things like credit card numbers or HIPPAA protected data you start to realize “oh hey, that’s not such a bad idea.” So, something just went from “Major Engineering Effort” (see Amazon’s S3) to “Handy Side Effect.”
For the data side, as I say, if they really felt the need to implement a SQL RDBMS in Smalltalk it wouldn’t be that hard to do entirely in the image. It would essentially work like SQLite since you don’t need to handle multiple simultaneous connections, which are the sticky bits of an RDBMS project. SQLite is pretty small and you wouldn’t need a lot of the data structure bits since they already exist in Smalltalk. In general, they probably just use standard data structures to model them more-or-less naturally. Since they persist, it’s just as good as a database with the exception of transaction processing (largely eliminated by their interaction model).
James:
*shrug*
As I said, this is a hobby for me. I sysadmin by day, code and putter by night. $100/month is far from practical, particularly when I’m trying my best to get a Wii habit going (oh yeah, with a wife and two kids to factor in too… *grin*). It simply isn’t worth the hair-pullage to get re-acquainted with a language whose syntax varies widely from the stuff I use on a day-to-day basis and whose installation requirements aren’t really and easy feat on my cheap-y web hosting.
Byron:
I understand the very nice data separation advantages, plus the “don’t flippin’ care what the form fields are called, since they get automatically taken care of by Seaside”. I also realize that Ruby draws heavily upon Smalltalk for inspiration — I didn’t bring it into the conversation, Aron did. I frankly have avoided Ruby as much as possible, as it simply doesn’t seem to work in a way similar to the way I think.
A lot of this comes down to software religion, I guess. Y’all can rail at me to convert to bowing to your Zoroaster or 5 Point
CalvinismStallmanism, while I maintain a comfortable Methodist (hah! pun!) state of being. What works for me works for me and you can have your PARC and eat it too, as far as that goes.I still would like to see some concrete numbers in re: Perl/PHP/J2EE/Python/RoR/etc. vs. Seaside on a production server under load. How does it handle a digging? An Instalanche? Or, Heaven forefend, a Slashdotting? I just can’t believe that a language with the overhead of Smalltalk could play in the same ballpark as those mentioned above (well, maybe RoR…).
One final thought, James:
With Smalltalk’s history and breadth of development, etc., what makes you think that “those in the know” will pay any more attention to it now than in the previous 25 years? What in particular makes Smalltalk viable as a web development platform now, as opposed to ’96, when the Web was just starting to hop? Is it simply the “Moore’s Law Benefits Java” principle at play, or do you see it as something more fundamental? Is Seaside really the bee’s knees?
Since I enflamed this post I feel I need to weigh in. I would like to point out that there are some languages that are really cool notionally and as research subjects. Often they are bright and shiny and they draw many in to enjoy as playful diversion. Then there are some languages which you can count on. They may not be incredibly convenient for every use and they may require some discipline from the programmer. There are two factors that differentiate the former type most – non-determinism and syntactic sugar. I think Doug was trying to note that Smalltalk, Pascal, Lisp, etc. had/have value especially in their influence on other languages, libraries, and frameworks but in your production system you need something a little more proven. I can sense this becoming an essay so I am going to end it. Perhaps I will post more to my own blog later.
Why not try the Seaside one click installer and go through some of the tutorials. Seaside is pretty cool and insanely easy to get running. Deployment isn’t too hard (though admittedly not available out of the box on major Linux server distros as you note).
Scaling is similar to Java and Ruby (done all three). If you have stateful transactions (bunch of server state across multiple pages) you need a sticky load balancer. If you don’t and you are stateless, you don’t. Doesn’t matter which language and environment you use.
Seaside is full of server side state. So you better have a sticky load balancer and a bunch of servers for scale. But, if you’ve got a slashdot size audience, put your static content on S3 to take the slashhorde and keep your transactions for your customers. If you have 10,000 of customers, you can afford the hardware.
Avi is the only seasider that I know who uses literally thousands of customer images. Most seaside apps are probably single image or a handful of images talking to a relational database with GLORP.
If you’re just getting started, still use S3 for static content (they’ll charge you 2 cents a month) and get a small virtual host for you customers.
If you’re just fronting for a simple relational store, keep on trucking with PHP. Nothing wrong with that. If you’re building something like DabbleDB (check it out), you might want something different.
Smalltalk probably won’t be the next big thing. It is still fun and different. I’ve done Smalltalk, Ruby, and Java professionally and Smalltalk is by far my favorite.
Re benchmarks. I’m kind of a disinterested observer in this discusion. I’m not a smalltalk programmer but I was using Ruby 7 or 8 years ago, long before it became in any way popular. Most of my time is spent in Java and Python. I’d suggest you have a look at this site:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
The guy that runs that site is a frequent commentator on James Robertson’s blog (and is also a fairly vocal critic of Smalltalk, although to be fair, I’d guess he’s critical of almost all languages). As, you’ll see, certainly given the default weightings, Smalltalk outperforms PHP, Perl and Ruby quite considerably. Now, given all the dynamic development features using something like Seaside provides, it seems to me that there _just might_ be some credibility behind what James is saying 🙂
Avi was inspired by WebObjects in creating Seaside. And in case you don’t know, WebObjects is the standard to beat (in terms of both tooling and framework design) when it comes to web application development. Instead, the Java world went off half-cocked in following Sun’s woefully misguided J2EE designs. And 10 years after it was released, WebObjects is still out in front when it comes to Java web application development, even if most people have never heard of WebObjects (it is, after all, Apple’s best-kept secret).
Avi tried to build on and out-do WebObjects, and in some ways I think he has succeeded (e.g. the through-the-web debugging of an application, where the browser actually becomes the debugger of a running session inside Seaside — see http://wilkes.blogspot.com/2006/01/debugging-in-seaside.html).
In fact Doug, rather than just toss this about with James et al., why don’t you go and have a look what Avi and Co. have achieved with Seaside in producing DabbleDB (http://www.dabbledb.com/explore/7minutedemo/) . That 7 minute video shows someone _building_ a dynamic web application using just a CSV file and Dabble.
I can’t imagine another company/techncology that could build DabbleDB. Gmail (and any other Ajaxy webmail client) is very much underwhelming when compared to DabbleDB.
It strikes me that most people have failed to grasp just how amazing DabbleDB is. Avi has taken many ideas from Lotus’ (revolutionary but failed product) Agenda. When Agenda was available back in the DOS days, people failed to grasp what Agenda was, and how amazing it was. I think the same fate may befall DabbleDB. But that in no way diminishes the brilliance of DabbleDB, Seaside and Avi Bryant.
Bernard:
That’s a pretty interesting site. It seems (from my quick reading) that Smalltalk gets the better of most of those languages in CPU time, but gets handily spanked in terms of memory used. I expected the second result and was a bit surprised by the first, honestly, at least by the scale of the difference.
It looks as though those are for common operations, though, and not specifically tuned to a web environment. Be interesting to see a web test suite run against all those.
Doug,
I’m not really interested in converting you to or from anything. Why would I? I don’t work for a Smalltalk vendor so it comes down to a competitive advantage for me. As for overhead and performance, if you don’t have hard numbers how are you making your claims about overhead and performance? Oh, right. Religion. In any case, the memory footprint is something a little bit better than a Java solution as is processing performance depending on the Smalltalk implementation you happen to be using (somewhat better for the well-optimized Smalltalk VMs. Go read about the birth of the Hotspot Java JITer if you want more data). Processing performance doesn’t really matter since pretty much all web-apps are I/O bound so you find that the bottleneck is actually back on the database machines, hence the rise of things like memcache. Your web-servers tend to be pretty idle unless they’re serving a ton of little hits . You’d scale it in the usual sort of way. Avi Bryant probably has some truly hard numbers given that he actually has been dugg and whatnot.
Doug wrote
> It seems (from my quick reading) that Smalltalk gets the better of most of those languages in CPU time, but gets handily spanked in terms of memory used.
No it’s just that the measurements are being made against ordinary developement images that include the IDE and other development tools 🙂
Look at a test that actually uses memory:
http://shootout.alioth.debian.org/gp4/fulldata.php?test=binarytrees&p1=vw-0&p2=ruby-2&p3=vw-0&p4=ruby-2#memchart
Hahahahahahahahahahahahahahahahaahhahaah
hahahahahahhahahahahahahahahahahahahahah
oh my gods. how uninformed.
Special K:
Whom, exactly, are you referring to?
‘Cause I still ain’t convinced on the Smalltalk web dev front.