In The thing with code clarity: you can't be proud of something I can't read, Santiago L. Valdarrama makes an plea for clarity. I applaud Santiago's position but think clarity misses the point. I prefer simplicity--the removal of non-essential elements.

I'm not convinced clarity leads to simplicity. Clarity can lead to understanding. Is understanding a complex implementation worthwhile? Not if that implementation can be simpler.

Simplicity. Achieve it and the documentation need only explain the essential elements of the solution. It solves the problem of how much to document. It makes obvious to those maintaining the implementation what it does and where the gaps in their knowledge lie.

On Reddit, Uberhipster makes excellent comments and includes informative links. The first discusses The Little Prince; the second the progression of Picasso's Bull. I like the connection between my notion of simplicity and Picasso's Bull. But it raises troubling questions when applied to software.

The Little Prince and Bull are the work of a single individual. Most useful software is developed by teams.  I'll bet lack of clarity amplified through misunderstanding by multiple people creates a vicious downward spiral.

Clarity won't provide an escape from this spiral. Simplicity will.

I finally finished my Winter 2015 (yes, that's correct) issue of Nautilus. Amazing articles.

One article that stands is Shakespeare's Genius is Nonsense. This article was informative enough to provide me with a new appreciation of Shakespeare.

Shakespeare's Genius is Nonsense provided insight into how the writing style creates a lasting effect for the reader (or upon hearing the words spoken) because of the links that spread out from each word based upon sound, sounds that resemble it, its sense, its potential senses, their homonyms, their cognates, their synonyms and their antonyms.

The emphasis in Shakespear's writing is not so much on the puns contained therein but on the unexploded puns which retain their energy and create a lasting effect.

In Five thoughts on software, Seth Godin points out that utility and ease of use have been pursued at the expense of power and simplicity and that it is urgent that software companies create tools that increase the quality of what user's create.

This is similar to an argument made by Frederick P. Brooks Jr. in the Computer Scientist as Toolsmith. Brooks made this argument in 1977 and again in 1996. In 1996 Brooks wrote:

If the computer scientist is a toolsmith, and if our delight is to fashion power tools and amplifiers for minds, we must partner with those who will use our tools, those whose intelligences we hope to amplify.

Godin lays some of the problems with software at the feet of customers who accept poor software as the norm. He requests that customers have higher aspirations for what their tools can achieve. I agree.

Good customers are demanding. In my experience, the most demanding customers provide the best insight on what your product roadmap should contain. Finding those customers is challenging because the relationship needs to evolve into a mutually beneficial partnership.

If you have software that doesn't amplify your intelligence contact the vendor. Whether that vendor is interested in helping you create value or not will become apparent very quickly. If you conclude that they aren't interested in helping you create value then spend your money elsewhere.

The same goes for the software developers. You can tell if your company cares about its customers by the quality of input you obtain from those customers. And how far you are from those customers. If you are far enough away that you wouldn't recognize a customer if you saw one then perhaps you are working for the wrong company.

Godin lays down a challenge to the entire software industry: build powerful and simple software that allows him to increase the quality of what he creates. I like building software. I think it's a challenge worth committing too.

What will you do?

Installed LaTeX2HTML using Mac Ports:

# sudo port install latex2html

Looked good but it messed up my LaTeX style files so that none of my LaTeX files would build.
To correct this had to take the following actions.

# sudo port uninstall texlive-latex texlive-basic texlive-bin
# sudo port install texlive-latex
# sudo texhash

No avail.

Had to reinstall several style files (e.g., etoolbox.sty and parskip.sty).
Picked up the style files from ctan.org.

These went into /opt/local/share/texmf-texlive/tex/latex. Then

# sudo texhash

LaTeX restored and operational.

In “Why Most Unit Testing is Waste (An Exploration)” I summarize how Coplien views an explicit calling structure (or context) for the objects (and methods) as critical to enabling reasoning about the execution of a program. Here, I take an in-depth look at the article’s introduction.

What piques my interest in the introduction to “Why Most Unit Test is Waste” are statements comparing the difficulty of reasoning about programs written in FORTRAN to an object-oriented programming language. Understanding this is critical to understanding the motivation behind Coplien’s arguments on waste.

The object-oriented programming language Coplien refers too isn’t named. I selected C++. Java is an equally good choice.

It turns out that FORTRAN, C++ and Java all support polymorphism. In fact, all three languages support static (early) binding and dynamic dispatch. Static binding ensures that compilation fixes the binding of names. Dynamic dispatch is the process of selecting which implementation of a polymorphic operation (method or function) to call at run time.

FORTRAN introduced polymorphic types in FORTRAN 2003. A review of FORTRAN 2008, J3/10-007r1, states that the class type specifier is used to declare polymorphic entities. A polymorphic entity is a data entity that is able to be of differing dynamic types during program execution.

A review of “Programming Languages — C++” and “The Java® Language Specification Java SE 8 Edition”, shows that both support static binding and dynamic dispatch.

The C++ standard states that virtual functions provide the mechanism for dynamic binding and object-oriented programming. A class that declares or inherits a virtual function is called a polymorphic class.

The Java standard that instance methods provide the mechanism for dynamic dispatch. A method which is not declared static is an instance method.  An instance method is also called a non-static method. In “The Java® Virtual Machine Specification Java SE8 Edition”, instance method is likened to virtual methods in C++.

If FORTRAN, C++ and Java all use dynamic dispatch what is Coplien’s thesis regarding reasoning about FORTRAN and object-oriented programs?

Some thoughts:

• my analysis of FORTRAN, C++ or Java is incorrect.
• Coplien’s discussion relies on a version of FORTRAN that predates the introduction of polymorphism.

If my analysis is incorrect then this article is done. If Coplien’s thesis relies on an outdated version of FORTRAN then it is worthwhile understanding how (if) this affects the conclusions.

I’ll assume that my analysis is correct and Coplien refers to an outdated version of FORTRAN for purposes of supporting his thesis. Reliance upon an old version of FORTRAN is in line with the article’s introduction, which makes FORTRAN sound ancient.

Relying on an outdated version of FORTRAN requires that it not support polymorphism. FORTRAN 95 does not support polymorphism. FORTRAN 95 is an official standard and no public previews are available. (FORTRAN 77 introduced ad-hoc polymorphism for operators and I’ll ignore this. [Wikipedia])

Assuming an outdated version of FORTRAN, then all three programming languages support early binding. C++ and Java support dynamic dispatch. FORTRAN does not. There is no need to examine early binding as it is common to all three languages.