News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Two Views of Ruby, in Plain Language


It Isn’t All a Gem



September 1, 2006 — 
Several months ago in this column, I pointed to Ruby as a dynamic language worthy of thoughtful consideration for scripting, even for developing entire applications. While my affection for the language remains high, I am concerned about the rampant hyping I keep reading regarding Ruby. Like any language, Ruby has weaknesses that any developer (especially non-Java developers) will quickly recognize. Here are the salient ones.

Long Learning Curve. Many articles talk about the ease of learning Ruby and provide examples of its greater concision when compared with Java. (See Maik Schmidt’s Guest View, “Dynamic Ruby Gets Ready for the Enterprise,” July 1, page 34, for an example.) Let’s be accurate here: Almost any language except COBOL will be more concise than Java, but concision does not make it easy to learn or use. In fact, Ruby is dependent on tricks used in Perl, such as specially named variables that are not intuitive, to provide shortcuts and concision. This design has been widely condemned in Perl because it sacrifices readability. The same applies to Ruby. (Consider these four predefined—and unrelated—variables: $! $-0 $0 and $_ .)

Ruby also uses techniques that derive from printf-style codes. The String unpack command provides 37 format codes for different ways of extracting data from a string. There are 22 codes for booleans regarding a file status. And because most of these codes are used in Ruby, they have to be memorized. Is the code ?S clearer than an API call to test whether a file is a socket? It’s more concise, but hardly clearer. To be proficient at Ruby—even to read it easily—you need to memorize these hard-coded syntactical features of the language. Java, C++ and Python, by comparison, require far less rote memorization to learn the language.

The learning curve is hampered by the absence of good tutorials. The bible of Ruby developers is “Programming Ruby” from the Pragmatic Programmers (Dave Thomas and Andy Hunt). It’s a decent reference work for the language and the APIs, but insufficient as a tutorial. It lacks the steady development of code of increasing complexity to bring the reader along from simple to large complex applications. It is nothing like the terrific tutorials by the same authors on other programming topics. Moreover, there are few alternate resources, although several books are finally on the way.

Slow Execution. Ruby is translated; there is no concept of VMs. As a result, performance is distinctly sluggish. Oddly enough, this lack of translation to an efficient binary format is touted as an advantage by many evangelists because skipping the compilation step is perceived as such a timesaver. This either/or view reflects a lack of knowledge of alternatives. Dynamic languages today can be both interpreted and compiled. For example, Groovy and NetRexx are two languages that can be run interpretively from the command line or compiled to Java bytecodes. The benefit of the latter option is the ability to leverage the years of work that have gone into optimizing JVM performance—something Ruby desperately needs. JRuby, the effort to have Ruby run on the JVM (in the manner of Jython), is one possible solution. However, that project is moving along slowly and has garnered surprisingly little support from the larger Ruby community.

Lack of Tools. Few tools today support Ruby development, and those that do aren’t terribly impressive. The principal commercial IDE, ActiveState Komodo 3.5, barely functions well enough to use. It hangs frequently and has limited syntactical support for the language. Remaining dev tools are equally immature. So, developers accustomed to the robust development environments for Java, C/C++ and C# will suddenly find themselves using tools from 10 years ago. Expect to use a plain editor for development and to rely on printf-style dumps of variables for debugging. Fortunately, a tracing facility is built into the language.

Ruby enthusiasts talk about how the language puts fun back into programming. Personally, I think this is true of any scripting language, except maybe Perl. Writing shorter programs that can do a lot is always a pleasure. Ruby on Rails (RoR), the Web framework that runs on Ruby, adds to this pleasure by its truly elegant, intuitive design. More than features of the language per se, RoR is the real reason to adopt Ruby. It has led to a remarkably active community, which gives Ruby additional appeal. Posts to mailing lists are answered quickly and with very little flaming for even obvious errors. However, don’t expect a panacea in Ruby, but a language with its own strengths and weaknesses and an acute need for better tools and better performance.

Andrew Binstock is the principal analyst at Pacific Data Works.


Share this link: http://www.sdtimes.com/link/29506
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading