Java vs. Ruby LOL

[Sonny Gill]

Ok, this would at least make you smile



@ garbett.org - Java/Ruby Flamewar

- Sonny

[Jeroen T Wenting]

I could do better than that... But I'd need a serious wideangle lens to get the entire stack of Java books in the picture

[Ulf Dittmer]

So does this mean Java is really hard to learn -compared with Ruby/RoR- and needs lots of books to explain, while everything you need to know about Ruby can be said in 2 books?

[Chetan Parekh]

[Jeroen T Wenting]

Originally posted by Ulf Dittmer:
So does this mean Java is really hard to learn -compared with Ruby/RoR- and needs lots of books to explain, while everything you need to know about Ruby can be said in 2 books?

No, it means Ruby is so shallow and/or so few people use it that there's pretty much nothing to tell about it (and not enough people to buy a book to make it economic to publish one).

[Ernest Friedman-Hill]

Originally posted by Ulf Dittmer:
So does this mean Java is really hard to learn -compared with Ruby/RoR- and needs lots of books to explain, while everything you need to know about Ruby can be said in 2 books?

That's what I thought the photographer had in mind; is there another (non-inflammatory) interpretation?

[Gregg Bolinger]

If you read the original weblog entry linked to in the first post beneath the image, you'd know that they guy says he used all those books for developing web applications in Java (yes, appearntly the JFC one as well) but only needs to the 2 books to develop the same applications, in less time, with less code, in Ruby and Rails.

[Amit Batra]

I like how all those books have been stacked. but im not entirely convinced. Im sure there are things in java you could do alot faster with lesser code also. I mean if ruby does even start to get big java will just evolve and get better.

[ankur rathi]

Who is Ruby???

[Bert Bates]

Isn't the point that for big, billion-transactions-a-day, load balanced, fail-over, huge development team, type of situations, Java really scales but has a lot of overhead? Whereas RoR is pretty awesome in a small shop for small to medium sized applications? So it boils down to choosing the right tool for the situation?

[Michael Ernest]

Reading not too far in, I see this guy's idea of Ruby power is the argument for Perl/Python/PHP power: that is, dynamic-typing accompanied by some amount of dense expressive power, simplified library access, code generation techniques, or all three.

There's lots you don't have to write. This result is 'economical,' but it isn't necessarily 'elegant.' Perhaps I'll blog on that point if I get some minutes and motivation.

Other syntactic sugaring in Ruby makes it easy to express iteration constructs briefly, among other things. Also nice. I especially like the busywork that can be done quickly: generating MVC application frameworks; building skeletal classes with method bodies, and; updating libraries. All are easy to execute. The intense focus on user ease in Ruby does yield several useful conveniences.

What your blog author isn't saying, though, is that only by having read the Java bookstack on the left does he have any clue why the books on the right are so powerful. That's also fine -- unless you have a problem in your code. When you need to debug key relationships, such as a mismatch between a database schema and its object representation in your RoR schmeer. Or does Ruby prevent you from making those kinds of mistakes? I haven't read along far enough to know for sure.

As with Perl and other dynamic-typing languages, Ruby doesn't require that you understand the internals to be productive. But if something breaks, or you need to test the framework itself, or debug it, it's another story. That's when all the cost of dynamic typing rears its ugly head..

As Bert said, this is still not a big threat to solo or small-group development. You wrote your code, you know your code. But for large groups, especially ones with significant staff turnover or with a practice of handing off code from group to group, it's a short path to a lot of confusion.

Some of this Ruby loving, I think, is summer romancing. Type-checking is tedious. And, as with most things in summer, brevity is sexy. How quickly people forget the Java knowledge that developed their appreciation for Ruby and the escape to dynamic typing. Why would anyone ever go back to such a static relationship, with all its rules and needs and limits? We have to grow, man! We can't be held down!

But when it gets to bigtime projects, we'll see if the tune remains the same. It's not you, Ruby, it's me. But we'll always have that 92-line shopping cart we made together. I'll never forget you...

Ruby does shows that static typing isn't an all-purpose approach, as if we didn't already know that. For example, application environments for which code itself has a short shelf life. Where's that again? Oh yeah: web apps.

Has anyone yet mentioned, by the way, that your average Rails app runs even slower that server-side Java? Or is that hitting below the belt?
[ August 21, 2006: Message edited by: Michael Ernest ]

[Frank Silbermann]

You don't need the book on JBoss unless you want to be a JBoss administrator. I've used Tomcat to build web applications without reading any Tomcat books.

You don't need Patterns of Enterprise Architecturem, Core J2EE Patterns, or J2EE Best Practics unless you want something more that a simple web application. If you do, the book is equally relevant for Rails -- or would be if Rails offered anything more than simple applications.

You don't need the book on Web Services to do a web application -- only for building web services. I've heard of Rails ease for building web applications, but I've heard nothing about its use in building web services.

You don't need JUnit in Action unless you want to use JUnit for unit testing; I haven't heard anyone say that unit testing is simpler in Rails (perhaps Rails programmers simply don't do unit testing).

You don't need Java and XSLT unless you want to do XSLT transformation of XML documents, which Rails does not provide.

You don't need Java Foundation Classes unless you want to build an applet to run in your web page. With Ruby/Rails, you cannot build applets.

Hibernate in Action may be necessary to get a persistence layer. It might be interesting to investigate whether one can use Hibernate to develop a "general-purpose" persistance tool that mimics the defaults provided by Rails. Then you wouldn't need to fool with Hibernate any further -- if you were satisfied with the Rails-like defaults.

Java in a Nutshell corresponds to the Programming Ruby book.

I don't know anything about XDoclet; so I suppose it cannot be too vital.

-------------------------------------------------------

That leaves us with Jakarta Struts, Struts in Action, Jakarta Struts Cookbook, Java Server Pages, and Java Servelet and JSP Cookbook against Agile Web development with Rails. I have never used Rails, but I tend to agree that JSP/Struts stinks. For a competent object-oriented programmer, I believe that Java Wicket will prove to be far more productive than either of these alternatives. (However, Rails may be easier for hackers too incompetent to benefit from code re-use facilitated by object-oriented abstraction techniques.)

Rails aside, there has always been a trade-off between the compile-time checking and runtime efficiency of statically-typed languages such as Java and C++, versus the polymorphic flexibility of dynamically-typed languages such as Smalltalk and Lisp. I remember how Smalltalk was growing in popularity twelve years ago until the Java bandwagon pushed it aside -- mainly due to its superior security architecture and greater familiarity to C/C++ programmers.

Perhaps Smalltalk deserves a second look. Is there any reason to believe that Ruby is more flexible and expressive than Smalltalk?
[ August 21, 2006: Message edited by: Frank Silbermann ]

[Marc Peabody]

Tonight I had my first Ruby Brigade (user group) experience.

Why am I looking at Ruby?

It seems that every time there is a need in Java, we add another layer to it. I wish we could do more to change the language to make it do what we need.

For some reason our language isn't evolving. Instead, it's growing cancerous tumors. I can't help but think of JSF at the moment. I've been a big fan of it for a while, primarily because I know it's better than Struts. But JSF is just another layer of complexity added on top of an already complex spec.

We're not stupid. We've discovered plenty of best practices and design patterns along the way. Why doesn't our language make those things easier? Why isn't "singleton" a keyword? Why isn't there a keyword to provide default accessor/mutator methods against my variables so I can have simple encapsulation without cluttering my classes with passive method declarations?

Why do I have to map everything in an xml document? Realize, our xml documents are user manuals for Java to understand what we need it to do. Without it, our language isn't smart enough to keep up with us.

Consider struts-config.xml - it should have prompted us to change Java. It showed us that our domain was changing and we needed to add a few words to our vocabulary. Instead, Java gave us another competing framework in JSF, with its very own xml config file.

Bummer.

[Johannes de Jong]

Originally posted by Bert Bates:
Isn't the point that for big, billion-transactions-a-day, load balanced, fail-over, huge development team, type of situations, Java really scales but has a lot of overhead? Whereas RoR is pretty awesome in a small shop for small to medium sized applications? So it boils down to choosing the right tool for the situation?

Perfect reply B

[Johannes de Jong]

ME you deserve a round of malt

[Frank Silbermann]

Originally posted by Marc Peabody:
Tonight I had my first Ruby Brigade (user group) experience.

Why am I looking at Ruby?

It seems that every time there is a need in Java, we add another layer to it. I wish we could do more to change the language to make it do what we need.

For some reason our language isn't evolving. Instead, it's growing cancerous tumors. I can't help but think of JSF at the moment. I've been a big fan of it for a while, primarily because I know it's better than Struts. But JSF is just another layer of complexity added on top of an already complex spec.

We're not stupid. We've discovered plenty of best practices and design patterns along the way. ...
Why do I have to map everything in an xml document? ...
Consider struts-config.xml - it should have prompted us to change Java. It showed us that our domain was changing and we needed to add a few words to our vocabulary. Instead, Java gave us another competing framework in JSF, with its very own xml config file.

I agree that adding yet another layer of complexity to J2EE is crap. Fortunately, there are a few Java frameworks which _replace_ rather than paper over the problem. Most of you are familiar with the superiority of Hibernate over older-spec entity beans (so much so that the latest EJB spec basically incorporates Hibernate).

On the web side, there are a couple of new Java frameworks which do not add a layer to the Servlet/JSP/TagLibrary/Struts/JSF stack, but rather replace most of it with a much simpler and more powerful technology that leaves "easy" tools such as Rails and PHP in the dust. Wicket is one such framework; Echo2 is another. Each build directly upon servlet technlogy (basically hiding it from the user) and throw away all the JSP/TagLibraries/Struts/JSF crap.

These technlogies are superior to Ruby/Rails and PHP for the same reasons that C++, Java, and Smalltalk are superior to C, Fortran and Pascal -- they allow you to write all program logic (not just business logic but even presentation logic) in an object-oriented language. This means that any complex logic you write can be written in a reusable way. (Note that the Design Patterns you reference require an object-oriented language to be easily implemented.)

Most web applications exhibit patterns of display logic that suggest opportunities for re-use, if only the tools could support it. But once your logic is embedded within HTML (or XML) tags, it is pretty much frozen for life. Now some will claim that JSP allows you to put presentation logic within re-usable custom tags, but the nesting and association of custom tags is also an expression of presentation logic -- so how are you going to reuse that? (And do you really want to configure every re-usable component with XML?) Wicket and Echo2, however, allow you to keep all presentation logic separate from the HTML, in Java, without XML, and therefore a high-IQ developer can find savings that a PHP or Ruby/Rails programmer cannot even dream of.
[ August 22, 2006: Message edited by: Frank Silbermann ]

[vasu maj]

Ruby ON Rails