Again and again. Recently this InfoWorld article, sparks some Ruby x Java flames again.
I try to find some references about the author, but now I realize: it don’t matter, I think there is a pattern. People simply HAVE to write something. And they really do…
Regards the article's title, it again put RoR x Java, trying to convince us that: first COBOL is dead. It is ? It really is ? Java / J2EE, DB2, COBOL CICS integration is the recursive task that I work TODAY. And Second RoR is forcing Java programmers to invest in new skills. What I can say about that ? at least ridiculous ?
On the first paragraph we have this pearl: “Java is losing ground to Ruby on Rails, PHP, AJAX and other cool new languages”.
New languages ? Ruby is a language, RoR is not, and if we consider the first public release date, Ruby, PHP AJAX (read, JavaScript + XML) and Java it self are ALL born in 1995.
Next, another good one “Simply put, developers are saying that Java slows them down”.
Hehey… with these new “auto everything, super smart” IDEs, there is no excuses like “that language slows me down”. That is the crucial point. So many people are confusing and mixing languages with platforms and / or frameworks (may be Sun is partial guilt to don't clearly put the language and platform apart, commercial interests ?).
I really don’t waste my time comparing languages performance, and that is the point where I really agree with Matz: “machines are not important, people are important”. So, the language you choose must be the one that gives you more fun. OK, there are some practical issues that must be considered, but that is the spirit.
You run a performance test, You have a point. The same program runs faster on one language then the other, but witch language will give you the best software ? It will be the one which your programming team feels better.
And what is really slowing us down ? I think, the platform is guilt, it is really a mess trying to configure ALL the “possibilities”, because we can do anything anywhere "Write once, run anywhere" remember ? We just have to “configure”, or in other words, tie those “compatible” pieces together.
There is a Java vs Ruby (Gregg Pollack and Jason Seifer) video that illustrates this situation, if you don't know, take a look. In fact, these videos are becoming a hype on RoR community.
Now the best: “CEOs of Twiki.net, and Sendori states that Java platform (J2EE in this case) is becoming more and more complicated … and RoR on a shopping cart for an e-commerce site...” is the heaven ? Dahaha. Just a simple matter of “convention over configuration” baby.
And it continues… “Another area of (Java) weakness is the development of mobile applications …and no wonder Google is creating its own version (Android)”
And what is this Android ? "Android as it is currently defined is a fork of the Java ME, it is similar to the Java ME, but it's a (open source), non-conformant implementation, In fact, it's not really Java".
The real problem here is the fact that JavaME is a proprietary copyrighted solution. This new open source platform is a mutch better aproach. Android supports Java (the language) now, but could support Ruby in a near future. And again, we are talking about platforms, not languages.
And the grand finale "developers and analysts agree that Java is alive and well for internally developed enterprise apps. On the back end, there is still a substantial amount of infrastructure available that makes Java a very strong contender, says Zephyr's Shah. (CEO of software testing provider Zephyr)". Haha, another CEO "de facto" statement…
Gonna have to really disagree, I'm experiencing J2EE slowing me down every major change or upgrade needed by the application. A recent practical example:. this new resource adaptor was needed by a recent implemented Java / J2EE application. We spent two weeks to the support team install and configure it, two weeks for "configurations" and tests with a sample application and just two days to change and test the application. Who is the guilt? Java language? I don't think so.
Let's try another formula ? May be COBOL vs Ruby !
On the blue corner we have: the first, the oooonly and all procedural oriented: COOOOOBOOOL.
On the red corner we have: the neeeew, the funniest and totally object oriented: RUUUUUUBYYYY.
Sorry. I feel it will never ends…
Monday, December 31, 2007
Ruby x COBOL, the final... combat ?
Posted by Marcos Ricardo at 5:30 PM 2 comments
Labels: Other
Saturday, December 22, 2007
Ruby Christmas and New Year best wishes
From: Me
To: You
Cc: All
We can find hope on unexpected places…
We just need to want to.
And here is my last code of the year:
Posted by Marcos Ricardo at 4:54 PM 2 comments
Labels: Other
Sunday, December 16, 2007
Rails, Rails and my Ruby weekend after
That was amazing!
And those presentations confirm my “
Followed Google with just a few points:
- Test Driven Development or Behavior Driven Development (the newest euphemism) with Ruby.
- Domain Specific Languages and how to use .
- Agile Development Techniques.
Thanks to: Danilo Sato, Ronaldo Ferraz and Vinicius M Teles / Marcos Tapajos, respectively to open my mind on that subjects.
Those last events are all about Rails, but I will not start with Rails yet.
So I have to find a way to practice the first two items with Ruby only.
About Unit Testing with Ruby, I started With Satish Talin.
By the way, on my research about TDD and DSL, I find a useful place to MetaProgramming, and keeping me DRY on “Ruby thinking way”.
OK, OK, I have to start with Rails ASAP...
That is Cool!
Posted by Marcos Ricardo at 12:55 PM 2 comments
Labels: Rails, Ruby Language
Sunday, December 9, 2007
My personal Ruby project
After working with java for a while, a problem came up to me.
My recurrent problem is: lack of more descriptive comments on Javadoc for generated getters and setters on Database field’s value objects.
Unfortunately we access DB directly here no Hibernate, just some regular SQL on DAO, and associated VOs.
Here is an actual VO sample:
/**
* @return the cdNAT
*/
public java.math.BigDecimal getCdNAT() {
return cdNAT;
}
/**
* @return the cdSUCDESTPAG
*/
public java.math.BigDecimal getCdSUCDESTPAG() {
return cdSUCDESTPAG;
}
And here is a desired one:
/**
* @return the event’s nature from the payed indemnizations
*/
public java.math.BigDecimal getCdNAT() {
return cdNAT;
}
/**
* @return the office’s code from the payed indemnizations
*/
public java.math.BigDecimal getCdSUCDESTPAG() {
return cdSUCDESTPAG;
}
We have comments on all tables (and columns), on data base.
So my project is: create a Ruby application that will gather comments from database, join the terms: “return the” with the column comment and “from the” with the table comment, and create a really descriptive comment on Java source.
On the first version, will have to pass the java file and the table name.
On further versions, will try to do a deep analysis on corresponding DAO class, taking all table names, locating the child VOs and do the work there.
Current status:
- I have all the SQL needed to the job tested using tiny Ruby programs;
- I’m studying “active records” to use it on my Ruby programs;
- Made some practical tests, and experiences to select a Ruby GUI, to get it done.
The future:
- Extend this functionality to Ruby / Rails.
- Try an open source project on that subject, or include this functionality on an open source project that already exists.
Posted by Marcos Ricardo at 3:36 PM 0 comments
Labels: Ruby Language
Sunday, December 2, 2007
Rails, a lightweight and unobtrusive framework
May Rails be the first “love at never sight” case in history?
That is true, I never sight Rails deeply before, just some articles and podcasts now and then.
But there is a good conductor on it.
A basic one is the “convention over configuration”.
The way I get to Java / J2EE world is a bit weird.
I came into that to keep myself on IT market, but that assort of configuration work needed to accomplish a Java application, bothers me a lot.
Another one is the “non
That is: not to stand neutral about something, just make a decision (a good one) about anything involved on a web application.
We know that we have to use “active record” when dealing with databases, and now with Rails 2.0, we know will use REST pattern to tie the application pieces all around.
That is cool, since I will not be dealing with configurations and decisions that have nothing to do with a developer principal concern: the application itself.
More details? You can find here, where David Heinemeier Hansson, explains why Rails 2.0 isn't going to be a unicorn.
Posted by Marcos Ricardo at 7:07 PM 0 comments
Labels: Rails