Ah, another day of RubyConf has passed. Here’s a brief overview of the talks I attended and my thoughts on them. The theme for today was definitely Threading and Concurrency. And the conclusion in many (if not all) of the cases was: Ruby sucks at it, how can we make it better? I hope that Matz, et al takes these issues to heart and prioritizes some improvements in this area. Native threads are a start, but the GIL kills us. We need more!
Aristotle and the Art of Software Development – Jonathan Dahl
What a way to start the morning! Jonathan gave an overview of several great philosophers and how to apply their ideals to programming. He likened Perl, Java, and PHP to the school of Utilitarianism, where the ends justify the (very) nasty means of getting there. His basic theme throughout the presentation was that hard rules (from any school of thought) must be tempered with common sense. He gave the example of DRY versus clean & understandable code in ‘database.yml’. While the clean version has a lot of redundancy in the settings, DRYing it makes it impossible to read. Overall, a great way to start the morning.
Ruby Arduino Development – Greg Borenstein
I caught a Ruby electronics talk last year that was pretty cool, and got an even better one this year! Greg presented a number of cool arduino projects, including drumming with servos, a temperature reader using a big red arrow on a servo, and a drink mixer that could make screwdrivers using windshield washer pumps! It was a terrific overview of RAD and I can’t wait to buy an Arduino when I get home.
Better Ruby through Functional Programming – Dean Wampler
Dean did a nice talk about using functional paradigms in Ruby. He gave examples of makign sure your functions don’t modify state, pattern matching, using functions as first class objects, etc. He gave a good comparison that showed that DSLs are very similar to functional languages because they are very declarative instead of imperative. What I think he missed is that, under the hood, DSLs are very state-heavy in order to implement that declarative model. It was great to delve into these ideas, but I was left feeling that if you go through the trouble of following functional programming in Ruby, you don’t really get any benefits. Ruby isn’t optimized for concurrency like Erlang or Haskel and your code will really just be more difficult to trace. Maybe I’m missing something, but I didn’t see the benefits (except making it easier to switch to a functional language).
What Every Rubyist Should Known About Threads – Jim Weirich
When I see Jim’s name on a talk, it is guaranteed I will attend. I don’t care about the subject. Jim is an amazing speaker with always interesting topics. He gave a fairly basic overview of concurrency and why we need it (the failure of Moore’s law). For Java programmers and the ilk, this would be concurrency 101, but probably had some new information for a lot of Ruby developers. He provided some great code-heavy examples of race conditions and deadlock and how to work around them. He also hammered home his message of ‘Concurrency is HARD’, but it must be done. However, I felt there was a kind of elephant in the room with the fact that concurrency in Ruby is rather fruitless, thanks to green threads, GIL, etc. Jim did, however, give some great examples of ways to make it easier: Erlang & Clojure.
Using Metrics to Take a Hard Look at Your Code – Jake Scruggs
Jake gave a terrific presentation on how use metrics appropriately to help improve and maintain your code. He talked about code coverage, testing, Flog, Saikuro, and more. Jake also had a great example of applying these tools to target improvements with a real-life example of refactoring a Dameau-Levenshtein distance function. He also had great example of how inject has a tendency to muddy your code significantly, increase complexity, and decrease understandability, a sentiment I whole heartedly agree with. Best of all, Jake introduced Metric-Fu: http://github.com/jscruggs/metric_fu . Metric-Fu combines, code coverage, flog, saikuro, and more into an easy to use interface that integrates with CC.rb. Looks awesome and I’ll be trying it out soon!
Components are not a Dirty Word – Mike Pence & Nick Sutterer
One of the few Rails talks at the conference (as it should be). Mike introduced us briefly to ‘Cells’, a new type of Component more similar to what Merb has now. The Nick came up to demo Apotomo, a plugin that provides wholey-contained stateful widgets. These widgets are persistant and handle updating their own appearance. They also have event triggers, observers, and caching. I will definitely be giving Apotomo a try, at least to play with, although it may not be ready for production use yet.
Ruby Kata and Sparring – Micah Martin
Micah talked about his experiences with martial arts and how it can be applied to programming. His message was “To be a master, you must use disciplined practice outside of work”. This is the purpose of Kata, or Forms. He gave many reasons for a similar approach in development: peer feedback, definite goals, performance, etc. He even performed a Kata of developing Langton’s Ant right on stage. The best part was his introduction of a new tournament: battleship. All Ruby developers are invited to participate by building a battleship AI. The tourney info is available at: http://sparring.rubyforge.org/battleship/ . Awesome indeed, you can be sure I’ll participate.
Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it – Ilya Grigorik
Ilya gave a great talk on how to break down a task into something where you can use multiple processes. This is the good stuff. Forget threads and concurrency problems. If you truly isolate the tasks (share-nothing? hello?), you begin to produce a system that can massively scale very easily. He demonstrated using his real-world example of scaling AideRSS.com. They split off the different tasks: network-bound, IO-bound, CPU-bound. The different processes communicate with message and job queues (he mentioned starling, beanstalked, and SQS) and they used EventMachine to prevent blocking-IO. In the end, they could load each EC2 instance with basically one task of each: saturating network, IO, and CPU simultaneously to get the best bang for the dollar. Overall, the talk was great, but I may be biased since I feel it basically validated all my experience and convictions about the RIGHT way to scale.
Keynote – Dave Thomas
To round out the evening was Dave with a literally breathtaking talk. He gave an example of Ruby’s biggest problem (at least I think so): slow development. Ruby had 48 months between 1.6 and 1.8 and it’s already been 52 months waiting for 1.9. (I guess Matz has really taken to heart his goal of being ‘enterprisey’) This causes INCREDIBLE problems for migrating to a new version, not to mention learning or using the new features. It also leads to slower adoption, wheich means less usage of the new version, which makes even LONGER releases. Dave’s solution is to Fork Ruby. He proposed four forks, all VERY good ideas.
RubyLite – A version of Ruby where we strip out a lot of the unnessessary stuff. Dave projects Ruby’s codebase to be 100MB when 2.0 is finally release (in 2011!). Pulling out a ton of unneeded syntax, libraries, and redundant methods could significantly improve size and performance. I’m all in!!
Parallel Ruby – Dave proposes a ruby that will automatically parallelize certain operations. A new operator: //= would perform something similiar to: a,b=b,a using passed procs simultaneously. Basically distributed map automatically. Awesome idea. Have no clue where to begin with this one though.
Typed Ruby – Ruby with typing. Charles Nutter has been workign on something very very similar to this with Duby. Cool idea, but I love duck-typing too much.
Closure-based Ruby – Dave offers a new syntax for hashes that will free up braces (not a bad idea, if there’s an =>, you already know it’s a hash, the braces aren’t really needed, just like with implicit arrays right now). The braces can be used to element all the Lambda, proc, Proc.new, block madness. Make ONE first-class proc object, that can be passed and used all over the place. A GREAT idea!!! I think he took it a little far when he suggests making class and method definitions using it. The code at the very end looked like Lisp with braces all over the place, you couldn’t tell what was what. But otherwise, I whole-heartedly support a simplified proc system in Ruby.
Dave closed by saying that he hopes that he inspired us to go out and impliment these ideas, or any others we may come up with. Try out new things and maybe they’ll get merged into MRI. I sure hope RubyLite and the closure system Dave proposed eventually get taken into MRI. I may even take a crack at implementing them myself!