Chad Perrin: SOB

31 August 2006

the role of OOP for programming instruction

Filed under: Cognition,Geek — apotheon @ 04:16

There’s quite a bit of discussion floating around on the Web about what makes one programming language “better” than another, both in general and in specific cases. While much of that is dependent on circumstances, personal preferences, and assumptions about the sort of tasks you wish to complete, some of it is fairly universal. There are precious few, for instance, who would say that GWBASIC is a better language than Ruby. There are fewer still who would say Brainfuck or Whitespace is better than both. On the other hand, as a joke language, Whitespace is hard to beat.

Personal preferences make a difference in how easy it is to learn a given language but, again, there are some generalities that can be made. It’s generally easier to learn to program via Perl than, for instance, C++. There are some specific, somewhat measurable characteristics of languages that contribute to this. I would suggest that a language that aims to be easy to learn as a first language should include the following characteristics:

  • not much of the syntax need be known to be able to write code
  • not much of the syntax need be known to be able to read code
  • unknown syntax is very easy to look up
  • semantic structure lends itself to thinking about program architecture
  • language lends itself to succinct code
  • syntax is easy on the eyes
  • programs with errors should fail in a verbose and helpful manner

I intentionally avoided social aspects of programming languages, focusing instead on the technical design characteristics of the language.

A language like Ruby or Python is among the easiest on the eyes (generally — my personal preferences make Python very hard on my eyes in particular), as contrasted with some other languages (many will think of Perl here, but it’s not all that bad — better than Lisp, I would think). It’s incredibly easy to look up unknown syntax in both Perl and Ruby, both of which are also very helpful and verbose when a program errors out. It’s unlikely that I’ll surprise anyone by mentioning that Ruby and Python kick Perl’s ass in terms of being able to read code without having to know much of the syntax, though Perl makes up for it somewhat by being one of the best languages in the world for looking up unknown syntactic elements. Python is reasonably good at making it possible to write useful programs without knowing too much of the language’s syntax — marginally better than Ruby, in fact, which might surprise some people who know how much I like Ruby in general and detest Python. PHP is generally better at being writeable without knowing much syntax than either Python or Ruby, largely because its core syntax could probably be written on a thumbnail by an enterprising cheater on a college exam that has very neat handwriting. Perhaps surprisingly, I think Perl is actually just about as easy as PHP for a newbie to start using without knowing much syntax — it’s absurdly easy to start with a tiny subset of the language while writing useful programs. In fact, I think it’s easier than PHP in this respect, one of the easiest languages out there in this regard, though Lisp dialects are clear winners over even Perl.

It was the realization, earlier today, of the relative difficulty of writing useful Ruby without knowing much syntax that struck me as odd. I think it is better than C++ or Java in this respect, but it is still surprisingly more difficult than I would have expected. The major win is not in needing very little of the syntax, but in the fact that the syntax is easy to use once learned, and in the fact that it is easier to guess valid syntax than in many other languages.

I was considering how it stacks up to Perl and Lisp on this matter, as I spoke with Sterling. While Perl itself is dead easy to use with very little volume of knowledge of its syntax, and Lisp even easier, both languages by contrast require a hell of a lot more knowledge of syntax to be able to use their object systems. I thought about this in relation to what makes Ruby sort of a “loser” in this regard, and realized that it is, in essence, the object orientedness of the language that forces a heavy necessary syntax knowledge overhead on the newbie programmer.

Once I start separating things into categories by object orientation, Ruby starts to look a lot better on this easiness of learning metric: compared to other object systems, Ruby’s does not require a very heavy syntax knowledge overhead for writing useful programs. While Perl itself is easier to learn in this respect than Ruby, Perl’s object system is more difficult to learn by this measure than Ruby’s. In comparison with other object oriented languages then, Ruby is a net winner (though, as Sterling pointed out, whether it is a .NET winner is still up for debate), as is Python (for very different reasons).

I don’t really know, off the top of my head, how this helps us in determining how to teach programming to people (even if those people are ourselves), or just to teach new programming languages to people who already know how to program. It may be something worth considering the next time you decide to start designing a new language, though. I think it’s an important consideration, even if I’m not entirely sure of how it can be translated into concrete benefit. Something it suggests to me, however, is that the Logo advocates were probably right to choose it as the first instructional language to introduce to children, and those who advocate object oriented Visual Basic should probably be drug out in the street and shot (not that I wasn’t already leaning in that direction in the first place).

At this point in the evolving history of programming, on the other hand, OOP is something that is very important to learn if you’re serious about programming. In that regard, then, Ruby is one of the best languages available for teaching object oriented programming. If you believe that OOP should be taught first, maybe Logo isn’t the way to go.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License