From: Joe Van Dyk <joevandyk@...>
Date: 2005-09-17T15:29:26+09:00
Subject: Re: Some interesting criticisms of rails

On 9/16/05, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> 
> I remember reading about the Dining Philosophers problem when I was young and how it was solved with this incredibly complex logic proof that laid out most of the rules for what we know as "thread locking".  For those of you who don't know, the Dining Philosophers is where there's four idiots arguing about communism eating a massive bowl of pasta and they're too stupid to ask for more than two serving forks.  So, these "philosophers" spend a lot of time fighting over the forks and there needs to be a way to coordinate this fork "sharing".  The solution?  Ah, we'll add even more complexity to the problem and create neat things like semaphors.

I remember that from a recent Operating Systems class.  So it's still
in use today.
 
> Of course another way to solve the Dining Philosophers problem is: USE A FUCKING WAITER.  You see, if these idiots don't serve themselves--but instead get their pasta from a "server"--then you don't have anybody arguing over shared forks.  Hmmmm.  "Server".  I wonder why we call systems that act as a single access point to a service "servers"?  Gee.  That just stumps my tired little brain.

I should've brought that up to the professor.  :(


 
> What's that got to do with the world of distributed transaction management?  Well, you only need to have complicated distributed locking primitives when you try to distribute your shared resources to the point that people have to fight over them.  If you just have a "server" that controls access and "share nothing" then the problem is solved in a much simpler way.
> 
> And BTW, if you've ever seen a gang of philisophical communists duel with forks for the last serving of fusili then you'll realize that letting communists share is not nearly as fast as having a waiter serve.
> 
> Zed A. Shaw
> http://www.zedshaw.com/
> 
> 
> On Sat, 17 Sep 2005 04:36:35 +0900
> David Balick <davidbalick@gtakethisoutmail.com> wrote:
> 
> > may be found in the podcast
> > http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
> > 09.html.
> >
> > I am considering using rails (as opposed to asp.net) so am wondering what
> > y'all think of what these guys say.
> >
> > In a nutshell, they say that Rails starts to get less appropriate for apps
> > with transactions that encompass entities other than just the database. If
> > the server side objects also modify the data, and particularly of the
> > modified objects then affect other objects, then it can become very non-
> > trivial to handle all of that in Rails.
> >
> > Any feedback on this from experienced Rails folk would be most appreciated.
> >
> > Cheers,
> > David Balick
> >
> >
> 
>