Utter pants. I mean, you used the word "bloat", which should make people 
lose any debate by default.

Alvin Ryder wrote:
> Java and C# are no guarantee for success. 

Neither is Ruby / Rails. *No technology* is a guarantee for success, no 
technology ever was, and I'll bet a gold bar against a plastic spoon no 
technology ever will. Technology used is a very important decision to 
make, but it never single-handedly moves you from doable to undoable or 
vice versa.

> you seem to need 10 instead of 3 people and 5 times as long.

Pure, unadulterated shite. Give me numbers. Credible statistics and real 
research, not random anectodal success stories that are too pathethic to 
sell Herbalife diet pills.

Also, initial development cost isn't a very important factor. Recalls 
your uni software lifecycle charts about how much of a project's life is 
maintenance. For a successful project, the numbers are very much true. 
With a successful product comes the responsibility of supporting it and 
keeping it successful, and in some cases this responsibility creates 
ongoing costs that dwarf the initial development horribly.

> Ok, sure Java's OO may be nicer than Perl 5's but once you brew
> HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
> isn't exactly what I'd call pretty. Java is in no way a safe bet.

Noone cares about pretty. It's also a completely irrelevant issue when 
deciding on implementation language if you're at least remotely responsible.

> How about C#, well it runs in Windows and without serious and expensive
> firewalls you just can't go anywhere near the Internet.

You need to tighten off Unix-based servers too. Heck, there are even 
serious and expensive firewalls for Linux around too, because not 
everyone has an in-house iptables guru.

> Ruby and Rails just get straight to the point. They make common things
> easy and elegant. 

Sometimes things aren't so common. Ruby and Rails DO have faults. Just 
google around, I'm not going to go namecall out of respect and out of a 
sense of realism - every technology has flaws and any mudslinging would 
only lead to a pointless flamewar. Sometimes they are uneducated rants 
and / or whining, but some of them are valid.

And if you do NOT go out and learn about these flaws, and what impact 
they could have, and be fully aware of them when making the 
implementation technology decision on a project to consider the severity 
of their impact under the circumstances of your project, then your 
decision may cause a lot of trouble.

 > If execution speed really is a problem then I reckon
 > it'll get fixed.

Speaking purely theorethically, Ruby can not be made as performant as 
Java or C# could be made if they had ideally performing implementations. 
Latent typing makes it almost impossible to do certain optimizations as 
static typing does. That's pure fact. Of course, it's not saying Ruby 
can't be fast enough - but there have been people with more experience 
at the performance side of software development that talked much better 
about that

> As for developing major sites with Rails, most managers don't have the
> balls.

I advise you go on throught freshman year on a management school. It's 
the managers' job to "not have balls" and risk when there's apparently 
nothing to be had from taking it. If you want to be a Ruby advocate, you 
need to be able to persuade them, not yourself, of the advantages or 
using it.

> They'd rather pay millions to get a java solution, it isn't
> their money on the budget so they gutlessly pour it down the java hole
> and hope for the best. If the project fails they blame the team or
> throw more money and bodies at the problem, of course it's not java's
> fault or theirs.

That's because it's not. Since projects never fail purely on a 
technology solution - they fail on results of bad project planning more 
often than not (assigning novice programmers to large projects that will 
probably go over their heads), mistaken business objectives as whoever 
contracted the software finds he isn't really interested in what the 
tech demos had to show at all.

And the stereotype of lazy management that never gets punished is good 
to make Dilbert strips from - in real life, it probably doesn't hold 
true outside of a select few huge moloch companies, or on the opposite 
side of the spectrum small short-lived hick-led shops where the bosses 
kids and nephews gets all sort of crap assigned to get better allowance. 
In a well-led company with working internal management processes, when 
the shit hits the fan, everyone gets the stink.

David Vallner