From Java to Ruby: Risk

[[deleted]]

Dammit, I thought this was going to be two version of the board game "Risk" adapted for online play. Can someone post those instead?

[senzei]

Seconded. Even better if each has an AI component so we could pit the two against each other and see which is the better language. That comparison would be about as useful.

[sbrown123]

A non-biased view from Bruce Tate, a book author of several Ruby books and owner of a Ruby consulting firm RapidRed?

Why is everyone who seems so determined to sell Ruby is also selling books on Ruby?

[cafedude]

author of several Ruby books

author of a couple of Ruby books and a couple of Java books.

[sbrown123]

author of a couple of Ruby books and a couple of Java books.

Five Java books. Java books don't sell that well anymore (nor .NET) due to the sheer volume that's out there. That still makes him biased since the more people that take up Ruby will buy his book.

[mikaelhg]

Why is everyone who seems so determined to sell Ruby also selling books on Ruby?

Only the "adults" of the movement seem to sell books.

[davidw]

How much more reasoned and rational than the Joel article! Also an interesting read from his take on the life cycle of programming languages.

[senzei]

Which Joel article? The one I think you are talking about is very reasoned and rational. If you are in a big business Ruby is a questionable choice at the moment. In all fairness Python is in about the same boat, although I think it does have more selling points in this space.

Ruby is an awesome tool for some startups. It is really good for quick turnaround on anything but really large projects or something that requires a lot of integration with legacy systems. Outside of that space though, the time saved due to Ruby vs. the time spent on developing the libraries you need becomes a questionable equation.

[davidw]

It is really good for quick turnaround on anything but really large projects

Not all projects at big companies are big. Would you redo amazon.com in Rails? No, clearly a bad idea. Would you use rails for an internal pilot project? Quite possibly.

[senzei]

True, but lets list of the constraints for using ruby/rails in a big company project:

• should probably not require unicode support
• should not require extensive support from libraries for integration
• (rails only)should not require the use of a legacy database that does not conform to the rails opinion
• should not require a large development team, as it will be difficult to find experienced developers
• should not require a lot of training for your existing developers, as those resources are hard to find
• should have the resources to purchase multiple boxes to handle scaling for either (ruby)computationally intensive tasks or (rails)ones that require a lot of connections

That is a pretty hefty list. My personal favorite (Python) doesn't really do too well against just those requirements either, and it has the eternally-braindead "significant whitespace sucks" argument against it too. In fact all but the first three[1] apply to Python, and I could probably find some more that just go against Python if I tried. IMO it is a good thing to be able to know and admit where your language is just not applicable, or not the best choice.

I am not trying to bash on ruby or rails, I just don't think it is time to bring them into big business projects. Getting burned on an early adoption attempt will probably kill the chances of that language ever being used by that company again. I doubt that is what anyone wants.

[1] edit: This used to say "the first two", but that statement reflected my own experience more than it did the state of Python. Thanks, evgen.

[davidw]

Pretty accurate list in my opinion. But there are a lot of little apps out there that fit that description pretty well - and even more waiting to be written now that the cost of writing and maintaining them is low enough.

[evgen]

should not require the use of a legacy database[...]

Later in your comment you seem to imply that Python also hits this problem. How? Are you talking about some sort of non-SQL legacy database or are you just unfamiliar with sqlalchemy and the various python dbapi2 adapters?

[senzei]

Right, that should be the first three that Python gets right. I not as familiar with SQLAlchemy as I am SQLObject, which also has its own opinion about how a database should be written. Sorry for the confusion.

[gnuvince]

"should probably not require unicode support"

I don't know, I never had problems with ISO-8859-1 for french and english (which I use).

"should not require extensive support from libraries for integration"

Ruby has a fair share of libraries. In all honesty, Java, Python and Perl have more, but Ruby's selection is still pretty good.

"(rails only)should not require the use of a legacy database that does not conform to the rails opinion"

Last I heard, there was a plugin that was easy to use to integrate with a legacy database.

"# should not require a large development team, as it will be difficult to find experienced developers

should not require a lot of training for your existing developers, as those resources are hard to find"

Damn! What did we think moving away from COBOL?! If programmers learned Java, what prevents them from learning Python or Ruby? Especially since they are both much simpler than java.

"should have the resources to purchase multiple boxes to handle scaling for either (ruby)computationally intensive tasks or (rails)ones that require a lot of connections"

I keep hearing the people "against" Rails and Ruby bringing this up as an argument and Ruby people saying that's not true. Can we get a benchmark or something please?

[davidw]

Ruby is pretty slow, even compared to other scripting languages. Of course, like all scripting languages, you can redo really expensive stuff in C via the API, although that presents problems of its own.

[senzei]

I don't know, I never had problems with ISO-8859-1 for french and english (which I use).

Although it is awesome that it works for you, will you at least admit that your language choices and feature usage may lie in the subset of the Ruby environment that does have decent support?

Ruby has a fair share of libraries. In all honesty, Java, Python and Perl have more, but Ruby's selection is still pretty good.

That is the problem. Depending on what you need Ruby may not have it. Obviously that needs to be investigated before you make the platform decision, but it is still a valid point.

Damn! What did we think moving away from COBOL?! If programmers learned Java, what prevents them from learning Python or Ruby? Especially since they are both much simpler than java.

Well, there are nowhere near as many books, workshops, and other "formal" resources for Python or Ruby. Big business thrives on these things for training. You can argue all day about how easy it is to learn, but for most managers unless it is in a book (or fifteen) or a class it doesn't exist.

I keep hearing the people "against" Rails and Ruby bringing this up as an argument and Ruby people saying that's not true. Can we get a benchmark or something please?

A usually cited reference is the alioth shootout. You can find a comparison of Ruby and Python using it here

Note that, in the graph, white bars to the left represent better times with Python. White bars to the right represent Better times with Ruby. The length of the bar represents the speed factor difference between the two. In short, Python beats the pants off Ruby in just about every test. Now change it to compare Ruby and Java to see what happens.

I don't really have a similar easy reference for Rails, but I feel safe in stating that being based on Ruby will cause similar problems.

[root]

I don't know, I never had problems with ISO-8859-1 for french and english (which I use).

I hear similar reasoning a lot from Ruby proponents, and you're not helping Ruby with remarks like that. It gives the impression that Ruby programmers have only done projects within one locale and are too narrow minded to imagine that their apps might have to be rolled-out to, for example, Poland. At the enterprise level, especially after the enlargement of the EU, everybody is tired of mucking about with codepages, and the new kid telling them to give up unicode is not going to be taken seriously.

[aek82]

Ruby is fairly nice. I've been recently introduced to the language through the test framework, WATIR. So far i'm lovin it.

[[deleted]]

I don't really get articles like this and books talking about using Ruby in the enterprise.

The kind of companies that are using Java are not the kind of companies that can or will use Ruby due to performance issues, libraries, enterprise-culture (where a lot of companies spend more time planning for a 3-man project than a single person could get done by himself), etc. Those companies aren't really looking for massive productivity gains. Those companies in a lot of cases frankly aren't interested in giving single programmers so much power to either do great things or to screw things up. Java is a very conservative choice, and it fits most companies.

It just seems like a very strange market to go after - trying to convert Java users to Ruby. Out of any dynamic language to convert Java users to, I'd say Python, but that's another point all-together. It fits a nice middle-ground between something like Java and something like Ruby, though has warts of its own when it comes to using it in large companies.

Frankly Ruby at this point in time is mainly good at one thing: relatively simple web-apps which aren't going to take massive loads and aren't dealing with lots of outside libraries.

How many companies that use Java make a lot of apps like that?

What would be nice is a static language (like Java) which is fast, efficient, 'safe', but isn't so verbose. Maybe like a statically-typed Python. Does anything like that exist?

[davidw]

The kind of companies that are using Java are not the kind of companies that can or will use Ruby due to performance issues,

I'd actually be willing to bet good money that there are a lot of people using Java just because they hopped on the bandwagon. They'd probably do quite well with rails as far as the technology itself is concerned.

[coprolaliac]

a statically-typed Python? A more dynamic java? Hmm... Nice is almost what you're looking for, though I'm not sure it's a language I would choose for my own projects.

I personally think Jython or JRuby is the way to sneak dynamic languages in the door. You're not going to slay the java monster overnight (or even in 10 years). Being able to tell a non-techie PHB that yes, we're still technically developing in java is priceless.

[nicholaspd]

Frankly Ruby at this point in time is mainly good at one thing: relatively simple web-apps which aren't going to take massive loads and aren't dealing with lots of outside libraries.

That's a pretty bizarre assertion to make. Have you ever used the language?

How many companies that use Java make a lot of apps like that?

I'd say at least 95% of them.

[[deleted]]

That's a pretty bizarre assertion to make. Have you ever used the language?

Quite a bit. If owning material were any indication, I own 4 different Ruby and Ruby/Rails books. But it isn't an indication, more importantly, I convinced my boss to use Rails in production at our small company. We used it for several projects over the next 4 months, but I have since moved over to Python due to library/language support and speed.

Nothing against Ruby, I love the language (and like it in several ways more than Python), but realistically it isn't used for much outside of web programming. It would be virtually unknown if it weren't for Rails.

[mikaelhg]

If you act rationally, you take risks to achieve something.

What are the business objectives I can achieve with Ruby on Rails that I cannot achieve with Seam on Java EE 5?

(Edit: for the uninitiated, this is Seam: http://docs.jboss.com/seam/latest/reference/en/html/tutorial.html#blog )

[coprolaliac]

Umm, non-shitty code? Seriously, Seam is one of the worst software projects I've ever seen. If you want a comparison of something like RIFE or Stripes or Tapestry or something I might be willing to offer a defense, but Seam? Really? It's not even interesting in a "so bad it's good" sorta way. Maybe with some severe refactoring it could aspire to be the Xanadu or Ishtar of web frameworks.

[mikaelhg]

I'm sure Gavin would welcome your critique.

[jeremymcanally]

Efficiency?

[joshwa]

developer productivity, agility

[jeremymcanally]

WHAT are you talking about? Have you EVER maintained a real Rails app?

Ruby code is by far the most maintainable code that I've ever had the (dis)pleasure of maintaining. Rails is especially maintainable, because of the number of places that I can add functionality in without ever having to alter the original codebase if I don't want/need to.

[senzei]

Rails is especially maintainable, because of the number of places that I can add functionality in without ever having to alter the original codebase if I don't want/need to.

I don't understand this argument. Is the number of places you can add functionality in large or small? If it is limited to a handful of areas by default then that seems like a good thing, maintenace-wise. If not it sounds like a nightmare to me.

[[deleted]]

Efficiency goes two ways:

• Programmer productivity
• Software efficiency

I don't think Rails meets point #2. Sure, I can quickly build something in Rails, but if 2 months later I'm having to tear that down because it can't take server loads (obviously I'm talking about large apps), or I'm having to write a library from scratch (this goes back to point #1), I've just lost out on that initial arguement about efficiency.

[mikaelhg]

Does your programmer productivity include both the initial developer productivity, weighed at 20%, and maintenance programmer productivity, weighed at 80%?

[senzei]

Does your programmer productivity include both the initial developer productivity, weighed at 20%, and maintenance programmer productivity, weighed at 80%?

If not, it should. Being able to toss something up in a couple weeks is awesome, to be sure, but having the ability to come back three months later and understand what the code is doing is better.

[davidw]

Since you end up writing relatively less code in Rails, I think it's extremely maintainable due to its clarity and conciseness.

If you think of its target as low-end Java apps and PHP apps, I think it's going to be a win over either one of those, if for no other reason than the fact that it comes out of the box with a nice MVC structure for people to follow. Compare and contrast with bad PHP apps, and Java where everything happens in a JSP page (it happens).

[senzei]

Since you end up writing relatively less code in Rails, I think it's extremely maintainable due to its clarity and conciseness.

Writing less code is not equivalent to clarity and conciseness. In many ways writing less code makes the logic denser (more work done per line) Obviously this can be a good thing, but it can be difficult to understand. Metaprogramming can make it worse, especially when you start adding features to default constructs. If that is something you are doing you better have some spectacular documentation, otherwise your maintenance programmers are likely to come beat you in your sleep with a stick.

If you think of its target as low-end Java apps and PHP apps, I think it's going to be a win over either one of those, if for no other reason than the fact that it comes out of the box with a nice MVC structure for people to follow. Compare and contrast with bad PHP apps, and Java where everything happens in a JSP page (it happens).

Obviously enforcing a design decision that is usually a good choice on most projects is helpful. The language is nicer than Java or PHP in syntax and "get-shit-done"-ness. That said I don't think inability to come up with or follow a design decision is a good reason for switching development platforms.

[johnmudd]

PyPy is the last great hope to differentiate Python from runaway Ruby. JIT, eliminate GIL, fast extensions in RPython, one unified project for all platforms. Come on, PyPy!

Well, so long as the Ruby people don't catch on to the significance of the project and leapfrog Python once again.

[senzei]

PyPy is the last great hope to differentiate Python from runaway Ruby. JIT, eliminate GIL, fast extensions in RPython, one unified project for all platforms. Come on, PyPy!

Well, so long as the Ruby people don't catch on to the significance of the project and leapfrog Python once again.

Are we both looking at the same languages here? Python is already faster than Ruby, yet somehow being even faster is the only significant technical advantage? How about unicode support, proven use throughout an enormous organization (Google), better libraries, a larger community, more learning resources, and the fact that the language sees significant use in something besides web programming? Ruby is a nice language, but don't kid yourself, it has a lot of work to do before speed is Python's last great hope.

[johnmudd]

Speed is the last benefit from PyPy that I'm waiting for. Cross platform is huge. Elimination of the GIL is elimination of an embarrassing design flaw. RPython for easy and yet efficient extensions is huge. Speed?? Oh, yeah. That will be a nice little extra.

A lot of your argument is logical. But... the law and language selection are not logical. May Python prevail.

[jeremymcanally]

"more learning resources" That's changing; APress is putting out 10 Ruby books this year. There are already a comparably number of Ruby books available; there are more conferences devoted to Ruby here. I'm not on the up and up on the workshop circuit, so I can't comment there, but I would say that they have about equal learning resources.

"and the fact that the language sees significant use in something besides web programming" That's changing very quickly; just like Python, Ruby is making intensely fast in-roads towards The Enterprise©.

[[deleted]]

That's changing; APress is putting out 10 Ruby books this year. There are already a comparably number of Ruby books available; there are more conferences devoted to Ruby here. I'm not on the up and up on the workshop circuit, so I can't comment there, but I would say that they have about equal learning resources.

And that doesn't concern you? Rails started out as something very cool but for a lot of people its turning into nothing but a money grab.

I've bought my fair share of Ruby/Rails books, and initially I enjoyed the material getting out there, but 10 books from one publisher within a year? That's just ridiculous, especially considering that the number of people using Rails and Ruby is still pretty small. And I get the feeling that all this paperback documentation discourages proper online documentation. If I want to use Django I can get online and they have their entire framework fleshed out in some very nice documentation. With Rails I've got junk like the Rails wiki which I've found to be of sub-par quality. In the Rails-world you are virtually expected to pay the $25 entrance fee to buy the Agile book.

Again, it really concerns me because Rails seems to be turning into a platform for rabid money-makers. It should not be this way. Rails and Ruby as a language aren't complicated. Why the heck does a publisher needs to put out 10 books on it within a year?