Joel Spolsky on languages for web programming

[Chad Perrin]

[Ruby is slow] so if you become The Next MySpace,
you'll be buying 5 times as many boxes as the .NET guy
down the hall.

I can't believe I missed another rebuttal here.

If you become the next MySpace, you are done! Just getting to that Critical
Mass point is 98% of the battle. Once you are there, you have many more
options than when you started.

So, once again, Joel is also taking a slam at Lean Software Development
here...

I'm also amused that Joel didn't realize MySpace got where it did by
utterly failing to take the approach Joel advises.

 

[Jeremy Tregunna]

[Ruby is slow] so if you become The Next MySpace,
you'll be buying 5 times as many boxes as the .NET guy
down the hall.

I can't believe I missed another rebuttal here.

If you become the next MySpace, you are done! Just getting to that
Critical
Mass point is 98% of the battle. Once you are there, you have many
more
options than when you started.

So, once again, Joel is also taking a slam at Lean Software
Development
here...

I'm also amused that Joel didn't realize MySpace got where it did by
utterly failing to take the approach Joel advises.

Perhaps it's just me who sees this, but to me Joel seems like a troll
-- and not a very good one either.

 

[M. Edward (Ed) Borasky]

If you're going to debate the scale of productivity increase for web
development gained with Rails, perhaps you should also debate these
mythic software performance gains for .NET over Rails.

I haven't seen any benchmarks one way or the other. So I can't comment
with any assurance. Nobody is paying me to improve the performance of
either .NET or Ruby, but since Ruby is an open-source project, it's only
natural that I'd choose to volunteer in that direction. But I'm a lot
more interested in hard numerical apps than web apps at the moment.

I, frankly, am
not convinced .NET grants any notable performance benefit over Rails on
average, at all.

Neither am I, as I noted above. But Joel Spolsky is, so I think it's at
least worth investigating how he came to his conclusions and tearing
said arguments apart. I think what he is saying is that *today's* Ruby
interpreters are slower that *today's* .NET run-times, and not anything
about Rails vs. NET for web apps. Yes, the line about buying five
machines vs. one is a cheap shot.

Speaking of which, does anyone know what the underlying platform is for
MySpace? Windows? .NET? LAMP? Something else?

I'm more convinced of productivity gains for Rails
programmers over .NET programmers, however.

With equal levels of experience? Equal levels of application domain
knowledge? The same processes? All factors equal except .NET vs. Rails?
That's a competition I'd like to see, if there's some way to set it up.
It's very rare, however, that all other factors *are* equal.

Most of the claims of improved productivity for Rails -- the ones I
believe, anyhow -- are made by people with many years of experience in
web development under their belt and much of that experience with a
mature Java framework. In short, all they have to learn is where to find
everything in Rails and the details of the Rails domain-specific
language. They already know how to build a shopping cart and just need
to learn how to do it in Rails.

 

[M. Edward (Ed) Borasky]

No, I want to provide Joel a Cluebat, with glowing letters on it spelling:
"Premature Optimization is the root of all evil".

In a web app, the bottleneck is the database, so - guess what?! - it's
written in C. Anything else is just tuning.

I will trade CPU cycles for programmer cycles any day.

Well:

1. I don't consider a 4X speed improvement on a matrix multiply and
inverse, which is what I got with YARV over Ruby 1.8.5, "premature
optimization".

2. If the bottleneck is the database, why does Rails frown on stored
procedures, preferring instead to do everything in the ActiveRecord ORM?

 

[Chad Perrin]

I haven't seen any benchmarks one way or the other. So I can't comment
with any assurance. Nobody is paying me to improve the performance of
either .NET or Ruby, but since Ruby is an open-source project, it's only
natural that I'd choose to volunteer in that direction. But I'm a lot
more interested in hard numerical apps than web apps at the moment.

Joel indicated that you could get the same scalability/performance out
of one fifth the boxen by using .NET instead of Rails. That's where
this tangent of the discussion originated.

Neither am I, as I noted above. But Joel Spolsky is, so I think it's at
least worth investigating how he came to his conclusions and tearing
said arguments apart. I think what he is saying is that *today's* Ruby
interpreters are slower that *today's* .NET run-times, and not anything
about Rails vs. NET for web apps. Yes, the line about buying five
machines vs. one is a cheap shot.

Speaking of which, does anyone know what the underlying platform is for
MySpace? Windows? .NET? LAMP? Something else?

Until recently, MySpace was running on ColdFusion 5. It is, last time I
checked, undergoing migration to BlueDragon.NET (CFML on .NET).

With equal levels of experience? Equal levels of application domain
knowledge? The same processes? All factors equal except .NET vs. Rails?
That's a competition I'd like to see, if there's some way to set it up.
It's very rare, however, that all other factors *are* equal.

Most of the claims of improved productivity for Rails -- the ones I
believe, anyhow -- are made by people with many years of experience in
web development under their belt and much of that experience with a
mature Java framework. In short, all they have to learn is where to find
everything in Rails and the details of the Rails domain-specific
language. They already know how to build a shopping cart and just need
to learn how to do it in Rails.

That sounds like less-than-equal levels of experience with Rails. Let's
just unceremoniously dump equal numbers of long-time web developers into
Rails and ASP.NET environments, but without prior experience with
either, and see what happens. That's probably more fair than
experienced ASP.NET developers vs. experienced Rails developers, since
from what I've seen most of the .NET developers who know their fourth
points of contact from holes in the ground are desktop application
guys, not web developers. I wouldn't want to give the Rails guys an
unfair advantage.

 

[khaines]

[Ruby is slow] so if you become The Next MySpace,
you'll be buying 5 times as many boxes as the .NET guy
down the hall.

Last time I checked, 5 new boxes were cheaper than 5 new programmers...

Slow and fast are notoriously difficult to pin down, especially when
dealing with dynamically generated web content. If there is much in the
way of database queries or similar activity involved in generating the
page, that can quickly become the bottleneck. If the application is such
that the db data can be cached in some way, even if the dynamic generation
is still taking place, speeds can be fairly fast.

My in-development IOWA branch is, in testing, pumping some real (as in,
destined for a production web site) dynamic web pages in the 2.5k to 4k
bytes size range in excess of 200/second on a modest 2ghz AMD Athlon
server.

If I take that same dynamically generated content and let the framework
cache it (and serve the cached content itself) in tests I am pushing 3800
to 3900 requests per second for a 2.6k page THROUGH RUBY CODE, and about
1000 requests per second for a 38k page.

"Ruby is slow." is easy to say, but in practice, where web apps are
concerned, ruby can be fast enough.


Kirk Haines

 

[Phlip]

1. I don't consider a 4X speed improvement on a matrix multiply and
inverse, which is what I got with YARV over Ruby 1.8.5, "premature
optimization".

Nobody has stated Ruby is fast. Your argument, however, is: "my algorithm is
bigger than your algorithm".

Trivially put your matrices into a C++ library, bond it to Ruby, and keep
going.

Programming is mostly about command-and-control code, glueing ready-made
libraries together. The faster and easier the glueing is, the more time you
have open to optimize the few things that need it.

2. If the bottleneck is the database, why does Rails frown on stored
procedures, preferring instead to do everything in the ActiveRecord ORM?

If they are fast, leave them there.

 

[Phlip]

Perhaps it's just me who sees this, but to me Joel seems like a troll --
and not a very good one either.

The word you reach for is probably "successful blogger" there.

;-)

 

[Rick DeNatale]

Joel indicated that you could get the same scalability/performance out
of one fifth the boxen by using .NET instead of Rails.

s/indicated/claimed/

 

[Chad Perrin]

s/indicated/claimed/

I was trying to be nice.

 

[Chad Perrin]

[Ruby is slow] so if you become The Next MySpace,
you'll be buying 5 times as many boxes as the .NET guy
down the hall.

Last time I checked, 5 new boxes were cheaper than 5 new programmers...

If you become the next MySpace, that "5 times as many boxes" would not
be 5 boxes vs. 1 box. It would be more like 100 boxes vs. 20 boxes, or
worse.

. . and how many hours' worth of developer work per week?

If your answer is "not much more", I'd have to say "So that's why
MySpace is so unreliable and buggy -- aside from the broken-ass platform
they use."

 

[kate rhodes]

I'm sorry, but i just need to step into this and point out what should
have been obvious ages ago....

You can't compare .net and Rails. It's like comparing the JVM or
Parrot and Rails. It makes no sense.

NET and the JVM and Parrot are just virtual machines that by themself
contribute absolutely nothing to the productivity of a web developer.

Or for a non-programmer analogy it's like saying that the
contstruction company makes the architect more productive. I'm sorry
but it doesn't. Yes they come into contact but the architect /
developers productivity issues are no longer an issue when the
construction company / virtual machine comes in to do it's work.

And while we're on the topic, can you (all of you) please explain to
the managers at your company that .net isn't a language and *nothing*
is "written in .net"


- kate = masukomi

 

[David Vallner]

.NET and the JVM and Parrot are just virtual machines that by themself
contribute absolutely nothing to the productivity of a web developer.

NET is the whole platform, the CLR is the VM.

David Vallner

 

[Chad Perrin]

.NET is the whole platform, the CLR is the VM.

You beat me to it -- just as Rails implies the Ruby interpreter, so .NET
implies the CLR.

 

[Austin Ziegler]

1. I don't consider a 4X speed improvement on a matrix multiply and
inverse, which is what I got with YARV over Ruby 1.8.5, "premature
optimization".

2. If the bottleneck is the database, why does Rails frown on stored
procedures, preferring instead to do everything in the ActiveRecord ORM?

It's an Opinion. A potentially valid one, but just an Opinion.

Frankly, DHH has made a number of mistakes in his Opinions on what a
database should do. Some of these are worse than others -- encoding
MySQL semantics into AR behaviour (when MySQL is *not* doing the right
thing by any measure) is a good one. But there's nothing *inherently*
wrong with stored procedures or triggers. There's good reasons for
having them and using them; there's good reasons for not using them
even if they are available (they weren't available for MySQL for a
long time, IIRC).

Certain things -- like audit logging -- I *only* want done with
database triggers.

-austin

 

[Rob Sanheim]

It's an Opinion. A potentially valid one, but just an Opinion.

Frankly, DHH has made a number of mistakes in his Opinions on what a
database should do. Some of these are worse than others -- encoding
MySQL semantics into AR behaviour (when MySQL is *not* doing the right
thing by any measure) is a good one. [snip]

Hi Austin

Could you elaborate on this? I'm curious as to what you mean by
"mysql semantics into AR behaviour". Do you mean the preference to
treat a database as a glorified hash, and not enforcing any
constraints at the db level?

thanks,
Rob

 

[Austin Ziegler]

It's an Opinion. A potentially valid one, but just an Opinion.
Frankly, DHH has made a number of mistakes in his Opinions on what a
database should do. Some of these are worse than others -- encoding
MySQL semantics into AR behaviour (when MySQL is *not* doing the right
thing by any measure) is a good one.

[snip]
Could you elaborate on this? I'm curious as to what you mean by
"mysql semantics into AR behaviour". Do you mean the preference to
treat a database as a glorified hash, and not enforcing any
constraints at the db level?

That's one. An aversion to foreign keys (which, contrary to DHH's
assertion, *can* encode the relationships captured by most of the
belongs_to_* sort of helpers in AR) is another. The one that's always
annoyed me most is the fact that MySQL behaves incorrectly with
respect to table and column-name case-sensitivity.

That is, these two are supposed to be identical:

SELECT ID FROM PRODUCT;
SELECT id FROM product;
SELECT Id FROM Product;

You're only supposed to be case sensitive if you enclose your named
object in double quotes:

SELECT "Id" FROM "Product";

Oracle, for example, when you query the data dictionary, returns
columns in all caps. This means that the folks who wrote the Oracle
adapter for AR have to go to the extra effort of downcasing everything
... unless it's mixed caps. This is one point where (IMO) the SQL
standard made big mistakes (allowing any case-sensitive object names
at all, no matter the reason), but AR encodes MySQL behaviour as if it
were correct.

(Worse, MySQL behaviour is not consistent on this matter; on Windows,
MySQL itself is case-insensitive but AR is still case-sensitive. MySQL
is one of the worst damned implementations of SQL ever. Still.)

-austin

 

[Keith Gaughan]

That's one. An aversion to foreign keys (which, contrary to DHH's
assertion, *can* encode the relationships captured by most of the
(Worse, MySQL behaviour is not consistent on this matter; on Windows,
MySQL itself is case-insensitive but AR is still case-sensitive. MySQL
is one of the worst damned implementations of SQL ever. Still.)

That's with respect to table names rather than column names, and really only
effects MyISAM tables. InnoDB tables don't have that problem, if I remember
correctly. BDB and others I'm not so sure about because I haven't had need to
use them myself.

 

[Austin Ziegler]

That's with respect to table names rather than column names, and really only
effects MyISAM tables. InnoDB tables don't have that problem, if I remember
correctly. BDB and others I'm not so sure about because I haven't had need to
use them myself.

IME, it is something with MyISAM (which is still the most common
configuration because it offers pure speed) and it *does* affect
column names as well even though it shouldn't for the stupid reasons
that tables are affected.

MySQL is a big sticking pile that should be left in the scrapheap.

-austin

 

[Rich Morin]

MySQL is a big sticking pile that should be left in the scrapheap.

No, really, tell us how you REALLY feel about it. -).


FWIW, a friend of mine is a seasoned DB programmer who migrated
from Oracle to PostgreSQL a few years ago. He says similar things
about MySQL. Worse, however, he says that RoR is destined to be
saddled with MySQL workarounds far into the future. Consequently,
he dismisses Rails as a whole, which is a shame.

Given that RoR is extremely modular, I see no real reason why this
must be the case. If some folks that are sharp in both PostgreSQL
and Ruby (note: I am not one were willing to make the effort,
AR could be enhanced (or replaced, if need be) to provide clean DB
semantics.

Until that time, the AR/MySQL hegemony will continue to dominate
RoR practice. As they say, an ounce of implementation trumps a
pound of rhetoric...

-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume (e-mail address removed)
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development