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…
Hi,
In message “Re: Joel Spolsky on languages for web programming”
on Fri, 1 Sep 2006 20:30:02 +0900, “Dido S.”
[email protected] writes:
|Language Wars – Joel on Software
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.
On 9/1/06, Dido S. [email protected] wrote:
Language Wars – Joel on Software
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.
On 1 Sep 2006, at 14:00, Yukihiro M. wrote:
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.
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.
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:
Regards,
Rimantas
On 9/1/06, Dido S. [email protected] wrote:
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
On Sep 1, 2006, at 9:20 AM, Rob S. 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.
James Edward G. II
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 H.
Hi,
In message “Re: Joel Spolsky on languages for web programming”
on Fri, 1 Sep 2006 23:28:09 +0900, James Edward G. II
[email protected] writes:
|On Sep 1, 2006, at 9:20 AM, Rob S. 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.
Well, to be fair, it’s not quite that.
Start with The Road to FogBugz 4.0: Part III – Joel on Software –
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
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 B.
On 9/1/06, James Edward G. II [email protected] wrote:
On Sep 1, 2006, at 9:20 AM, Rob S. 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.
James Edward G. 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
On Sep 1, 2006, at 9:36 AM, Yukihiro M. wrote:
|> “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 G. 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 S. wrote:
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 B.
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
Hi,
In message “Re: Joel Spolsky on languages for web programming”
on Fri, 1 Sep 2006 23:49:44 +0900, James Edward G. II
[email protected] writes:
|> 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.
In message [email protected], James B.
[email protected] writes
Where would be but for Not Invented Here?
Paying homage to Doug Englebart rather than Steve Jobs.
Stephen
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.
On 9/1/06, Rob S. [email protected] 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”:
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”
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)
Yukihiro M. wrote:
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:
-
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. -
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.
- 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.
- 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.
- 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.
Ben H. wrote:
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.