Does code become better as it approaches English?

Posted by Sadek Drobi on Jan 18, 2008 11:50 AM

Community

Architecture

Topics

Domain Specific Languages,

Design,

Programming

Tags

Business Natural Languages

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?

---

Related news:  "Literate Testing" for Readable JUnit Tests

 

1. Back to top

   For some apps, a more narrative approach works well

   Jan 18, 2008 1:09 PM by Jeff Haynie

   When I designed Appcelerator's "Web Expression Language" I wanted some much more narrative and readable. Something that you could look at and understand what it does without having to mentally decode it. It's not a pure language like a C++ but it's nonetheless a language and we wanted something that was easy to comprehend and fast to understand. You can see and play with the simplicity of the syntax at http://try.appcelerator.org Computers are much smarter than humans and anything we can do to increase productivity of applications IMHO is good.

   Reply

2. Back to top

   Fluency in Natural Language

   Jan 19, 2008 10:01 PM by Geoffrey Wiseman

   During the DSL tutorial at QCon, someone, I believe Charlie Poole, noted that as DSLs approach natural language, they can loose expressivity for people who aren't already very fluent in the natural language.

   Reply

3. Back to top

   Its like DSLs

   Jan 20, 2008 12:02 AM by Francois Ward

   In the same way programming will often stray from "pure" code toward a domain specific language to better express itself, in a way, java, C#, C++, are "domain specific languages" for software development, while english is not. Having a language closer to english for coding would be like replacing all DSLs with raw C: it would work, but it is simply not optimal, it wouldn't be as intuitive...

   Reply

4. Back to top

   It's probably related more to globalization

   Jan 21, 2008 11:14 AM by Cristian Herling

   With today's distributed teams it make sense to code in a lingua-franca that every developer can speak in order to be able to write code that can be understood by its counterparts which probably speak a different language from him/her. This lingua franca is English, so most of the code ends up being written in English.

   Reply

• Older >