New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.

Posted by David Black on May 14, 2007

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.
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.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
No comments
Watch Thread Reply