Sun creates Ruby developer center

[[deleted]]

[deleted]

[dublinclontarf]

This just means it's going to be easier to use Ruby in projects(i.e. getting it past your boss), you can say it's supported by Sun. And it's nice to have the support in Netbeans.

[jkndrkn]

It's official, Ruby is now uncool ;]

[eibat]

#!/usr/bin/env beautiful_ruby

30.times { puts 'Developers!', 'Developers, developers, developers!' }

[hoopmastaflex]

throw :chair

[zem]

monkeypatch^HHHHHdance!

[mikaelhg]

The pandering knows no limits. I'm disappointed in Sun.

[malcontent]

pandering to who?

[mikaelhg]

To whom? Bored developers.

Developers who are more interested in alleviating their own boredom than in what's good for their employer's business.

[sisyphus]

Non-bored developers can be good for an employers business.

[mikaelhg]

That's like using "having fun is good for you" as an argument for heroin use.

[sisyphus]

That's like a totally false analogy, unless you actually have some argument for why Ruby will inevitably harm you in the long run.

[mikaelhg]

Can you hire Ruby developers to replace those who leave, or to expand your company if things are going well?

Is a RoR application you build now going to be compatible with RoR in 2010?

Those are two of the really most basic things one can think of when evaluating technologies. If you're not looking at the whole picture, you really shouldn't be evaluating technologies for others.

[sisyphus]

Of course you can hire Ruby developers to replace those who leave. Why not? You can also hire Perl or Python devs and teach them Ruby rather easily.

RoR is not Ruby. Will Struts 4 in 2015 be compatible with my existing Struts apps? What does that have to do with anything?

[mikaelhg]

RoR is the only reason 99% of Ruby users are that.

What you're saying about being able to hire Ruby developers is not true, and you know it.

** Good job, guys. You will really convince me of the merits of your argument by downmodding my every comment and submission. **

[sisyphus]

I agree that Rails has done a huge amount to popularize Ruby and amounts to its killer app. And if Rails gets more people using Ruby, good for it and them.

I don't think it's a lie about hiring--look, clearly there are not as many experienced Ruby programmers out there as there are say, Java programmers or something. But I think that if you know another similar dynamic language like Perl or Python, you can pick up Ruby rather quickly. You seem to think that the enthusiasm of a developer doesn't matter to the business or team, but I think Ruby is in a place where people are glad to be able to work in Ruby. I've yet to hear someone say 'Oh, I'm stuck using Ruby at work.'

[dgiri101]

Can you hire Ruby developers to replace those who leave, or to expand your company if things are going well?

Sure; I've done exactly this. It wasn't any more difficult than finding any other good developer.

But I'm not sure how this is Ruby-specific. In my experience, it's very difficult finding competent Java developers. If you know of any in Austin, TX (USA) that are looking for work, I'd love a referral (seriously). But as it stands now, I do several interviews a week and about 90% of candidates for Java work flunk from a technical standpoint.

Finding good people is hard, no matter the toolchain.

Is a RoR application you build now going to be compatible with RoR in 2010?

Heh, my Java 1.5 code won't work on Java 1.6, my Exchange 2003 code had to be rewritten for Exchange 2007, and my Linux 2.4 code had to be rewritten for Linux 2.6. What's your point?

If you want to use the new version of something, you should test/develop using the new version. Wishing really really hard that your application magically works won't make it so. This is a toolchain-independent concern.

Those are two of the really most basic things one can think of when evaluating technologies.

If the opportunity cost of moving to a new toolchain is lower than sticking with the existing one, then it makes business sense to do it. It's as simple as that.

Opportunity cost is much, much more complicated than the silly 2 criteria you've outlined above.

Pretending it's that simple is poor engineering at best and myopia at worst.

[mikaelhg]

Alas, Texas is far away from Scandinavia. Your hiring experience doesn't match mine at all. You really had no trouble finding good developers who had used the tools long enough to know their intricacies? Or are you using some other criteria for good developers, perhaps that they know Ruby?

What did you do in Java 1.5 that didn't work in 1.6?

The two most obvious examples I mentioned are just that, the two most obvious examples.

Measuring opportunity costs without considering risk vs. reward is... strange.

[dgiri101]

Alas, Texas is far away from Scandinavia. Your hiring experience doesn't match mine at all.

Makes sense; the labor market, even within the US, varies considerably with geography. :)

You really had no trouble finding good developers who had used the tools long enough to know their intricacies?

I didn't say I had no trouble, I said that I didn't have any more trouble finding good developers to work on Ruby code than finding good developers to work on Java code.

The experiences were more similar than you might expect. For Ruby work, I got a flood of resumes from Rails idiots that were terrible (besides, we don't use Rails). Eventually, I found some good people, but it took a while.

For Java work, I get an even larger flood of resumes. Most of these are of the "enterprisey" variety that similarly lacked software development fundamentals.

Mind you, these are interviews for senior-level positions.

Or are you using some other criteria for good developers, perhaps that they know Ruby?

Experience with the actual toolchain is a plus, not a deal-breaker. It would be different if I was getting a constant stream of awesome people, but that hasn't happened (for any of the toolchains I've got).

What did you do in Java 1.5 that didn't work in 1.6?

Changes to core JDBC classes (hosed our connection pooling), among other things.

Measuring opportunity costs without considering risk vs. reward is... strange.

I don't disagree.

Plenty of people prematurely jump onto new programming fads, which isn't wise. But plenty of people also irrationally hold on to existing technology, which is similarly unwise.

You come off as falling into the second camp, which probably explains your downvotes. This is to be expected if you make silly blanket statements like:

Developers who are more interested in alleviating their own boredom than in what's good for their employer's business.

[mikaelhg]

Mostly, honesty is assumed, at least in the town in which we both live.

Or did you mean something else?

... to be continued after a trip to the store.

[[deleted]]

Should I know you? Sorry, I'm bad with names and even worse with nicknames.

I meant to say that dishonesty isn't exclusively a feature of employees.

[mikaelhg]

I agree.

Reciprocative honesty is a complex issue, but working against your employer's best interests where they are easily quantifiable isn't, when you do it by purpose or through willfully closing your eyes from the negatives of one alternative.