X-Received: by 10.58.112.195 with SMTP id is3mr3336654veb.29.1382200198213; Sat, 19 Oct 2013 09:29:58 -0700 (PDT) Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!o2no14151885qas.0!news-out.google.com!9ni58445qaf.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Programming language and IDE design Date: Thu, 17 Oct 2013 11:06:26 +0100 Organization: Compilers Central Lines: 90 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-10-016@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 X-Trace: leila.iecc.com 1382200197 57592 64.57.183.58 (19 Oct 2013 16:29:57 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 19 Oct 2013 16:29:57 +0000 (UTC) Keywords: design, comment Posted-Date: 19 Oct 2013 12:29:57 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Xref: csiph.com comp.compilers:999 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]