Programming language and IDE design

At the 2013 IEEE Workshop on Source Code Analysis and Manipulation
http://www.ieee-scam.org/2013/ each presenter was asked to come up
with a controversial statement. Mine was:


"Source code should be hard to write [and easy to read]".


The first comment from the audience was that this was not controversial!
Programmers in general spend more time reading code than writing code:
so anything which makes code easier to read, even at the expense of
harder to write, should be a gain overall.


The really controversial statement is to drop the phrase in brackets:


"Source code should be hard to write".


The justification for this statement is that one metric which correlates
very strongly with maintenance effort is lines of code.
If code is hard to write, then programmers will be motivated
to spend fewer lines of code to implement a particular functionality.
As Dijkstra wrote in "On the cruelty of really teaching computer science":


"if we wish to count lines of code, we should not regard them as
'lines produced' but as 'lines spent': the current conventional wisdom
is so foolish as to book that count on the wrong side of the ledger."


Similarly foolish wisdom is seen in IDEs (Integrated Development Environments)
which allow the programmer to create hundreds of lines of code
with just a few clicks of the mouse. Thus instantly creating a significant
maintenance effort. Another example of this "wisdom" (which in my
experience is very common among commercial IBM assembler
programmers) is when a programmer needs to implement a new function
which is fairly similar to an existing function: he or she just grabs a copy
of the existing module, changes a few lines of code and slaps it
into production. Over time, the two copies drift further apart,
bugs are fixed in one copy but remain lurking in the other copy,
new programmers have two lots of code to read, which are
confusingly similar, and so on.


So my assertion is "Source code should be hard to write": *even if*
the writing difficulty does not result in any improvement in ease of
reading! For example: before any programmer checks in a new module or
program change, they should be forced to write out all the code
longhand with a quill pen. This apparently pointless extra work
should give programmer's the opportunity to think about whether there
might be a shorter way to solve the problem (which might even be
easier to read and understand).


This also affects programming language design:


(1) Rather than use "{" and "}" for every type of grouping, each
different type of group such as an if statement or while loop, should
have its own opening and closing keywords. This is something that
modern COBOL gets right (along with the many things it gets wrong!)


(2) A commonly accepted rule for designing databases and software
systems is that each piece of information should be stored in only one
location. With a programming language, it is better for the reader if
information is duplicated to all the places where it might be needed,
with the compiler enforcing consistency. For example, data types and
formal parameter names should be recorded everywhere they are needed.
This helps the reader because the data type of a variable, for
instance, is right there in the function where the variable is
referenced, and the reader does not have to look it up in a different
file.


(3) Indentation helps the reader if it is consistent: so should also
be enforced by the compiler. In line with point (2), nesting should
be defined by *both* indentation *and* grouping keywords:
with the compiler enforcing consistency between the representations.
This means that the reader can rely on either indication of nesting,
since both are reliable.


Comments, anyone?


--
Martin


STRL Reader in Software Engineering and Royal Society Industry Fellow
martin@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc


[It's always seemed to me that the blats of code from IDEs that you
then might twiddle are an admission that the underlying design is bad,
and they don't understand OOP. Shouldn't those twiddles be
subclasses, with no code at all for the stuff that doesn't change?


On the other hand, having recently written a lot of python code, I've
come around to the opinion that enforced indentation is all the grouping
you need. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.