Programing: Why Idiomatic Programing Are Bad

, , …,

Here's constructions in several languages. See if you can understand what they do and identify each language.

(floor x y)
require POSIX; floor(x/y);

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. (see spec: Source

The (floor x y) is not a good lang design, more of a lang quirk.

Similarly, in Python 2.x, x/y will work when both x and y are integers. Also, x//y works too, but that // is a unreadable syntax quirk.

Similarly, 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 measure 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, of course, in the 1990s. Idiomatic languages, i.e. lang with huge number of idioms, such as perl, is the worst.

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

For actual code of these langs using floor(a/b) doing something useful, see: In-place Algorithm for Reversing a List in Perl, Python, Lisp, Mathematica.

See also: 〔Programming Languages Have Social Mores Not Idioms By Zed A Shaw. @

What Idioms Should Matter?

basically, the only “idiom” that should matter are those that affects algorithmic complexity. The best example of this is a Python idiom: Python: a Technique to Append String in a Loop.

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

• Most of the time, it doesn't matter. In real-world code, majority of real-world code are not in pretty idioms, or, the code need attention in aspects that are far more important than idioms.

• Idioms, especially those relying on rare language feature, makes it hard to understand and port. What you think is so superb when you are hot with the language, but in a few years, it's a puzzle.

• style/formatting idioms are the most worthless. We should have automatic formatting tools and format-aware syntax instead. Mantra of style/formatting idioms suppress awareness of these issues. For example, variable naming convention. It should be built into the language syntax whenever possible.

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. (but, unfortunately, lispers are not aware of this idea) 〔➤ 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's 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: Programing Language Design: Syntax Sugar Problem: Irregularity vs Convenience)

Here are examples when fully formatting-aware syntax (⁖ 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 syntax StandardForm screenshot
Mathematica automatically rendering code into 2D display.

Mathematica example here: