Idioms and the One True Way
Posted: 4 years ago (2007-11-08 22:34:34 UTC ) / Updated: 2 years ago (2009-06-01 22:28:45 UTC )
Imported from WordPress
Originally posted on 2007-11-08 22:34:34
Programmers, as they use a programming language, fall into sets of idioms. Think of every C or C++ style guide you've read, whether at a job or for some other project. Each of these is a particular set of idioms, a possible One True Way. The Linux Kernel has a very specific look to it. Ruby has some pretty specific recommendations, if you look. Even in languages where bad style is the norm, there are significant attempts to standardize and make things legible.
A style guide isn't an absolute, even among people who feel strongly. If you look through the Linux Kernel code, it's not a 100% match for the style guide, but more importantly there are a lot of idioms that you don't see in style guides. Conversely, there are particular ways that everybody creates a for() loop in C. One may quibble about details of the placement of things, but that basic structuring, indenting and formatting of it (give or take a newline and curly-brace) is remarkably identical in all experienced C programmers.
A style guide is only that -- a guide -- because it's really a proxy for a set of priorities. A good style guide will choose its recommendations to accomplish specific goals. For instance, good indentation and brace style make the code more readable, add necessary whitespace for legibility, and make it clear where blocks start and end. Well-chosen variable names make it clear what components of the program are doing. Restrictions on function length make sure that a function can be comprehended by a single programmer of reasonable ability in a reasonable period of time. Different style guides make different recommendations, partly because different groups and different programmers have different priorities. You may find a programmer who 'grew up' on Turbo Pascal and a 25-row fixed-resolution text screen expects a different function length and different indentation style than another programmer who started his work with Java and Eclipse on a 1600x1200 LCD panel.
Other parts of a style guide, and other idioms, protect programmers from misuse of the language -- for some definition of 'misuse'. For instance, nonportable C++ features may be forbidden, or error-prone parts of a language like C's "goto" statement. C++'s templates may be disallowed, particularly for a group that cares strongly about code size. An embedded platform may forbid the use of malloc() in interrupt handlers because it can take a long time for unpredictable reasons.
When I'm learning a new language, the first thing I like to look for is unique language idioms. What do they do differently in this language? Sometimes new idioms are because of the structure or capabilities of the language, but sometimes it's just that people have a blank slate, a new chance to try a new way of coding something. Either way, a new idiom is a new way of thinking of a chunk of code, and that can be very powerful.
For instance, Standard ML and SML/NJ were my introduction to the idea of higher-order functions, things like map() and reduce(). While SML allowed imperative programming, it lends itself strongly function programming -- to passing all data around by function parameters (input) and return values (output) rather than assigning anything to variables. While most modern languages can use the functional programming paradigm, few programmers do so in, say, C++ or Java. It's an example of a specific set of idioms that can turn out to be astounding useful, as Google has proven with mapreduce.
It's common for a language to have a powerful new set of idioms even when all the components were already present in earlier languages. Perl certainly didn't invent regular expressions (regexps), but its combination of easy regexp syntax with reasonable access to 'real' programming features meant that Perl users got far more power out of them than was common. You could do the same thing with awk or bash, various Unix utilities and patience. But the Perl language, and the Perl idioms that went with it, made regular expressions far more powerful, for a far broader group of users, than ever before.
This is one reason I'm so interested in Ruby's metaprogramming. It's not completely new, because you can do the same things with 'eval' in most dynamic languages. Adding new types at runtime isn't a completely new trick. But Ruby carefully makes it easy to do so. And while such languages features are never trivial to use, as LISP macros demonstrate, Ruby gives a cleaner, simpler implementation than I've seen so far. I'm paying attention because, like object-oriented programming, functional programming and aspect-oriented programming, it has the look of a very useful new "One True Way".
Maybe some day it'll even be written into a style guide :-)