Why Idioms Are Bad

By Xah Lee. Date: . Last updated: .

Here is code in several languages. See if you can understand what they do and identify each language.

↓
↓
↓
↓
↓
↓
↓
↓
↓

↓
↓
↓
↓
↓
↓
↓
↓
↓

↓
↓
↓
↓
↓
↓
↓
↓
↓

↓
↓
↓
↓
↓
↓
↓
↓
↓

↓
↓
↓
↓
↓
↓
↓
↓
↓

↓
↓
↓
↓
↓
↓
↓
↓
↓

They are all doing floor(x/y).

In Common Lisp (floor (/ x y)) can be written as (floor x y). Because Common Lisp's “floor” function essentially acts as a integer quotient function. The second argument is optional, with default value of 1.

In Python 2, if x and y are integers, then x/y is the same as x//y, which returns the integer quotient. Note, the // is a unreadable syntax quirk.

In perl, you can do require POSIX; floor(x/y);. The “POSIX” instead of “Math” is a quirk. In any case, “floor” should really be builtin. Another way to do this in perl is int(x/y).

All of the above are quirks. They rely on computer engineering by-products (such as “int”), or rely on the lang's idiosyncrasy. One easy way to judge it is whether a programer can read and understand a program without having to spend a lot time to delve into its tricks. Problem with these lang idioms is that it's harder to understand, and whatever advantage/optimization they provide is microscopic and temporary.

Best is really floor(x/y).

Idiomatic programing is a bad thing. It was spread by perl in the 1990s. Idiomatic languages, i.e. lang with huge number of idioms, such as perl, is the worst language.

Thanks to Zach Beane, Kaz Kylheku, for the tip on Common Lisp's “floor”.

See also: [Programming Languages Have Social Mores Not Idioms By Zed A Shaw. At http://learncodethehardway.org/blog/AUG_19_2012.html]

When Are Idioms Important

basically, the only “idiom” that should matter are those that affects algorithmic complexity. For example, in a programing language where strings are immutable, and you need to append to string ten thousand times, you should use a array and append to array instead, then convert array to string.

[see Python: Append String in Loop]

vast majority of idioms insisted by hackers, are stylistic or formatting concerns. These are harmful because:

Examples formatting-aware syntax are {XML, LISP, APL, Mathematica, Python}, to different degrees. For examples, see:

For example of syntax that are not formatting aware or screwups, see:

what does it mean to say a language's syntax is formatting-aware?

it means, the characters or syntax in the language indicates to some degree the semantic unit of the code.

For example, in lisp, the parenthesis characters ( ) serves a expression marker, and lisp syntax is almost just parenthesis. This means, lisp code can be automatically pretty-printed. [see Fundamental Problems of Lisp]

in C syntax languages such as Java, the curly brackets { } and the semi-colon ; are such characters. The curly brackets mark a semantic unit (to some degree). The semicolon indicates a end of a code unit. However, C syntax isn't formatting aware because it is a syntax soup.

Here is a different example. In XML, the syntax has the form <x>…</x> and <y … />. This is formatting aware, because that form is a semantic unit, and the whole XML syntax is basically these 2 forms. (it has exceptions. See: Syntax Design Problem: Irregularity vs Convenience)

Here are examples when fully formatting-aware syntax (For example, lisp) and automatical formatting is fully realized:

Note: Mathematica is a language with regular syntax, and automatic formatting, even for complex rendered 2D math expressions. Mathematica achieves this because its syntax is fully regular, and each symbol (or tokens) has context-free unique meaning.

Mathematica example here:

Programing Idioms and Style