Tuesday, November 06, 2007

Explicit! (vs Implicit, of course)

Boring coding article.

I'll skip the long backstory. Basically, I've recently started thinking about implicit vs explicit languages.

As you know, Bob, an implicit language lets you do more with less, but makes it difficult to stray from the well-worn path. An explicit language is the opposite, allowing you to do precisely what you want to do, but requiring more. More code, more skill, more mental RAM.

I've worked with the source of a lot of products in my life, and I have developed a healthy distaste for explicit coding. To me, it smacks of selfishness: a coder programming something using more because it is more comfortable for him, screw anyone who might have to use his code base later. Selfish coding.

As long as I have the source (and I always have the source), I DON'T find implicit languages to be especially confusing or surprising as to what they do. There are occasional exceptions, such as Ruby on Rails' ever-indecipherable pluralization rules. But I have a much harder time parsing and remembering the added arguments and lines of an explicit language.

Also, I find that if you build towards implicitness, you build very tightly architectured code. I don't have to wonder whether the "takedamage" function is part of the ship class, ship interface, cship class, c_ship class, c_hull class, c_base_object class, or what. I don't have to wonder why sometimes you're passing a weapon, other times a struct, sometimes a damage class, sometimes a raw number, sometimes an enum... I find that explicit coders will tend to spread this kind of function out among half a dozen more-or-less related classes, and that really pisses me off. (That's a real example, sirs and madams.)

The funny thing is that most programming paradigms (like Object Oriented Programming) are attempts to build an implicit language out of an explicit language. You build chunks of code that you call and they IMPLICITLY do stuff. You're functionally building your own dialect of whatever with every program you write. But nobody seems to think like this.

They should, because people like me have to live with your choices, and if you try to be as implicit as possible, we'll be able to understand your program in half an hour instead of half a month.

So, that's my coding article of the month.

2 comments:

Olick said...

Wait. So people sometimes DON'T use object oriented programming in order to create easy to read and use code?

I think, though, that in many cases there is a lot of swap between implicit and explicit languages. For example it is wholly possible to build towards implicitness in an explicit language. Conversely, you may override ANYTHING in Ruby, and therefore may be as explicit as you wish at any time.

I'm just starting out in the industry, and already I have read code that makes me want to cry. Learning arguments and lines is not as big of an offender as having to track down massive indirection. Files calling other files calling scripts which proxy other scripts...

Craig Perko said...

Yeah, 'sall about the architecture. Or lack thereof.