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.
We are developing an Automated code reviews for Ruby developers using Github, discover how you can become a better Ruby developer.
Check out Golang. It’s the best of both world. :)
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
@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.
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.
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
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).
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
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).
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.
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
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?
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
Pingback: From Java to Ruby – what I love, what I miss | Development Topics | Scoop.it
Pingback: In the News: 2012-07-09 | Klaus' Korner
Groovy 2.0 was released recently and it supports most of the good things you like from Ruby. but also added static compilation and type checking when you need them.
http://groovy.codehaus.org/
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.
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
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
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
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 ?
Hi Stefan
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.
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.
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
Pingback: From Java to Ruby – what I love, what I miss » 8th color | Creativity as changing tool | Scoop.it
I think you’re looking for Scala. :-)
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.
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
Java generics are garbage. They’re literally compiler shorthand for casting.
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.
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
“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.
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
Why was the choice between Python/Django and Ruby/Rails only? What about say Java/JSF?
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
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).
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
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
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
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
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
“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 =)
i really like that you are giving information on core and advance java concepts. Being enrolled at http://www.wiziq.com/course/1779-core-and-advance-java-concepts i found your information very helpful indeed.thanks for it.