Link Details

Link 800453 thumbnail
User 1015259 avatar

By andrew.c.oliver
Published: May 31 2012 / 11:50

Now that Ruby is more mainstream the community should really give up the pitch that the reason to choose Ruby is developer productivity. There are much better reasons.
  • 18
  • 0
  • 2702
  • 2078


Add your comment
User 352719 avatar

Jonathan Fisher replied ago:

5 votes Vote down Vote up Reply

Productivity should be measurable, right? Can the 'engineer' put some numbers to his claim? Real engineers deal with numbers, so it shouldn't be a problem for that guy.

"More productive" is just reverse FUD from the Python and Ruby communities. When it comes down to it, Ruby/Python may be more "fun" but in all likeliness doesn't have some magictastical property that makes all developers who use it into super productive people.

User 1015259 avatar

andrew.c.oliver replied ago:

0 votes Vote down Vote up Reply

I think you hit the nail on the head. I don't think these are logical or quantifiable arguments. There are certainly things that make me individually more productive with Ruby than with other languages (such as Java), but I can't say these make a huge difference on the project outcome when it is a more than single developer project. In fairness I think it is a "growth" thing. Now that Ruby is used and proposed on larger, more serious projects -- it needs to make a larger and more serious argument. When it was used on more 1 man projects "you don't have some horribly cumbersome packaging system and can 'edit in place' if needed" -- is a decent argument.

User 352719 avatar

Jonathan Fisher replied ago:

0 votes Vote down Vote up Reply

...couldn't agree more! I love the standard Ruby API. I've long been a proponent that Java should drop it's dead weight, break backwards compatibility and create a new standard API that leaves the crappy parts out...

here's my short list:
0) Examine the API of Ruby/Python and figure out how to do "simple things" with a single step
1) No checked exceptions on API classes
2) No factories
3) All API classes should be designed to be thread unsafe and unsynchronized. Only synchronization classes should be thread safe

This things are enough to be "annoying" but not make a huge difference on average across large teams.

User 338269 avatar

Miloskov replied ago:

0 votes Vote down Vote up Reply

Ruby is for the cloud?, I dont think so. Rails is just an MVC framework as anything else, What Rails changed the way to develop frameworks it was the CoC but thats all I dont see difference between ASP MVC, Django, Spring MVC, Play2 and Rails.

Ruby is just a dynamic language as they call them I will call it a scripting language as it was with Perl, PHP, Python. On Web terms It is just a server side language.

A real Cloud based platform with Concurrency, Parralelism , Events programming language and framework I will look more into Javascript/Node.js, Scala with Typesafe stack or Erlang.

User 1015259 avatar

andrew.c.oliver replied ago:

0 votes Vote down Vote up Reply

I agree that Rails is not great to be honest. I make mention that I'm not a big Rails fan. In general I haven't found anything much better than JSON for the front end and "whatever you like" on the back end that emits JSON. Node.js appeals to me for the hope of a unified language.

Because dealing with the costs of a project are a key part of my job responsibilities, I'm more dubious of Scala and Erlang. Most business apps are not rocket science, so really I need a language that lets me utilize junior developers for the bulk of the project and senior developers only for the heavy lifting.

Add your comment

Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Apache Hadoop
Written by: Piotr Krewski
Featured Refcardz: Top Refcardz:
  1. Play
  2. Akka
  3. Design Patterns
  4. OO JS
  5. Cont. Delivery
  1. Play
  2. Java Performance
  3. Akka
  4. REST
  5. Java