« Django 0.95 | Main | link_to '(delete)' {:action => 'delete', :id => recipe.id} »

That nobody else could do

Obie: "I really don't think Seaside poses serious competition to any of the major web frameworks. Too much voodoo.."

Obie is probabaly right, but Voodoo is all relative, isn't it? That's more or less what a Struts person might say looking at Rails - "too much voodoo". There might well be a lot of voodoo in Seaside, but show me another framework that can support what dabbledb does. I think Zope/CMF could do it, but not Rails, not until the RDBMS dependency is thrown out and a generic model/dsl for content is supplied in its place. If that's voodoo, so be it.

I think the difference between Seaside and say Rails (or Django), is that Rails provides what Obie once called "Productivity Arbitrage" - the ability to do something you're already doing, at a drastically lower cost or improved rate thereby changing market dynamics - typically by introducing a new efficiency that reduces the overall value of the market but increases your absolute income from that or a related market. Whereas Seaside makes new markets possible. Rails is like a Jacquard loom, Seaside is like a horseless carriage. You need both types of innovation.


July 30, 2006 08:05 PM

Comments

Eric
(July 31, 2006 02:32 AM #)

"not until the RDBMS dependency is thrown out"

I'm curious... why does the RDBMS dependency have to be thrown out? Could you please elaborate on this?

(July 31, 2006 03:55 AM #)

What can dabbledb do that no other language that emits strings (html/css/ajax) to be sent over the wire to a browser not do?

Reg Braithwaite
(July 31, 2006 10:47 AM #)

What can dabbledb do that no other language that emits strings (html/css/ajax) to be sent over the wire to a browser not do?

Ahhh, the "Turing Complete" argument. What can dabbledb do that assembly language not do? In theory, nothing. But in practice, quite a bit. (By the way, are you asking about dabbledb or about Seaside, the framework used to write dabbledb?)

Try asking this question:

What does Seaside make it easy to do that no other language that emits strings (html/css/ajax) to be sent over the wire to a browser not do?

Bill Seitz
(July 31, 2006 02:59 PM #)

The problem is that most frameworks are not Turing-complete. And are more likely to have bugs than languages. (Or perhaps it's that the languages tend to have already been around a bit longer, so the bugs have been worked out.)

So when something unexpected happens, figuring out what's going on is harder when there's a wall of Voodoo involved.

(Speaking as someone moving from Zope to PythonPaste.)

Bill Seitz
(July 31, 2006 03:21 PM #)

re: Eric's question about RDBMS mentality - If you're running a loose framework that lets users (or some subset of users) create custom data types, or a long list of custom attributes extending existing data-types, then using an RDBMS as the back-end can be highly annoying.

(On the other hand, when I was researching TripleStores a while back, I found that a number of them were built on top of SQL engines. Though perhaps that practice is changing...)

http://webseitz.fluxent.com/wiki/DataStore
http://webseitz.fluxent.com/wiki/TransparentObjectPersistence
http://webseitz.fluxent.com/wiki/TripleStore

(July 31, 2006 06:01 PM #)

One thing about Seaside Voodo -- it's all Smalltalk, so it's all visible.

Bill de hOra
(August 1, 2006 01:44 PM #)


"So when something unexpected happens, figuring out what's going on is harder when there's a wall of Voodoo involved."

I agree with this. But good luck trying to automatically evolve a DB schema in response to user changes to what the data types are. That's more or less what dbable db does.


"On the other hand, when I was researching TripleStores a while back, I found that a number of them were built on top of SQL engines."

True. They use rdbmses as indexing/storage mechanism.

assaf
(August 1, 2006 11:11 PM #)

Or should it be, "any framework that's sufficiently DRY is indistinguishable from Voodoo"?

Unfortunately, Voodoo works both ways. So the make it or break it decision for me has always been: how easy would it be to fix things when the Voodoo turns against me? Because it always does.

I'm probably missing something fundamental, but the flexi-schema fails to impress. Or maybe I just figured out which pins to push. With Rails, changing the database at run-time and reloading the model is one line of code, it's just not prominently documented or discussed.

Much to the credit of its Smalltalk origins that make it possible.

And building a content database adapter is a few day's work. Same credit.

But Seaside has continuations which keep me intrigued, now sure you can do that with Rails.

(* And by do, I mean here and how without hiring a ten person team and budgeting 12 months R&D to get a prototype. *)

I think your point about markets is absolutely dead on, but for a different reason.

Rails is spreading mainstream (one person's mainstream is another person's niche) and wider it goes, the more of the same we're going to see. More of the same structured data, normalized tables user interface.

Seaside is still edgey and attracts a very small crowd that's thinking outside the box. So you're going to see less stuff, but higher creative to me-too ratio.

It's not the frameworks and never was, but the people they attract. Which is why I'm keeping eyes open on Seaside and what comes out of that.

And yes, DabbleDB is seriously impressive! It's one of the better examples of "let's make something better".

phil jones
(August 28, 2006 03:02 PM #)

Hmm. I'd like to understand what you meant about something Seaside can do that that Rails can't in the case of dabbledb.

It seems like the main question is : can users create new types and data structures? Which is fairly trivial with an object store, but a bit messy with an RDBMS because, unless you let the users directly mess around with the database schema (dangerous), you have to do all the complex mapping between their desired new types and the database.

However, I thought Seaside's "voodoo" was all about continuations which were a way of abstracting away from explicit sessions and management of the flow of control over http.

These seem two different issues. You could, presumably allow users to define their own types with any sort of object database, even using something like PHP. It's probably easier to build dabbledb in Seaside than PHP, but not clear that this is any less "productivity arbitrage".

Bill de hOra
(August 28, 2006 06:04 PM #)

"Hmm. I'd like to understand what you meant about something Seaside can do that that Rails can't in the case of dabbledb."

What is this "Hmm"? Explain yourself!

You can argue it's not rails, its the RDBMS that's limiting (true). But rails is architected on an RDBMS, so it doesn't matter much.

"However, I thought Seaside's "voodoo" was all about continuations..."

There's that, but to be honest the details of how Seaside manages state is much less interesting than how it can manipulate content.

"These seem two different issues. You could, presumably allow users to define their own types with any sort of object database, even using something like PHP. It's probably easier to build dabbledb in Seaside than PHP, but not clear that this is any less "productivity arbitrage"."

They are two different issues, but you introduced continuations, so I'm not sure where you're going. The Dabbledb sauce is in the object storage. It's clear to me the critical technology that makes Dabbledb a hit is Smalltalk and how it runs in an image. Saying you could do this on PHP is not untrue. It would not be untrue for Rails either, but really Rails is for optimising working on web apps built on relational databases. I think by the time you were done making it run on an ODB, you have have something built in Ruby, that wasn't anything like Rails. It'd probably be called "Rope".