Does code become better as it approaches English?

Achieving readability and expressiveness by writing English-like code is one of the trends on the rise in today’s industry. This is particularly true for DSL and BDD communities, but many developers working in Java, C# or Ruby also try to make their code look as close to English as possible.

In his article “The Narrative Urge”, Michael Feathers challenges the idea that “code becomes better as it approaches English”. Expressiveness and readability help improving maintainability and bridging the gap between programmers and business, as it was highlighted by Martin Fowler and Neal Ford in their presentation about DSLs. Michael Feathers does not question that fact. He emphasizes, however, that “natural language should not be the only direction we explore when we look for expressivity”.

One should not neglect the fact that there are different ways of understanding the text. Feathers compares narrative and symbolic modes:

In the narrative mode, we are approach text like prose and read through it the way we would read through English or any other natural language - it tickles the verbal centers of our brain. The symbolic mode is more visual.

Hence, expressiveness can also be yielded by the symbolic approach and Feathers argues that in some circumstances it may be more appropriate than the English-esque one. He outlines a number of trade-offs that might impact the choice between these approaches.

Feathers considers narrative mode to be more appropriate for user facing tools rather than for “code written by and for developers”. More importantly, however, the choice depends on the domain specificities. First of all, according to Feathers, it may depend on how “settled definitions and nomenclature” even though criteria are not that clear:

On the one hand, if you are working in a domain like dates or scientific units, with settled definitions and nomenclature, it can pay to use a natural language style in your API. When definitions are settled, there is less of a chance that the machinery of a DSL will have to be refactored as much over time. On the other hand, once definitions are settled and well understood, you can eliminate a lot of cruft by moving toward a symbolic approach.

Feathers also highlights that in some domains, it is not easy to give a verbal expression for a task. In this case, symbolic alternative can “make code comprehension a breeze” being “more precise than what we are used to with natural language”. Feathers further develops this idea in his other post about trade-offs of narrative vs. symbolic programming . He gives the example of the symbolic approach in an embedded DSL for music composition:

funkGroove

        = let p1 = perc LowTom qn

              p2 = perc AcousticSnare en

          in Tempo 3 (Instr Percussion (cut 8 (repeatM

                  ((p1 :+: qnr :+: p2 :+: qnr :+: p2 :+:

                    p1 :+: p1 :+: qnr :+: p2 :+: enr)

                   :=: roll en (perc ClosedHiHat 2))

             )))

According to Feathers, the symbolic mode works well for this specific domain because “people don't talk about how one note follows another as much as they listen for notes or see them on a page.” More generally speaking, he argues that the symbolic approach is more appropriate for programs that are about structure rather than about semantics for which narrative mode more suited.  

Hence, a certain number of elements should be taken into consideration before chosing English-like code as a means for improving readability and expressiveness. What does your experience tell about the expressive power of symbolic approach and different trade-offs presented by Michael Feathers?