A third way

Programming is about translating what a human wants into instructions a computer can understand.

Or is it?

Thinking down this path, there are two ends of a programming language spectrum. A language can be close to the computer’s perspective: imperative languages that declare data, move and store data, carry out instructions in a fixed order. At the other end, spoken languages aren’t specific enough to convey instructions to a computer.

But there’s more to this concept than one dimension! The key is: speak not to the human, nor to the computer, but to the problem we’re solving. The appropriate abstractions, and therefore elegance and simplicity and productivity, lie in the language of the problem.

Some problems are well-suited to an imperative language, some to an object-oriented one. Others to neither. The key is to fit the language to the problem, not the programmer and not the computer. Every problem has its conceptual sweet spot.

Aim for a declarative style: state the solution rather than a series of instructions.

For instance, functional languages speak not in instruction sets, not in English, but in calculations. People naturally think in a more imperative manner, and computers operate with defined instructions and changing the contents of memory. But when we’re calculating an output from some input, a functional language is more effective at stating the solution than either computer or human language.

Why do we care about this problem space? “Calculations” include more than math. Any translation fits: reporting from a database; taking a URL plus request parameters and outputting HTML. This sweet spot is relevant to all web programming and a big chunk of business software.

Coding in a third language space means we need translations in two places. The computer must be taught to understand instructions in this different form. That’s the job of a compiler. The human must learn to write code in a shape unfamiliar to his or her brain. That’s our job as developers.

Don’t think like a computer. Think about the problem you’re solving. Think and write in its language, not yours and not the hardware’s.