Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community

Posted by David Black on May 14, 2007 02:05 AM

I'm just starting out with Ruby, and I think it's really great. There are a couple of things I'm not sure about, though. I come from C, so I was surprised to see that zero is true. Wouldn't it be easier for C and Perl programmers if zero were false?or this:
Coming from C++, I consider static typing very helpful. Are there any plans to add it to Ruby?or even advice like this:
Ruby lets you use under_score or camelCase for variable names, so just use whatever you used in the language you come from.I'm probably giving a skewed view of the use of "come from" in so many words. But the gist was always the same: Ruby didn't count, so everything had to be expressed in terms of other languages. There were C and Perl programmers, but not Ruby programmers (or if there were Ruby programmers, Ruby's feature set should have been less about them and more about the C and Perl programmers). Dynamic typing could stay or go, depending on how people who used languages other than Ruby felt about it. And there was no need to respect Ruby's stylistic traditions - in fact, Ruby wasn't a real language so it couldn't have traditions - so just airlift some conventions in from another language.
This kind of thing went on for a long time. (It still goes on, but there's less of it and there are more people who see how misguided it is. So I'll speak of it in the past, at least to paint with broad strokes.) It was weird. Weird on the merits, and weird to be on the receiving end, as a Ruby programmer, because it made one feel invisible.
Agile Development: A Manager's Roadmap for Success
Give-away eBook – Confessions of an IT Manager
The Agile Business Analyst: Skills and Techniques needed for Agile
Effective Management of Static Analysis Vulnerabilities and Defects
The concept of "coming from" a language, I believe, served as an anchor for a lot of these questions and suggestions. It was as if the very fact that Person A had used Language X for N years somehow incurred an obligation on Ruby's part to emulate Language X. Leaving aside the slighting of Ruby (which I believe was largely unconscious, though extensive) - and leaving aside, too, the feature soup that would result if all of these requests for change were honored - putting that much stock in which language you "come from" just doesn't make sense.
Consider this scenario:
You "come from" C. So you think that having zero be false is "intuitive," and that zero should be false in Ruby. However, you grudgingly accept that it isn't, and you get on with programming in Ruby.
A few years later, you're very comfortable with Ruby, and you decide to try another language - perhaps Perl. Now, when you start using Perl, you "come from" Ruby. So you expect zero to be true. So Perl is doing it wrong.
In other words, you're always one language out of step. And only one language at a time can be correctly designed! You're always homesick, and never enjoy your travels.
That can't be right.
Mind you, I'm not saying that Ruby exists, or ever existed, in isolation from other languages. Far from it: Ruby has borrowed a lot of features, and wears its heredity on its sleeve. Ruby's creator, Yukihiro "Matz" Matsumoto, is extremely knowledgeable and incredibly good at putting his knowledge to use in the language-design process. So the Ruby world is always abuzz with talk about how various bits of Ruby relate to bits of other languages.
Still, Ruby is anything but a feature-pastiche. It's got a style and design signature all its own. Matz takes the greatest care with design and feature decisions. After you've heard Matz discuss how he thinks about these things, all the more do you realize that "to make C++ programmers feel more at home" just isn't in the ballpark.
Nor do I mean to suggest that Ruby shouldn't change. In fact, Ruby is still in development. Matz has always encouraged and welcomed suggestions for changes to Ruby. Topics related to feature addition and change often dominate the mailing lists. So it's not that anyone wants or expects Ruby not to change. It's more a matter of where the change, or the suggestions for change, comes from. If someone feels that having zero be false would make Ruby better, for some reason other than that it would make Ruby feel more like one or more languages that aren't Ruby, then by all means let's hear it.
It's time to be allowed to come from Ruby. And that does not mean doing unto other languages what's been done unto Ruby. Believe me, I will never write to the mailing list of any language requesting that something be changed in the language so that Ruby programmers will feel more at home. (I might be tempted to... but I won't.) It means according Ruby full, first-class citizen rights in the programming-language world, and enough already with the implied asterisk next to its name.
So if you come to Ruby, stay for a while - and if you stay long enough, feel free to come from Ruby. You won't regret it!
David A. Black is a long-time Ruby and Rails programmer, author, and trainer. Active in the Ruby world since 2000, David is the author of Ruby for Rails: Ruby Techniques for Rails Developers (Manning Publications, 2006) and the PDF Short Cut Rails Routing Roundup (Addison-Wesley, forthcoming, 2007).
David is the owner and director of the Ruby/Rails consultancy Ruby Power and Light, LLC (http://www.rubypal.com), and a co-director of Ruby Central, Inc., parent organization of the annual RubyConf and RailsConf events (http://www.rubycentral.org). In his Ruby Central role he has co-organized Ruby and Rails conferences, including the annual RubyConf, RailsConf, and RailsConf Europe, since 2001, and has served as administrator for the Ruby Central Regional Conference Grant Program and Ruby Central's participation in the Google Summer of Code.
David is the chief author of Ruby's standard scanf library, and the author and maintainer of the official Ruby Change Request site.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply