Joel Spolsky on languages for web programming

[Dido Sevilla]

http://www.joelonsoftware.com/items/2006/09/01.html

Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well. We're
taking a wait and see attitude before we attempt to use Rails for any
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Joel Spolsky on languages for web programming"

|http://www.joelonsoftware.com/items/2006/09/01.html

I am very proud he mentioned Ruby in one of his essays. Actually, I
agree with his conclusion:

that's not a safe choice for at least another year or six. that's not
a safe choice for at least another year or six.

He is a businessman, not a geek, so he does not have to risk himself
using Ruby (and Rails). It doesn't matter. He will not pay me
anything even if he choose Ruby.

But we disagree in the middle.

(1) it displays a stunning antipathy towards Unicode and
(2) it's known to be slow, so if you become The Next MySpace, you'll
be buying 5 times as many boxes as the .NET guy down the hall.

(1) Although we took different path to handle m17n issue from other
Unicode centric languages, we don't have any "stunning antipathy".
(2) Although Ruby runs slower than other languages in those
micro-benchmarks, real bottleneck in the most application lies in
either network connection or databases. So we don't have to buy 5
times as many boxes.

matz.

 

[Richard Conroy]

http://www.joelonsoftware.com/items/2006/09/01.html

Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this.

He is a good writer, and I really like how he cuts through the
rhetoric and is firmly grounded on practical programming matters.

His core point on technology choice is valid:
"How do you decide between C#, Java, PHP, and Python? The only real
difference is which one you know better. If you have a serious Java
guru on your team who has build several large systems successfully
with Java, you're going to be a hell of a lot more successful with
Java than with C#, not because Java is a better language (it's not,
but the differences are too minor to matter) but because he knows it
better. Etc."

His point is valid too if you have a big Rails guru on your team, someone who
has built large successful Rails systems, then you pick a Rails solution.

The performance/scalability of Rails as an enterprise web-fronted system is
continually questioned. People point to Basecamp etc. as examples that Rails can
do it.

But thats missing the point - those systems are successful becuase those
companies have very good, experienced Rails engineers. Rails n00bs would
probably make a lot of mistakes that clash with the framework and
compromise its scalability.

He also has a point about his wait-and-see attitude wrt Rails. Rails development
is moving quickly, and in a year's time the major issues like unicode support,
deployment, support ecosystem (tools, etc.) and performance could be
solved problems.

 

[Derek Chesterfield]

Actually, I agree with his conclusion:


He is a businessman, not a geek, so he does not have to risk himself
using Ruby (and Rails). It doesn't matter. He will not pay me
anything even if he choose Ruby.

In the context of the enterprise, I agree too. But only in the sense
that 'safe' implies availability of skills, and perhaps tools to some
extent. IMO, Ruby and Rails are 'safe' in the sense that they have
longevity, which I think would be the next biggest concern of
enterprise users.

 

[Rimantas Liubertas]

In the context of the enterprise, I agree too. But only in the sense

that 'safe' implies availability of skills, and perhaps tools to some
extent. IMO, Ruby and Rails are 'safe' in the sense that they have
longevity, which I think would be the next biggest concern of
enterprise users.

There is another take on what's risky and what's safe:
http://www.infoq.com/articles/From-Java-to-Ruby--Risk


Regards,
Rimantas

 

[Rob Sanheim]

http://www.joelonsoftware.com/items/2006/09/01.html

Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well. We're
taking a wait and see attitude before we attempt to use Rails for any
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...

I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":

"Wasabi, a very advanced, functional-programming dialect of Basic with
closures and lambdas and Rails-like active records that can be
compiled down to VBScript, JavaScript, PHP4 or PHP5."

So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??

Also, I could see how looking at unicode in Rails could scare large
enterprise apps, but the scaling and slowness thing is just FUD.

- Rob

 

[James Edward Gray II]

I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":

I too found that beyond ironic.

James Edward Gray II

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Joel Spolsky on languages for web programming"

|On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
|
|> I find it amusing that he says Rails is too risky and new, yadda
|> yadda, but then he goes on to talk about their in-house language,
|> "Wasabi":
|
|I too found that beyond ironic.

That indicates that he trusts himself, and not me (Ruby). And I think
he's right.

matz.

 

[khaines]

and rewarding. I doubt I could do the same with a Rails app. So for

now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...

An interesting performance test is to take some task and implement it in
Rails or Nitro or IOWA or Camping or whatever, and then implement it in a
PHP framework with equivalent functionality.

I have done some of this using CakePHP, which is a reasonably good PHP web
development framework, and the results are interesting. While PHP will
benchmark faster than Ruby for isolated benchmark tasks, when one starts
looking at frameworks with equivalent capabilities, PHP loses that
performance advantage, at least in the limited testing that I have done so
far.


Kirk Haines

 

[William Grosso]

Well, to be fair, it's not quite that.

Start with http://www.joelonsoftware.com/articles/FogBugzIII.html --
they had a VBScript app and it needed to be on PHP. So they wrote
a VBScript to PHP compiler.

Good choice, given the market pressures.

Three years later, they've extended that compiler a little in the
direction of a FogBUGZ specific DSL and given it a silly name.

Not particularly surprising, nor particularly relevant to language
debates.


Bill

 

[James Edward Gray II]

Hi,

In message "Re: Joel Spolsky on languages for web programming"
on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II

|On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
|
|> I find it amusing that he says Rails is too risky and new, yadda
|> yadda, but then he goes on to talk about their in-house language,
|> "Wasabi":
|
|I too found that beyond ironic.

That indicates that he trusts himself, and not me (Ruby). And I think
he's right.

Really? I trust you a lot more than me, at least as far as designing
languages goes.

James Edward Gray II

P.S. I've used Spolsky's software and read his books and it just so
happens that I trust you more than him too.

 

[Rob Sanheim]

I too found that beyond ironic.

James Edward Gray II

On second though, maybe Joel was just trolling a bit here? Maybe just
a bit of an in-joke, knowing that the bloggers would go nuts about the
obvious contradiction?

It seems to nutty to be true...
- rob

 

[James Britt]

So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??

Where would be but for Not Invented Here?


--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[Mike Berrow]

It seems to me that Joel has accused us of having too much *fun* with
Ruby and with Rails. Way too much. And we all know that fun can't
possibly go hand in hand with productivity and *real* business.

-- Mike Berrow

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Joel Spolsky on languages for web programming"

|> That indicates that he trusts himself, and not me (Ruby). And I think
|> he's right.
|
|Really? I trust you a lot more than me, at least as far as designing
|languages goes.

To rephrase, he has right to trust himself than me. I think I am a
better language designer than him. But at the same time, I think he
is a better programmer to create enterprisy software.

|P.S. I've used Spolsky's software and read his books and it just so
|happens that I trust you more than him too.

I've read his book, but not used his software, so that I may not be
the right person to judge him.

matz.

 

[Richard Conroy]

I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":

So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??

Yes, *Joel* did. He makes quite a strong case for it:
"in defense of not-invented-here syndrome"
http://www.joelonsoftware.com/articles/fog0000000007.html

Also, I could see how looking at unicode in Rails could scare large
enterprise apps, but the scaling and slowness thing is just FUD.

The unicode issue is scary to an enterprise mindset, where having
a valid unicode mechanism that is 'non-unicode centric' still qualifies
as 'unicode antipathy'. The enterprise mindset has become happy
with the fact that unicode support is one of those things that they
don't have to think about in the languages/frameworks they favour.

The scaling/slowness thing though I can kind of understand (the
concern that is). I get
the feeling that Rails performs properly when you stick to the promoted
model, but if you deviate from it (processing too much, rather than
using the stack properly) you can choke your performance. Other
languages are probably more forgiving in this respect.

Don't forget the original context of Joels post: "Which web technology
would you bet your company on" (and by implication you house &
savings and whatever other assets you have used to get capital)

 

[Stephen Kellett]

Where would be but for Not Invented Here?

Paying homage to Doug Englebart rather than Steve Jobs.

Stephen

 

[Ben Harper]

I suspect the 'fun' thing is a bit of a stab at the frequency of the
word 'fun', as well as the 'programmer happiness' thing in Ruby and/or
Rails evangelism. I myself don't like such terms too much when used to
describe what I do.
I love my work, and some of it now involves ruby, but 'fun', in written
english, has connotations that perhaps do not suit the way myself and
like-minded people describe how we feel about our work. I would use it
in conversation, but I would not use it in a banner advertising my
working environment.

 

[M. Edward (Ed) Borasky]

Hi,

(2) Although Ruby runs slower than other languages in those
micro-benchmarks, real bottleneck in the most application lies in
either network connection or databases. So we don't have to buy 5
times as many boxes.

Allow me to rant on what we performance engineers do for a living ...

Most web applications I've encountered are not engineered for
performance -- *ever*. There's this little slogan they teach
programmers, which I've heard repeated numerous times on this list:

Beware premature optimization.

As a performance engineer, I don't consider premature optimization a
sin, of course. But leaving that aside, what it translates to is "make
it work, then make it pretty, then deploy it." Once it's deployed, it's
faster to "throw hardware at it" than it is to do the performance
optimization aka performance *re-engineering*.

Incidentally, the person who coined that slogan, Edsger W. Dijkstra,
said also that programming should separate the concerns of correctness
and efficiency. He *never* said to *only* worry about correctness. Part
of the discipline of programming is to pay attention to the efficiency
in equal measure to the correctness. That somehow seems to have been lost.

OK ... on with the rant:

1. Those of you who claim to be doing "test-driven development": If
performance testing isn't part of your test-driven development, you
aren't *really* doing test-driven development.

2. Micro-benchmarks are important. A few weeks ago, I ran and profiled a
micro-benchmark on "Matrix", which I posted to the YARV mailing list and
on my RubyForge project page. It's four times as fast in YARV as it is
in Ruby 1.8.5.

Whether it's YARV or some other low-level implementation techniques
really isn't important. What *is* important is that the Ruby "inner
interpreter", to borrow a term from Forth, *must* be as fast as it can
be given the other design constraints like compilers and portability.
The way to achieve this is with profiling on micro-benchmarks.

3. The future of "throw hardware at it" is multi-core processors and
storage array networks (SANs). If you aren't designing your applications
to take advantage of multi-processors, or if you aren't paying attention
to the "lower-level" I/O characteristics of your applications, they're
going to throw hardware at someone else's code.

Speaking of throwing hardware at it, there are ways to know what *kind*
of hardware to throw at it. Learn them.

4. An application with a network bottleneck is very often poorly
designed. One of the goals of performance engineering is *minimizing*
the amount of traffic between the client and the server.

Of course, if you're streaming audio, displaying high-definition video,
etc., the network traffic *is* the application, but an on-line banking
application should *not* have to send back more than a couple of
kilobytes to confirm that I've made a payment.

5. Database "bottlenecks": Most of the "industrial strength" databases
-- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
co-optimized with the operating systems and the platform hardware.
They've done their homework; they've done their performance engineering,
profiling and micro-benchmarking.

As good as they are, a poorly engineered database schema can make the
RDBMS work much harder than it needs to, requiring more hardware than is
necessary.

 

[M. Edward (Ed) Borasky]

I suspect the 'fun' thing is a bit of a stab at the frequency of the
word 'fun', as well as the 'programmer happiness' thing in Ruby and/or
Rails evangelism. I myself don't like such terms too much when used to
describe what I do.
I love my work, and some of it now involves ruby, but 'fun', in written
english, has connotations that perhaps do not suit the way myself and
like-minded people describe how we feel about our work. I would use it
in conversation, but I would not use it in a banner advertising my
working environment.

Yes ... I do what I do for a living (mostly in Perl and R, not yet Ruby
or Rails) for two reasons: I enjoy doing it and I get paid well for it.
Take away either of those and I'd go job hunting.