Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Public Council Teleconference: Application Rationalization — Hidden Costs and Smart Decisions
November 17 at 11:00 am US/Eastern (GMT-5)
Join Honorio Padrón, of The Hackett Group, who will share the drivers for companies to tackle application rationalization and the results of research that define the hidden cost of complexity. Additionally, we will discuss key decision milestones—to start or not, holding the course steady and fulfilling expectations.
Virtual Desktop Cost-Benefit Analysis — Michael Jacobs, Catlin Group
The analysis contained in this presentation measures the cost of everything from the machines and licenses to the infrastructure for virtual vs. traditional desktop environments.
Honor your best senior team members - Apply for the CIO Ones to Watch Award
Get well-earned public recognition for your top up-and-coming team members, your IT organization and your enterprise. Award winners will be announced, publicized and feted in May 2010, great timing to help attract new IT recruits to your company.
Learn more about the CIO Executive Council »March 01, 2008 — CIO —
Ask any programmer what his favorite language is good for and he'll yell, "Everything!" At least until his next favorite language comes along, which is also good for everything. The truth is: Any language that's Turing Complete and supports enough language features can solve any problem. The difference between languages and their usefulness is a matter of degrees of "yak shaving."
"Yak shaving" is a programmer's slang term for the distance between a task's start and completion and the tangential tasks between you and the solution. If you ever wanted to mail a letter, but couldn't find a stamp, and had to drive your car to get the stamp, but also needed to refill the tank with gas, which then let you get to the post office where you could buy a stamp to mail your letter—then you've done some yak shaving.
Some programming languages and some platforms (I'll make the distinction in a bit) minimize yak shaving. To create a simple language in Ruby, I have to find multiple undocumented libraries, install byzantine dependencies, track down build errors, find conflicts in things called "hoe" (which needs rubyforge which needs rake which needs Ruby), verify which version of Ruby I'm using, or try the undocumented lex and yacc integration, find out about Coco/R or other projects, install multiple non-Ruby packages, have the right libraries (again), talk with various people in IRC who don't want to talk to me—and then, after a few weeks, I might have just the harness done. Conversely, using ANTLR, without much fuss I can prototype an entire new language in a weekend and deploy it to just about any computer. It's not completely effortless; I can usually create a small parser for a protocol or mini-language in about a day or two using ANTLR and one book by Terrence Parr.
It's this distance between problem and solution that makes one language more suitable than another for a given task.
Aside: Sure, for the ultrageek in us, these yak-shaving expeditions can be fun, depending on the platform. I personally wouldn't do anything more complex than ant build on Java, but on Factor, Lua, Python or Ruby I'd gladly spend a weekend hacking at something just to prove I could do it (or to use it for something especially nerd powerful).
However, the platform is not the language. A programming language can be divorced from the physical computer it runs on. You can run multiple languages on virtual machines, such as the Sun Java Virtual Machine (JVM), Microsoft Common Language Runtime (CLR), NekoVM and LLVM; you can even host Forth in JavaScript in a browser. The separation of the language used to describe computation from the actual computational device means that programmers can choose various languages for a task, yet IT management can keep deployment platforms standardized and cohesive.
Why is this relevant to Ruby? Recently, there's been a huge push to take Ruby onto both the JVM and the CLR systems. Ruby's popularity means that companies like Sun, IBM and Microsoft want to add the language (and others, such as Python) to their platforms. This keeps programmers writing code for the vendors' platforms and keeps computers in the data center running their (expensive) software. Based on the adoption of Ruby on Rails I've seen for internal projects in 2008, this is a smart move.
In Ruby's case, the ability to host on multiple platforms means that whatever C, Java or C# can do, Ruby can do as well. The same advantage applies to Groovy, Boo, Python, Scala and JavaScript. What is left is a matter of style and reducing the number of yaks in the field you have to shave to get the job done.