I used to be very much a “C” guy. After learning BASIC and Pascal in my early teens, I cut my chops on C and – despite a few struggles – fell in love with it. The language felt right; it was close to the metal, but far enough away that programming it it could be pleasant. It helped me truly build a model of computation in my head which I think has served me well.

After getting into the web industry, however, I began to leave C behind. I coded in it less and less, since the industry outside of J2EE pretty much runs on dynamic languages (at that time, Perl – now PHP, ASP, Python, etc.). These languages always felt a little messy to me; I didn’t know what was really going on at the metal any more, like it felt like I did with C. Automatic memory management felt like a black box, and it always seemed I couldn’t optimize my data structures except at the algorithm level. And even then, who knew what the GC was doing in the background.

Over time, however, I came to embrace them – even to the point of spending a good deal of my free time playing in Lisp, Scheme, and SmallTalk. With processing power and memory becoming cheaper and cheaper, it was less necessary to worry about the overhead in dynamic languages, at least for my purposes. They tend to run plenty fast enough for web applications (where most performance problems are I/O- or DB-bound), and if they don’t then there’s always caching or throwing more hardware at the problem. If you know what you’re doing, the medium lends itself to the dynamic language programming style very well. It’s a common joke that PHP’s memory leaks don’t matter if a page request only lasts a second, and it’s basically true; who cares about optimizing a process that works to your needs? Reach the equilibrium between programmer time and project requirements, then move on to the next thing.

My old self would scoff at that attitude. It seems lazy, and it is. It still makes me uncomfortable. But it’s the way the web industry is built; the seat-of-the-pants, fly-by-night, hack-it-till-you-make-it attitude.

Where I’d Like To Go

However, I’ve got a bit of a problem. A long-time goal of mine has been to get into the PC game industry, ever since I wrote my first “Hello, World” in BASIC when I was 12. A kid getting into programming to write games is almost cliche, but it’s true; there are few teenagers that dream about writing database software or eCommerce sites. When we grow up our tastes often change, but sometimes they don’t. Case in point: after a decade in the web industry, I still want to work on real, wide-release, 3d games for a living.

There’s a small problem with moving to the game industry after the web industry, however. The programming culture is almost entirely different. The dynamic languages that I’ve mostly been immersed in at work – except for C# – are relegated to scripting in the game industry. Real developer positions, for the foreseeable future, have one almost ubiquitous language: C++.

That’s changing, somewhat, of course. Some development houses I understand are moving to C#, especially Xbox developers. Microsoft is pushing XNA, which runs on .NET. Then there are other enterprising folks who refuse to conform. But for most places, C++ still seems to be the language of choice for PC games.

So, basically, I made a choice. A while ago, I started sharpening my C++ skills again.

The Long Road Ahead

Now, in the hierarchy of languages that I enjoy coding in, C++ ranks somewhere above COBOL but below Logo; it is a complicated beast of a thing, with so many gotchas and corner cases that I’m sure it would make a Pharisee sweat. I actually derive real pleasure from the rantings of Yossi Kreinin in his C++ FQA Lite; even when I think he’s being somewhat unfair to the C++ FAQ authors, and even when I disagree with him on substantive issues, he still usually has interesting criticisms.

So, if I am so critical of C++, why am I studying it? Very simply – because C++ is still the industry language for game development. This is true just as much for historical reasons as it is for practical ones; arguably, there are better languages than C++ at the same level, without turning to dynamic or managed languages. But industry standard is industry standard, and until that tide turns, those of us who’d like to work with that industry have to tag along.

Now, I consider myself fairly proficient with C++ for someone who hasn’t shipped anything in it (it’s not exactly number one in my current field). I have most of the important bits of the language in my head, and I’m aware of things like RAII and how to implement patterns, etc. I’ve read Scott Meyer’s two books (though I haven’t fully internalized it all), and I’ve even built stuff in the language.

That said, it easily takes me up to two to ten times longer to implement and debug C++ code than in a dynamic language like Ruby or Lisp, depending on the complexity. Part of that is, of course, the language (and implementations) – no lexical closures (yet), no first-class functions (yet) (function pointers don’t count), no multiple dispatch (if you’ve never used it, it is unbelievably useful), gratuitous overloading of C keywords (like “static”), no standard ABI, private variables stored in header files (I understand why, and it can be avoided with pimpl, but it still bothers me), cryptic error messages (especially for templates, but other times as well), slow compilation…I can go on. One of the more irritating things is the default copy-constructors, and these days I just throw boost::noncopyable onto my classes unless I know consumers will need it (which is less often than you may think).

C++0x has some improvements. For example, I can’t wait for type inference; if the compiler can figure out what type I want, then why should I spell it out every time (though there are some limitations¹)? Even better, we’re going to have real lambdas and closures! But who knows how long it’ll take to implement – we’re still waiting for C99. Hopefully we’ll at least get early uptake of the most important features. TR1 is already available for VC9.

Qiān Lǐ Zhī Háng, Shǐ Yú Zú Xià²

I still have a ways to go. I’m in the playing around with various projects in C++, trying to be idiomatic rather than cute or clever. At the same time, I’m going through Sutter’s Exceptional C++ and C++ Coding Standards, internalizing good habits. It’s a little tough returning to the world of static typing, (semi-)manual memory management, and complex builds after such a long hiatus, but it’s worth the rewards. A longtime dream realized—becoming a real game developer.

I welcome the challenge.

This should be interesting. Before encountering (Smalltalk-inspired) Objective-C a few years ago and then (also Smalltalk-inspired) Ruby, my primary experience with OOP had been C++ and Java – both of which had left a rather sour taste in my mouth. Sure, I could see a few advantages, but they didn’t seem worth it – and now I realize why. Most development in those languages is really OINO – OOP In Name Only. People actually program procedurally, and create just as much (sometimes more!) spaghetti code as in traditional procedural languages!

One thing about Smalltalk that I think encourages “true” OOP development is the way that the development environment works. In C++ and Java, the file and class are the units of account – but in Smalltalk, all you see is one method at a time. I think this is an important observation; it actually encourages the developer to think more granularly, developing smaller and more targeted methods. Methods are visually separated from the class definition from each other – even instance and class methods are completely visually separated. My hypothesis is that this has a valuable psychological impact on design.

Interestingly, though, Ruby and Python developers still seem to do this. Perhaps not with the tenacity that Smalltalk programmers seem to, but I don’t seem to find ridiculously long procedures-masquerading-as-methods in their applications as often. Maybe it’s because of the nature of the communities, or maybe I just don’t have a large enough sampling of code. In any case, it’s an observation.

So, we’ll see how I do with this little project. I don’t imagine it should be too terribly difficult – the problem seems easily solved, at least from a distance. But now my first decision – how do I store puzzles?

This may not be as trivial as it sounds. The old-style Perl programmer in me wants to store it as a packed string. The C programmer wants a multi-dimensional array. The Lisper wants perhaps an array, perhaps a list of lists. But what’s the Smalltalk Way? A multi-dimensional array of “Cell” objects?

Rails Philosophy

So, the primary Rails philosophy is “Convention over Configuration”. This is the biggest selling point for any domain-specific application framework, to me – how much boiler-plate do I have to write before I can start mucking with actual logic? Some of the nicest parts of Rails are the things that it Just Does out of the box. Database access and abstraction, file structure organization, standards for separation of concerns and unit tests – all of these normal tasks that affect every web application are taken care of for you ahead of time. That is a remarkably powerful tool.

Of course, this alone is nothing unique or original with Rails. One of the things I liked the most about the Fusebox framework for ColdFusion was that it provides several of these abstractions out of the box. Now, Fusebox isn’t nearly as complex of a framework as Rails – it doesn’t begin to approach things like ORM, pluggable modules, AJAX support, etc. Even its handling of templates is pretty rudimentary by comparison. But it does have “opinions” about software development, and those made it a joy to architect in versus something like raw ColdFusion, PHP, or ASP.

A Java Interlude

Compare this with “Hello World” in J2EE. Look at the steps involved for a “typical distributed J2EE application”:

1. Create the EJB project and the HelloWorldEntity container-managed entity bean (CMP)
2. Create the EJB to RDB mapping using Cloudscape for the HelloWorldEntity CMP
3. Create a HelloWorldSession stateless session bean
4. Generate WebSphere deployed code
5. Create a server project
6. Binding the datasource to the HelloWorldEntity CMP
7. Create a data source and Cloudscape database tables
8. Creating a Java application client project and implementation
9. Create the Web project and a simple Java bean to read and write properties
10. Create the HelloWorldServlet servlet
11. Create the HTML home page
12. Create the JSP for final presentation to the user
13. Create a reference to the EJB session bean
14. Run the full application on the server

Does this really provide so much more than Rails and its ilk to be worth it? I’m not seeing it.

While J2EE certainly has some conventions, they are at a very low level of abstraction. This may provide flexibility for producing any sort of application you want. But at the same time, that much time spent writing boiler-plate in every app has to be a pain. I will admit that I am no expert in J2EE (I’ve never written anything serious in it), so if this is an unfair characterization, let me know. But it seems to me that any J2EE web application would take at least twice as long to write as a simple scripting language like PHP, and probably an order of magnitude longer to write than something in Rails or Django. Even with static typing, code generators, and IntelliJ, there seems that so much complexity can only complicate matters and ultimately introduce errors (or bad practices) in all but the most careful teams.

But enough dumping on Java. The truth is, as a language, I like it better than a lot of others. And I have a lot of respect for Guy Steele when he writes:

“And you’re right: we were not out to win over the Lisp programmers;
we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?”

But at least from afar, the whole Java web application world seems ridiculous.

Back to Rails

Another thing I like about Rails is the Ruby language itself. It definitely has the feel of a Smalltalk-Lisp-Perl hybrid – with its emphasis on “everything-is-an-object” and blocks, combined with a seat-of-your-pants, “static typing? what’s that?” scripting language feel. Look at some of these little snippets:

Using ActiveSupport’s Symbol#to_proc:

[1, 2, 3].map(&:to_s) #=> ["1", "2", "3"]

Array shuffling:

class Array
  def shuffle
    n = []
    while !empty?
      n << delete_at(rand(size))
    end
    n
  end
end
 
# Usage
[1,2,3,4,5].shuffle #=> [2, 4, 5, 1, 3]

MethodFinder, in particular, kind of blew me away:

irb> MethodFinder.show( "hello", 5 )
"hello".length == 5
"hello".size == 5
=> ["length", "size"]
 
irb> MethodFinder.show( "foo", "foobar", "bar" )
"foo".<<("bar") == "foobar"
"foo".concat("bar") == "foobar"
"foo".+("bar") == "foobar"
=> ["<<", "concat", "+"]
irb> MethodFinder.show( 3.14159, 3 )
3.14159.round == 3
3.14159.truncate == 3
3.14159.to_i == 3
3.14159.prec_i == 3
3.14159.floor == 3
3.14159.to_int == 3
=> ["round", "truncate", "to_i", "prec_i", "floor", "to_int"]

(though of course, this could be extremely dangerous in the wrong hands)

(HT: Coda Hale, Concentration Studios, and Andrew Birkett)

Clearly, Ruby has inherited much of the power of its Smalltalk heritage. When developer coding time is a priority, anonymous message passing with a method_missing handler is a Good Thing.

In general, dynamic, weakly typed languages – with all of their drawbacks – have always been my favorite coding environment. I’ve rarely felt too much enforcement of type safety to be worth the costs, though trust me that I do understand the reasons for it. It is rare that I find an object’s type to be ambiguous outside of classic ASP.

Conclusions

Though I’ve been playing with Rails on the side for a few months, I’m really only just getting my feet wet. I’m sure that there are aspects of the framework which will put me off; its Unicode support is poor (though that has gotten better in 1.2), raw performance is very poor (fingers crossed that a VM will be completed sooner rather than later), and DHH will probably continue to attempt to push away the enterprise market. But at the same time, I’m looking forward to getting my hands dirty in what is really still a very new framework, despite being over two years old. Thinking about architecture with the new CRUD features and ActiveResource alone should keep my mind occupied in between SICP and Latin.