As discussed, I’m going through the 7 Languages in 7 Weeks (7L7W) book. The first week was about Ruby. I went through the content and examples and now feel I have at least a basic understanding of the language, it’s strengths and it’s weaknesses.
Strong-typing and static-typing:
First, I’m coming from a statically-typed world. Also, and I’ve said this many times (and you can quote me):
“Incorrect assumptions are at the root of all software bugs.” –Robert Seder
I have found this to be true probably 99%+ of the time. So, because of that, in my professional opinion, the more explicit you can be, the better. Have fewer assumptions. Have the compiler enforce as much as possible, instead of your users finding bugs at run-time. These are the time-tested lessons of our professional!
Coming from that viewpoint which is reinforced almost daily, I don’t see much upside to this late-binding, dynamic-typing, duck-typing world that is the trend at the moment. I see of course the quick time-to-market, but it’s at the expense of assumptions and implicit coding. There’s another word for what that produces: technical debt – and didn’t we, as a professional already learn this lesson once?
Using duck and dynamic typing in production:
It’s almost like MS Access programming has become a big trend, but it’s a bad idea! The worst-case-scenario is that you actually write something useful that people want to use. It’s bad because you just wrote that useful application in a technology that likely won’t scale well, and it’s filled with assumptions and implied typing! I mean, I get it, it’s a paradox. People like the loose languages because you can crank out something quickly – but when you end up with a working, useful app – it’s written in a loose language that is very problematic! So – when do you trade convenience and speed for scalability and the survivability of the app?
Needless to say, I’m not sold at all on duck-typing or even dynamic-typing. In fact, in my professional opinion, dynamic and duck typing have no place in any production code (for any process that is critical to the business). It’s a hack, it’s lazy, and it encourages the developer to be lazy – and only bad things can come about from that!
Ruby Advantages and Disadvantages:
Despite that, Ruby definitely has some upsides. It’s great for scripting – if you need to munge through some data as part of a script or batch job, this would be a good fit. Ruby is very much like a Python/BASIC type language, which is very verbose and English-based, makes it easy and somewhat intuitive to learn too. It has some cool features like being able to dynamically generate other programming objects, by writing code (meta-programming). It’s also pretty clever how they solved the “multiple inheritance” paradox – by having Modules,which allow classes to share functionality.
I have not seen Ruby on Rails (the MVC web app platform), nor have I found an IDE that supports intellisense for the language, so I can’t speak to that. I don’t know how easy this would be to work with day-in and day-out, without a good IDE. The book says there isn’t really a good Ruby IDE.
However, just on what I’ve see so far, if I needed to chop up some data – Ruby is in the same category for me as Python, they would both be easy languages to do something like that. If I needed a script or a batch job, either would be a good choice.
Lastly, as the book points out, Ruby does have some performance problems and it doesn’t support concurrency (in this world of multi-core processors!).
Onward and upward – the next (2nd) language is “Io”…