From Java to Ruby – what I love, what I miss

UPDATE : Some follow up on this here.

Object

My story is probably similar to one thousand others: used to be a Java programmer, switched to Ruby six months ago when I quit my job to start 8th color. While discussing the “why” is probably not really relevant (short version: our product, Sybil, is a web front on a database, so it was globally for us a choice between Ruby/Rails and Python/Django, summarized there), I wanted to take the opportunity to write about the good and bad points of the transition, from my own personal point of view.

Disclaimer: This is an exercise at explaining a personal experience/opinion. I’m more than interested to hear yours. This is not an attempt to “prove” any “superiority” of a language on another.

Context

I still code some Java each week, as a part-time consultant (you need something to pay the bills), and we’re using Ruby for our startup related development, so I’m in both environments each and every week, which gives me a rather good view of my own quirks about each language. While most of those points are not IDE related, I use Eclipse for Java coding, and Sublime Text for Ruby.

What I love

Natural naming

Basically, Ruby is the first language I find that seems to think like me. When I code in Java and looks for a method name, I often rely on Eclipse (really nice) auto-complete feature. In Ruby, most often I just type the name that I would have chosen. More often than not, it works. This is not purely a personal matter or a coincidence: Ruby (and Rails) are known to expose the same methods several times, using synonyms (“size” and “length” can be used to return the number of character of a String, for example).

Collections and iterators

Even in Java, I’m already quite fan of using functors (or more correctly functors interfaces) on collections (take a look at “Predicate” in apache commons-collections for example), but those constructions, while useful, are lengthy in Java, not to type (again, Eclipse does a pretty good job there, creating the anonymous inner class, the method, and positioning your cursor at the place you need to type), but to read (in most situations, a short line will be more readable that the 6+ needed in Java).
Ruby’s iterators and the power that come with them with methods such as collect, select and especially map is staggering. More often than not, I start a method knowing that I have several transformations to do, expecting the code to span 10-20 lines, then write a small part, and discover that I’m done.

In addition to readability, this kind of easiness encourage me to use (abuse ?) collections, which is something I really like.

Console (IRB)

This has become my “exploratory” tool of choice. When I’m trying to figure out a solution, I often fire IRB and start testing along the way. The feedback is instantaneous, and once I’m satisfied with what I’ve done, I go back to my text editor.
The fact that Rails takes the same approach with the Rails Console is more than an added bonus: it is something I’ll have trouble living without (note that something similar is possible for Java applications, using Groovy. A former colleague did integrate a Groovy console to each of our applications, allowing to explore or patch a situation in production in mere minutes, should the situation require it).

What I miss

Interfaces as Contracts

I really like Java interfaces for using them as a “binding” contract. It means that I can express it in one single place, and have zero chance of forgetting to implement properly (as the compiler will check it). It beats any tentative to document, and is a simple and elegant mechanism that pushes me to really think about the objects responsibility, while being a safeguard at the same time.

Refactoring

You may argue that this is more a “tooling” point, but it is not: Java strong static type system may be the source for much of its verbosity, but it also allows the related tooling to do amazing things (especially since IntelliJ started the “refactor” operations).
Whether your IDE of choice implements them correctly or not is another problem: most of this kind of functionality will never be possible in a dynamically typed language (at least not with the same level of confidence).

Parameters types

While I like the idea of Duck Typing, I would appreciate to be able to optionally type my parameters. In Java, after the method name, it is probably the most efficient documentation that I know. I tend to create small classes for most of my needs, and as such, my methods definitions parameters really tell something. I know that some languages offer optional typing, would be interesting to try. As a result, I’m doubly attentive to my naming in Ruby, because it is the only visible aspect remaining.

Conclusion

Taking a look back as this list, I’m probably wishing for the best of the two worlds (and it is probably not possible). I found two great tools in Java and Ruby, and I intend to use them both when appropriate. I’m sure I’ll have occasions aplenty.





42 thoughts on “From Java to Ruby – what I love, what I miss

    1. Martin Post author

      I’m not sure you can really have the advantages of both static & dynamic languages without losing something in the middle. In other words, I do not think there is (or will be) one language to trump them all, I think it is more about the right tool for the right job (with some personnal preference on top of it).

      But I’ll get another look at Go (followed the news but never digged really deep there).

      Thanks for the input !

      Martin

      Reply
    2. Brundlefly

      @trung. Ha Ha Ha. Write a quick function to return the last element of a slice. Write a function that sorts a slice on an arbitrary class field. For that matter where the heck are field properties at all? I understand the designers attempt to simplify language syntax, but I don’t want to throw away half the advances and ease of features we’ve gotten in statically typed languages over the last 10+ years just because Go’s designers don’t personally like them.

      Reply
  1. Mark Burns

    I think things like named parameters and refactoring are probably just solved in different ways. I.e. more emphasis on tests, BDD/TDD in the community helping with the refactoring, and idiomatic ruby often has options parsing to do whatever type of validation you would like on the input, but again it would be covered by tests.

    You could argue an advantage of not having parameters types is that it doesn’t clutter the code unnecessarily. I.e. when you want to use them – maybe public API methods, you can do your validation and whatever checking you need, (also allowing you to think in more depth than just the type), and in your private methods or other simple methods you don’t have the overhead.

    Reply
    1. Martin Post author

      Mark,
      I think we agree on most points. You may not find an “equivalent” from one language to another, but you’ll find another way to solve the same problem (API brittleness in this case). On the parameter typing, it was the same reflexion that pushed me to say that I would like to have the option to use them, when appropriate.

      Thanks a lot for your input,

      Martin

      Reply
  2. Christian

    Take a look at Scala: you’ll get static typing, concise syntax, functional programming, something like mixins (traits) and even a statically typed way of duck-typing (you declare only the required method an object must have to be accepted as a parameter).

    Reply
    1. Martin Post author

      Christian,
      Honestly, I tried to (did read the pragmatic programmers book about Scala), and to this moment, it is a bit to weird for me. I’m not saying it is a bad language, I see very active and convinced proponent on the web, but for my (time-limited) investigation, it does not like to be a language for me.

      I would probably need to do another pass on it, but as usual, it is a question of priorities : there is so much to keep an eye on in the programming space.

      Thanks for pointing out the various points in the language, that give me a starting point to look at it.

      Martin

      Reply
    2. James

      Came in here to echo what others have said. I’ve seen your previous replies but it does sound like what you need is Scala. All the features of Ruby with better typing support (string interpolation coming in next version).

      Reply
  3. Alexander

    It seems like you are looking for Clojure. Give it a try. It fixes 2 out of 3 thing you miss while having everithing you like.

    Reply
    1. Martin Post author

      Hi Alexander,
      Go, Scala and now Clojure. Good thing I use ebooks, because this would become a weigthy bag of books. Joke apart, care to elaborate on the aspects that you find in Clojure to “solve” those kind of hassles ? What is the state of the Clojure “ecosystem” ? (I probably miss this point in the post, which is quite important – both Ruby & Java enjoy really healthy and broad ecosystems).

      Thanks,

      Martin

      Reply
  4. Rob K

    Hate to say it, but modern php supports all these features you just said you wanted, other than the interactive console. Modern php also has pretty damn amazing re-factoring tools in IDE’s like netbeans & phpstorm and many others.

    Older versions of PHP I would have to say I’m ashamed that I ever used at this point, but the more I use frameworks like Symfony 2 & Doctrine, Silex, Slim, and the like, the less i hate working with the language. I know that ruby & python have become these more “fad” languages to work with for web projects these days, but in the end, you work with what you are happy with. Take a moment to look into these frameworks and see what you can build, maybe it will offer some new insight into what you miss from java?

    Reply
    1. Martin Post author

      Rob,

      “Hate to say it, but modern php supports all these features you just said you wanted”

      Hate to read it too. But to acknowledge the positive sides of the tools you do not like is important (it is what keep our debates from being purely religous). I’m more used to the Ruby ecosystem, and it has grown a nice way those last years (lots of good quality librairies and frameworks). I could only suppose it is the same for PHP – which is exactly what you are confirming here.

      “but in the end, you work with what you are happy with.”

      I cannot agree more. Altough my first rule would be to use something adequate to the problem (or at least not wholly inadequate), this is certainly the second one. On of my reasons for using Ruby is that I really enjoy it. It is subjective but important nonetheless.

      Thanks for the “modern PHP” overview.

      Martin

      Reply
  5. Pingback: From Java to Ruby – what I love, what I miss | Development Topics | Scoop.it

  6. Pingback: In the News: 2012-07-09 | Klaus' Korner

  7. Michael Kimsal

    If you’re moving from Java, curious why not move to Groovy? Ruby’s cool, but I’d think you’d tick most of your boxes with Groovy while not having to give up the stuff you love about Java.

    Reply
    1. Martin Post author

      Hi Michael,
      That is probably where I lacked clarity in the post. I’ve a (mostly) Java background myself, but when we started 8thcolor, we decided to evaluate what looked like the best for our new company (and our product Sybil) in relative independance with our respective backgrounds (which are different anyway).

      For the record, I think that Groovy is a fine langage, and an excellent choice for any Java shop wanting to introduce some dynamic aspects without having to do a full technological revolution.

      Thanks for your contribution !

      Martin

      Reply
  8. AkitaOnRails

    Seems like you’re having a good time in the transition and it’s nice to see your positive view.

    On the points you miss let me add that very soon you will get used to not having static interfaces and thinking more about “Protocols”. At first it feels like you’re “missing” something, but later you will find that it makes your programming much more malleable.

    The same thing about refactoring. Exactly because you don’t have to define rigid interfaces and several layers of inheritance, implementing interfaces or abstract classes and abstracting the hell out of your classes – and then needing to refactor methods out from a subclass to a superclass, for example – you will do less and less “structural refactorings” and worry more about “behavioral refactorings”. I just invented those names, but I hope they are self-explanatory.

    Parameter Types is the same about the points above. You’re not comfortable not having static type checking, it feels fragile, it feels like you’re going to make simple mistakes. And again, it’s just a matter of getting comfortable. Soon you will start taking advantage of having dynamic parameters, replacing traditional parameters for “pseudo-named parameters” using Hashes and so on.

    Do more coding, experiment for a while doing lots of code, then come back and check out if you’re still feeling weird about these points. And while it’s the same old recommendation, learn your testing tools, they will be essential when you really need to refactor.

    Cheers

    Reply
    1. Martin Post author

      Akita,
      Thanks for the nice and elaborate comment. You’re right, I’m fully enjoying the transition, not because the grass in much greener here, just because being (or becoming) confident in two good and different platforms give you perspective.

      I think you nailed it : the programming’s (programmer’s ?) problems or challenges are the same whatever the language, but the answer need to be language specific. I think that being already more a “behavioral” java programmer (in your improvised and pertinent terminology) helped (I’ve fought inheritance abuse for years – but that is another story).

      I’ll quote you : it is all about getting used and confident in your tooling, and sharpen them until you are at ease.

      Martin

      Reply
  9. stéphan

    I think “your former colleague” should blog about the groovy console one day or another ;)

    Beyond choosing a language… you also picked up a platform.

    Choosing ruby and rails make your app production ready, most java web framework don’t think about http cache header, versioning, minifying js, gzip ,… If you rate your generated pages with ySlow there already AAA without any config or code change.

    As a javaist, what I really like is the tooling around Java. (build tool, code coverage with emma/jacoco, sonar for code inspection, profilers, MATdump analyzer, …)
    What is the situation in the ruby/rails world ?

    Reply
    1. Martin Post author

      Hi Stefan

      I think “your former colleague” should blog about the groovy console one day or another ;)

      Yes, you should. One million java applications (and their maintainers) would sigh in relief. Actually, you should also package it and publish it as a project on github.

      Beyond choosing a language… you also picked up a platform.

      This. It is what I spoke answering to Michael’s comment above. It was not just about a language, we had to pick a whole stack. And we like what Ruby and Rails have become : an opiniated but solid platform with the community and vibrant ecosystem you want when you start something.

      What is the situation in the ruby/rails world ?

      Good question about the tooling. I can answer for some of the points : testing frameworks and coverage are certainly there, build also (rake is mostly a nice internal DSL dedicated to build operations). Some attempts in quality inspection (flay, flog, reek and others), and at least some profiling tools, some shipped with Rails.

      Thanks a lot !

      Martin

      Reply
  10. Pingback: From Java to Ruby – what I love, what I miss » 8th color | Creativity as changing tool | Scoop.it

  11. Bruce

    1. Interface

    In Ruby, we use mix-in. You can use module as an interface :) and it does more than a pure interface.

    2. Refactor

    I never really rely on IDE to give refactoring, but there are some tools out there too.

    3. Static Type vs. Duck Typing?

    Long story. Many arguments. But once you get used to duck typing, it would be hard to go back to static. Now I am really struggling with Java Generics.

    Reply
    1. Martin Post author

      Bruce,
      Quick and “to the point”. I would like some more light on your points, still :
      1. Mix-in as interface : I really like Ruby’s Mix-in, but I’m not sure to see the “equivalence” between the two concepts. I agree that Mix-in can do more than an interfance (heck, you get the implementation for the same price), but what about situations where you want several classes to provide a functionality with the same API but different implementations ?

      2. Refactor : Any pointers on those tools ? Even if it is far less critical in Ruby, I always like to broaden my toolbelt.

      3. Typing : I agree with you on Java generics (actually, they are ok to use in their simplest form – to just type a collection especially in an API, and they become a real nightmare for anything beyond that).

      Martin

      Reply
  12. Kay

    Ruby to me has always seemed like an evolution of visual basic, in almost every sense. Despite some ‘usability’ additions, I’ve yet to see it overcome said bad genetics. Even if they aren’t iterative or related, they still share many of the same failings.

    You call it dynamic and intuitive, I call it arbitrary and unstructured. Difference of opinion, I think code should be as close to standardized mathematics as possible, it just fits better with the vast majority of people who write code and analytical thinking in general.

    Reply
    1. Martin Post author

      Kay,
      Ruby as en evolution of Visual Basic. Quite a statement.

      From the last part of your post, I understand that it is related to the less mathematical nature of Ruby. I would have one question and one comment : What are in this vision languages with “good” genetics ? I’ve some ideas, but would like to get yours. I do not see (for example) Java as being more “mathematically sound” than Ruby is.

      As for “mathematically languages” being a better fit to the “vast majority” of programmers, I would disagree (just looking at the popularity of languages such as Ruby, Pyton or JavaScript).

      Martin

      Reply
  13. Rob Grainger

    “most of this kind of functionality will never be possible in a dynamically typed language (at least not with the same level of confidence)”.

    Maybe you missed this, but Refactoring has been supported in dynamic languages much longer than static languages, witness the Smalltalk Refactoring Browser introduced in 1999. That along with Agile programming, and indeed OOP in general (except from Simula’s precursors) are some of the major innovations to come from Smalltalk.

    Reply
    1. Martin Post author

      Hello Rob,
      We are all in debt of Smalltalk, definitively. Any pointers to IDE still implementing this kind of rectoring on any of the dynamic language “en vogue” today ? (JS, Ruby, Pyton or others). I would be curious.

      Thanks,

      Martin

      Reply
    1. Martin Post author

      Joe,
      Short answer : at one moment, you need to narrow your choices, because you cannot make a real study of every framework out there. Especially as a startup. Django & Rails looked to be able to deliver what we wanted : fast development with very short code/test cycles for a “web facing on DB” application. This does not means that no other framework could. We just decided to focus on those two.

      Martin

      Reply
  14. Anonymous Coward

    Take a look at Scala and a better look at JavaScript. IMO they’re both nicer than both ruby and python. And strong typing is supposedly coming to JavaScript some time in the future.

    Scala can be as strongly typed as Java. Javascript (although it has its ugly parts) is a marvel of a language – once you get used to it, it’s IME the language easiest to use to express your intention. Both support function as a first class type.

    I absolutely don’t like python’s indent-based block delimitation, and Ruby’s pascal-like block delimitation is too verbose to my taste.

    I don’t really like Go either. I may be too much of an object junkie, but Go’s OO facilities are in no way matching my taste. In a weird way, Go’s support for OO reminds me of VB6 (can’t explain why).

    Reply
    1. Martin Post author

      Hello Anonymous,
      Damn, Scala again. For JavaScript, after having hated it with passion for some years, I may be putting some nuance in it. Still baffling to see the size of the “good parts”., but I start appreciating some aspects of it (once I got past the fact that everything is a hash, that’s it).

      Cannot speak about Go, no experience in it. Regarding Ruby, I would not call it “verbose”. I actually appreciate its terseness. Now, I’m coming from Java, so I may have a bad reference point.

      Thanks for your opinions !

      Martin

      Reply
  15. jD

    Hello Martin,

    I have a tremendous respect for Ruby, specially RoR because they shacked the enterprise Java world all the way to its foundation.

    Thank you to RoR we have the great concepts like DRY, Convention-over-configuration and scaffolding as part of our programming culture too.

    Kinda of slow -and not before many good developers left the Java ranks because of the frustration of that time.

    But, now we have Spring Roo . I believe it is the incarnation or RoR in Java plus much-much-much more.

    I would to invite you to visit my developer website. Which is btw 99.99% dedicated to Spring Roo.

    The link is shown below.

    Thank you
    jD @ http://pragmatikroo.blogspot.com/?view=timeslide

    Reply
    1. Martin Post author

      Hello jD,
      As an (not really) ex Java programmer, I have quite a lot of experience with Spring, and did venture in the Roo world some time. It is quite good, but I have the same itch about it than I have about gradle : I think that there is a (quite large) space for Java web application, without trying to emulate Rails in all possible aspects. I mean, if you want something that taste like Rails, looks like Rails, then why not just using it ? Except, again, if you are already heavily invested in the JVM, then it makes a lot of sense.

      What arguments did you found to use “Rails-like frameworks” and not Rails itself ?

      Martin

      Reply
  16. Jonathan O'Connor

    Martin,
    I too was an Eclipse fiend for many years, so I would recommend you get a copy of RubyMine from JetBrains. The latest version does have some refactoring ability, although not as much as Eclipse on Java. As for type safe programming, if you document your methods with Yard doc tags, then you can specify the types that each parameter and return value should give. RubyMine is clever enough to pick these up and use them in code completion. Here’s an example:

    # Some method does stuff
    # @param [String] s A String to be parsed
    # @returns [Numeric] Some description here
    def some_method(s)
    2
    end

    Reply
    1. Martin Post author

      Jonathan,
      Your the second to suggest to use the Yard doc tags, and I think I’ll definitively give them a try. Thanks for writing the small example, it made it much clearer to me.

      Martin

      Reply
  17. Mulasse

    “type parameters as documentation”.
    I strongly disagree. Parameter name is really, REALLY more reliable than type.
    Except case of hashes / array of parameters in Ruby, name is enough.

    What’s the difference between:

    - Person(String firstname, String lastname, String address, Date birthdate)
    - Person#new(firstname, lastname, address, birthdate)

    In second case (ruby), you get only the interesting part. With typeless parameters, you can either pass a date or a string or a numeric as birthdate without overloading 2 times your constructor as in Java.
    Especially when you know how boring is date instanciation and/or manipulation in Java.

    I could agree on the refactoring part. But no!
    Yes, without strong typing, you don’t have a compiler wich tells you “oh, the argument passed here is wrong”. But think:

    * compile time is long and 99% of the time wasted
    * it does not prevent from database refactoring (column name has changed ..) so you have 2 types of debugging
    * unit tests are here to cover failures from refactoring, both in java and ruby. You already rely on unit tests with java, because they guarantee business, and that’s what’s interesting for customer. Compiler does not interest no one, not even developer when they have learnt to work without.

    IDE (like rubymine) do great work to help you to refactor as clean as possible your code. It makes a better job than compiler. Unit tests are here, don’t bother with a third step that just make you lose time and nothing else.

    More, compiler won’t let you test code with is not completly “perfect”.
    I often try to use my ruby project while coding. As time I don’t hit a line with error, i can test “local” changes. You can’t do it with a compiler. You absolutely need to put that fucking comma to compile and test a line wich is at 10 kilometers from what you’re testing.

    So no, compiler does not make you save time.

    Welcome to you in Ruby and best regards =)

    Reply
  18. Mike

    Have you tried Haskell? It’s very expressive with (has map, filter, foldl…etc. high order functions) a supper strong type system (everything is checked on compile time) that doubles as documentation (just looking at function signiture one can have a good idea of what this function does), all functions in Haskell is pure so each function is very robust. If your doing web development you can try the Yesod web framework.

    Reply
    1. Martin Post author

      Hi Mike,
      Thanks for reviving the discussion here. Never tried Haskell – actually, never used a fully functional language, so the functional parts of Ruby are probably what I know best in this domain.

      We’ll probably not change the full stack for now anyway, but I’ll find some time to take a look to Haskell.

      Thanks!

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>