|
Working with Ruby
Barry: How is Ruby as a general purpose language?
Neal: It's great, but you can build a domain-specific language on Ruby. Ruby is so nice for domain-specific languages is because Ruby it has a very terse syntax, and it's very flexible (in a way that Java is not). Ruby is well suited for DSLs, but it's not the only language that's well suited. Lisp and Smalltalk are often cited as languages on which you can easily build DSLs. Ruby just happens to be the language everyone is using now.
Justin: To be honest, Ruby is benefiting so much from the Rails hype. Without Rails, we would still be talking more about Python for domain-specific languages. Stuart has a vested interest in Python because he does a lot of work on the Mac, and there's a native bridge from Python to Objective C (the language of choice on the Mac). Python has lots of great features, but Ruby is a little more powerful than Python. Python people may come after me with sticks and forks for having said that. But the power of Ruby is largely riding the coattails of Rails. Rails is one of those truly disruptive technologies that carries its underlying platform along with it, as opposed to the other way around.
Neal: That's what the Web API did for Java.
Stuart: In my daily life at Near-Time, I work with server-side technologies as well as client-side technologies. I work with some junior developers, so picking between these technology stacks is an important issue. We at Near-Time were initially very enthusiastic about Python, because of its advantages on the client-side for the Mac. We were looking at the skill sets of a fast moving, agile team. Learning two extra languages (Python and Ruby) wouldn't be as good as learning only one extra language (Python). So if the Python stack is comparable to the Ruby stack, we should just go with Python.
But before diving into some server-side projects, we took a deep breath. Java re-entered through the back door, because of the availability of Java libraries for all the ancillary technologies. We started asking ourselves if we have to incorporate a rules engine into this application, or if we have to do some pretty heavy XPath/XQuery things. That stuff exists in the Python and Ruby stacks, but we're likely to find Java solutions more quickly. While dynamic languages like Python and Ruby have some compelling advantages, there are certain problem domains where I need ancillary technologies. Perhaps I need a container with specific features. Java is still very much in the hunt, even for very light-weight agile things.
BB: Sure, Java has been around longer. But that's a political reason for adopting Java. It's not a technological reason.
Justin: I don't agree. On a consulting project, I was involved in a possible movement from Spring/Hibernate to Ruby on Rails. I posted some statistics about the performance and argued that Rails had a lot going for it. It became a big online discussion. I asked everyone what it would take to make Rails a reasonable choice on a small enterprise side. What if we start to bridge, not just the small Web app, but move up into the larger enterprise app? The answer was that we need some sort of messaging support. We also need a security model, better XML support, a better WSDL stack if I'm going to do Web services. The libraries are more mature on the Java side because people have been pounding away at them. It's not that people can't develop these technologies in Ruby, and maybe even faster than they could in Java. But developing technology is one thing and making the technology mature is another. Communities that are emerging around the dynamic languages will take longer to become stable.
Now, it's not to say I would choose Java over Ruby on Rails or Python just because Java has more mature libraries. But it is definitely a point in Java's favor. And if you have to do messaging, there is nothing you can do outside of Java that's nearly as robust. That's a huge win for Java and it's not just political. It's also technological.
Of course David Heinemeier Hansson (of Rails fame) says that the maturity scale for software has been compressed or condensed now with these more dynamic languages. You can get to maturity faster. It's not a fixed linear time frame. Even so, Java is currently much more mature.
Neal: People always seem to be looking for prescriptive, one-size-fits-all solutions. But that's naïve in this day and age, when you have so many useful choices. Some tools are better suited to some jobs than other tools.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
