Goodbye Ruby Tuesday
During the Front Royal Agile Fusion workshop I attended last week, we were programming in the Ruby programming language. I didn't know Ruby before going there, and it's probably the first time in five years that I haven't mostly been using Java (I've done a bit of Java native code using C and C++, but I was specifically writing the C/C++ to be called from Java).
I've come to the conclusion that Ruby is a toy language.
Part of me worries about making that conclusion after only five days of using the language. I've always seen the resistence to new things as a sign of codger-hood. How many times have I argued with people who told me that COBOL was just fine, thank you? Or that one didn't really need IDEs.
Most programming languages, however, aren't very original. They have different syntax for much the same concepts. I generally believe that there are a few styles of languages:
- Assembly
- Procedural
- Object-oriented
- Rules-based
- 4th Generation
Exceptions that I can think of include APL (which has fundamentally different looping constructs) and, I believe, LISP (although I haven't personally used LISP). 4th Generation Languages (4GL) failed. Nobody talks about them any more, really. Assembly is only used for performance-critical stuff. Rules-based languages haven't won many converts. I don't know enough about these so-called Aspect-based languages to decide whether or not they are a different style.
Most new development is done in an object-oriented language. Most of the concepts of OO languages are very similar. So what does Ruby offer over Smalltalk, or Java? I think C++ is unnecessarily complicated because it carries the baggage of C, and also because it never bothered to define a standard class library (well, in time for any serious exploitation of the class library) so I can't recommend it.
Brian Marick said, on day one, that Ruby was easier than Java (which reminds me of a number of discussions that I've had about Python). So after two days, I noticed that Ruby doesn't have a standard web component API. Every Java project that I've been on would have assumed that Servlets/JSPs is the right technology (or might have thought about Servlets with XML/XSLT), and would have used a standard servlet engine like Tomcat. I found myself having the "should we use CGI or not?" conversation for the first time in five years. I could scarcely hide my annoyance.
I feel, a lot, like people who make these arguments (language X is easier than Java) are comparing the number of keystrokes one has to type. And, sure, that relates to a whole 'nuther problem of comprehensability and maintainability. But I want to have a different conversation. The conversation about... <BC makes vague hand-waving motions>... component maturity or something.
The questions I'm interested in are:
- What is the enterprise component model?
- How do I achieve run-time plugablity?
- What tools are available to help me be more productive?
- How do I version my components?
Perhaps, in short, the question I wonder is: what is the difference between a language and a platform? One could argue, for example, that Zope is the beginnings of a platform for Python, but it's weak on services ("Distributed transactions? Why would anyone want that?"). Java operates in a space that's really only inhabited by one major competitor: .NET. And I think that too many developers don't understand what it is about these technologies that make them so different. In their haste to poo-poo Microsoft, too many developers haven't bothered to learn why COM is so revolutionary.
Ruby doesn't play in that space. I don't think that Python plays in that space, either.
I haven't figured out the nomenclature to describe the space. What is the attribute of Java that makes it so different? How do I name that attribute? Help! I'm fumbling for langauge! But not the Ruby language.
no subject
I hear: "Blah, blah blah, blah-blah, stuff."
Sorry I can't help. Nice weather, though, hey? :)
no subject
no subject
I understand what you're saying, and I think that it's what I would simply call maturity. This isn't a matter of age, only. It's a matter of the amount of (quality) effort put into developing the product. A niche language used by a few people for twenty years can still be immature because there has been very little effort put into it relative to a popular language, simply because fewer people are contributing to that. A larger number of quality people working with or on a language for a longer period of time will tend to solve more problems, iron out more details, come up with more standard methods and generally create more of the things that cause you to have to do less work and spend less time inventing (or reinventing) the wheel.
On the other hand, many people like to be pioneers and use tools that feel newer. Also, newer tools will often have been built on a more current basic design. I don't know if that's the case here or not. The analogy I could draw would be to operating systems. BeOS, for example, was exciting for a lot of people when it came out, and people labelled it "easier to program for" and "more powerful / efficient". However, they were talking about it providing some basic powerful concepts. In actuality it was harder to program anything truly significant on because it was so immature that there were few existing solutions to build on.
Which is the whole point of objected oriented design, really. OO itself doesn't really start getting useful until there's a decent amount of basic fodder out there to work with -- until there's a reasonable likelihood that for any project you undertake there will be pre-existing objects that you can leverage for your design.
So I guess I'm proposing 'maturity' for your term. I don't know if it fits or not.