Pragmatic vs. Dogmatic Languages

So, my earlier post about Ruby has sparked some comments by Glenn Vanderburg. Glenn was standing next to Dave Thomas during that "hard sell" of Ruby, then proceeded to demo Seaside (a continuations-based Smalltalk web framework) during the drive back to the airport (I only got a small peek because I was driving; Erik Hatcher was the main audience).

Glenn appreciated the fact that the update-copyrights.rb script I wrote, shabby as it is, is a Ruby script, and not Java code in Ruby syntax. In other words, I did my best to use Ruby-isms, including a little duck typing, blocks and iterators, and so forth. We're both disappointed I didn't write tests for the script.

This gave rise to some interesting email discussions, the most productive part of which was some new terminology (that I hope I did not subconsciously steal from someone):

• Pragmatic vs. Dogmatic Everyone gets hung up on types, dynamic vs. static, scripting vs. everything-else. I'd rather use "pragmatic" for non-type-encumbered languages (Ruby, Perl, Python, JavaScript) and "dogmatic" for Java, C#, COBOL ... everything that forces structure down your throat.

  In Java 1.5 terms, I like auto-boxing, but generic types are abominable! It makes the code much harder to read and the only gain is a minimal amount of compile-time type safety -- that isn't really safe. Dogma. Apparently, the dogma at Sun is "Java code that performs no casts must not ever throw a ClassCastException". So much for Dave Thomas' (and others') idea that the Java compiler should just quietly inject the necessary cast for you (based on all the other type information available) ... instead we have the syntax from hell.

• lovely spareness is what I like in Ruby, maybe Python ... what I miss from Objective-C. You get a lot done in very little code and the code is readable. It's the aesthetic of Ruby and it's admirable.

These terms, and the concepts behind them, resonate with me. Looking at how both Tapestry and HiveMind have been evolving, it is much the same: less dogma (well, beyond "services must have interfaces!"), and much more spare XML, with the frameworks doing a better job figuring things out from defaults. Ruby is full of this same "less is more" philosophy, which is why people get passionate about it.

My last big change of language was from Objective-C on NextStep. The transition from Objective-C to Java was initially very painful ... so much of Java seemed unnecessarily baroque. And a couple of key features I pined for were missing. In fact, those features have only shown up more recently as Java Aspects ... and as Ruby Mixins. Aspects make my eyes hurt; Mixins are minimal, and powerful. Ruby is something like coming home again to Objective-C.

Ruby won't be my primary tool for a while (if ever), but it's definitely something I want to keep in my toolbox, ready to go.