Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Does code become better as it approaches English?
Posted by Sadek Drobi on Jan 18, 2008 11:50 AM
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
RelatedVendorContent
Intel® SOA Expressway Performance Comparison to IBM® DataPower XI50
Velociti Partners Customer Survey
Open Sesame: Open Source Solutions for BI and Data Gain Acceptance
For some apps, a more narrative approach works well
by
Jeff Haynie
Posted
Jan 18, 2008 1:09 PM
Fluency in Natural Language
by
Geoffrey Wiseman
Posted
Jan 19, 2008 10:01 PM
Its like DSLs
by
Francois Ward
Posted
Jan 20, 2008 12:02 AM
It's probably related more to globalization
by
Cristian Herling
Posted
Jan 21, 2008 11:14 AM
-
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.
-
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.
-
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...
-
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.
4 comments
Watch Thread Reply