Joseph said:
Risk Management IS NOT equivalent to FEAR, in that you are right.
However, as I said earlier, no SIGNIFICANT progress can be expected
without some risk. Risk Management is about dealing with risk, not
eliminating it.
This we agree on.
Ruby and Ruby on Rails are not the safest choice, but I believe they
are one of the very best choices for web development. There is a
slight risk in it, but not enough to stop any bold, courageous
corporation, startup or even lone developer to create great software
with it.
And we agree on this too, to some extent. My argument is mainly that
without a certain level of knowledge about Ruby, the level of risk is
unknown, in which case it is prudent to assume the likely risk is high
until you have investigated it closer.
For those of us that know Ruby, the best we can do to spread it is to
help people get to the stage where they know enough that they can
accurately assess the risk of using Ruby for their projects, but until
people have that knowledge the risk as seen by someone who doesn't know
Ruby will be higher than the real risks with using Ruby.
Joel and people who share his views, equate Risk with FEAR. That is
their main mistake. Ruby is ready now... not for everything, but is
uniquely ready for web development, that is I believe a fact.
And it may very well be a fact, but again, there are still risks, and
those risks are greater for someone who doesn't know Ruby, or who
doesn't have the skills inhouse, whereas the corresponding risks for a
Java shop of doing something in Java may be very low if their staff is
skilled enough in Java.
Personally I hate Java and love using Ruby, but if I had to manage a
team of Java guru's, I'd still consider java as a safer choice than
Ruby unless the project was long enough to take significant time
retraining staff and possibly hiring replacements for anyone who decide
to leave.
They then have to make a tradeoff: low risk in Java (or C# or PHP or
LISP or whatever language they have the sufficient experience with to
make the risk a known, low factor) or a possibly higher risk in another
language vs. _possibly_ lower cost and shorter development time.
Developer hapiness doesn't count unless it affects one of the previous
two, or increases employee retention.
However, that possible payoff depends on whether they make a
successfull transition, which they won't know the chances off if they
have little to no exposure to the language. It also depends on whether
Ruby is right for _their specific project_, which they won't know if
they have little experience with the language.
These factors are all reasons why - regardless of how good Ruby is -
for someone to be picking Ruby just because you and I and other
Rubyists say it's good without having a reasonable degree of knowledge
about how appropriate it would be for their project themselves would be
quite irresponsible.
As another poster mentioned, there is an evolution in the adoption of
technology. Ruby is still with the early adopters, but that does not
mean is not mature enough for critical applications.
For some it certainly is. But despite having a reasonable experience
with Ruby, I'd hesitate about making a blanket statement about it.
Performance _will_ be an issue for some apps (as I've noted elsewhere,
it won't be for _most_ web apps, but there certainly are web apps that
are CPU intensive too, and where C/C++ extensions would be vital if you
were to go with Ruby at the current stage), and lack of certain
libraries might be an issue for some.
Feature poor XML integration IS an issue for my company (Edgeio.com) at
the moment. It's one we expect to solve, but at the cost of additional
work which we wouldn't incur in some other languages. Ruby is still
good for us, but it's not a panacea for all types of development. It
likely never will be, but as time goes the space of apps for which Ruby
is a good choice will of course increase significantly and I do believe
it can supplant many currently more widely used languages.
We still use PHP for our web frontend, though. All our Ruby code is in
the backend for now. I did consider Rails, and maybe we'll migrate to
it at some point, but currently the potential savings are too small to
outweigh the cost/time to migrate, and our frontend is growing thinner
and thinner as we refactor our middleware and backend, so it pays to
just wait for now.
What will prove me right however is not my rationale here or in my
previous post, but TIME, time will prove those who sticked to Ruby and
Ruby on Rails did so wisely, because TRUTH is tested in time.... I
believe Ruby is ready now, many people disagree, but ultimately time
and people using Ruby for critical applications will be the deciding
factor.
Ruby is ready now for some apps _if you have the experience_ or your
potential cost savings are large enough to justify taking the time to
retrain your staff or hire new people.
I use Ruby because it's the best of an increasing pool of bad
alternatives. I still haven't found a language I don't see tons of
flaws in, Ruby included. Ruby's flaws are just less annoying than the
rest
I don't believe in "truths" in language choices - people need
to pick what works for them, and while looking at what's popular is
often good, there are always exceptions.
Time will tell us indeed, but I am not waiting for the jury, I am
learning Ruby and RoR now, eager to apply it to create cool, amazing
web applications... isn't that the whole point? To push technology?
To make it fun again? To innovate?
That's one viewpoint. But the point for the companies considering
language choices is what technologies will bring them the greatest
profit at the lowest risk.
As much as it's tempting for me as a geek to pick technology based on
personal preference, ultimately I have a responsibility to the
shareholders that needs to take preference.
(and since I'm one of them, and I work at a startup, there's also the
hope of an opportunity for early "retirement"
)
Vidar
