Ruby at Code Camp
by James Britt
I'll be offering an introduction to Ruby . I've given Ruby intro talks before, and quickly decided that there was little point in giving a rundown of syntax, semantics, and bulleted lists of features.
Nor was there real value in emphasizing how Ruby compares to one or another language.
It's not that these things are aren't important, they're just not the best topics to cover in a one-hour talk. If you are presenting to a group of geeks, they'll generally believe you if you assure them that, much like other languages, Ruby lets you add numbers, manipulate strings, write to files, and handle myriad other fundamental programming tasks. Now, anyone who decides to go use Ruby will of course have to learn the little details, but they don't need them in next 60 minutes. What they need is a reason to go learn them once you've stopped talking.
Similarly, knowing how Ruby compares to say, Java or PHP, may be important to a Java or PHP coder looking to give Ruby a shot, but the things that make Ruby most interesting won't be grasped from a PowerPoint chart. Simply asserting things doesn't cut it.
So, rather than trying to explain a bunch of abstractions, I prefer to show code. Build an app, go over what what the options are as the code grows, show how Ruby makes it easy to go from simple procedural scripts, to well-order classes and objects, to domain-specific abstractions that enable natural expression of application logic. If all goes well, I'll be able to walk through the design and coding of a simple but useful Web tool that just so happens to make use of blocks, iterators, classes, modules, unit testing, duck typing, method_missing, dynamic class loading, and runtime method creation; all the little things that make Ruby both fun and productive.
I don't expect people to remember the details, but that isn't the goal. What I'm aiming for is interest, excitement, and the motivation to go learn more. I don't care so much that a single person remembers one line of code; the code and slides are going to be available on-line anyway. But if one or two people leave the room thinking, "Wow, Ruby looks really sweet," and go grab some tutorials off ruby-doc or hop down to the nearest B&N to buy the Pickaxe, then that's a big win. These people will take the time needed to learn some proper Ruby, get hooked, and then go pester their friends and coworkers about Ruby's coolness. Mission accomplished.
At the same time, though, I now make a point of avoiding any explicit Ruby advocacy. Sure, if someone asks, "Should I use Ruby?", I'll say Yes, but it's rarely that simple. The question more typically comes framed in some larger description of a complex project, or wrapped in a (not always) subtle challenge to "prove" how Ruby is so much better then @some_language at @some_task.
It's not that I don't think these sorts of arguments can be made (though the devil is in the details), it's just that I'm usually not the guy to make them. Truth is, while I try to keep on top of all ways Ruby can be used for a growing variety of software tasks, I'm generally not interested in tracking the details for any length of time. My brain is too small; I'm much more suited to knowing where to find information should I need it (and, hopefully, recognizing when I need it) than storing stuff in cache memory. I've made enough critical evaluations regarding Ruby for the common tasks I face, found Ruby eminently suitable for what I need, and simple see no value in persuading arbitrary strangers that I've made the right choice.
Fact is, I really don't care whether or not you think my language is cooler than your language. I have my gripes with Java, PHP, and, well, every language I've used, but getting into some schoolyard pissing contest (and there will be people looking for just that sort of thing) over LOC or configuration files or scalability or which language is more agiley is remarkably unrewarding. "Does Ruby scale?" Scales for me. "Is is more expressive than Blub?" It's expressive enough for me. "Why should I pick Ruby over [Python|Perl|Java]?" I have no idea. I picked Ruby.
I'd be remiss if I didn't provide, as part of my final slides and code, references for people who want actual details on those areas, but I can't think of a more persuasive tool for Ruby advocacy than simple showing off Ruby itself and getting out of the way.
|I'm also due to give a presentation in 3 weeks time and I was asking myself many of the same questions, so I am very curious to see what you will come up with. Let us know where you will post the presentation when you are done!|
> Let us know where you will post the presentation when you are done!
|All very true. I used VB6 for the longest time (for work, mainly), but what drew me to Ruby was the Rails framework and knowing that I could quickly produce things of value with the language. It was less of a question of scalability or popularity or whose people are cooler, but more of a question of "can I translate my thoughts to a product more quickly than if I used _____". I think if you do exactly what you say and provide them a start to finish application covering the major points, that will accomplish exactly what you want and the ruby community needs. It's the newness and excitement that draws us to something different, not the benchmarks and empty rhetoric.|