Storytotell

One difficulty with these discussions it that there is no standard, objective definition of readability. Without one, it’s hard to debate statements like the title of this thread, “Readability can mislead”.

After thinking about this a lot, I settled on a personal definition of “ease of extracting useful information from the code”. This recognises some principles I’ve found to be important when discussing readability and how to improve it. For example, different knowledge will be useful depending on what you’re trying to achieve and what you already know, so code may be more readable for some purposes than others. Similarly, information may be relatively easy to extract for someone with one background or set of tools but harder for someone else to obtain under different circumstances. This means readability is always a balancing act, and something that makes code more readable for one purpose or reader may actually harm the readability in another context.

This explains a lot of subjective preferences based on the reader’s background. For example, in the Good for Whom? article by Daniel Lyons[1] that was cited by the article we’re discussing, there is a question of whether a one-line regular expression does anything to aid readability, and whether a much more verbose Smalltalk-style implementation of the same logic is more readable. I believe the most important thing to recognise in that debate is that the readability of the regex version is dramatically different depending…

This is the response anybody who tries to make s-expressions "more readable" will get from lispers: don't bother. It didn't work in the 60's, why would it work now?

Parens aren't unreadable, not like a sigil and punctuation heavy language, and on top of actually being reasonably readable, they are also extremely easy to edit with something like paredit in emacs and vim. So reasonable readability and extremely easy editing are working against you, also making the code easy to parse gives you not one, but three reasons not to waste time on such ideas.

Now, let's look at the reasoning this page gives for this endeavor(from http://sourceforge.net/p/readable/wiki/Problem/):

"Many people find Lisp's s-expressions hard to read as a programming notation, and thus reject them both."

And many find them perfectly readable.

"As noted below, even Lisp luminary Paul Graham agrees that Lisp notations have readability problems!"

The page lists several quotes from various people. Interestingly, the two quotes from PG aren't good very good support. The first one talks about mathematical expressions, but I tend not to write many of those in my code, so it is a minor problem at best. And there are macros that let you write infix math in Common Lisp, surely there exist equivalents for scheme and clojure.

The second doesn't even talk about lisp, but about code readability in general:

"When you program, you spend more time reading code than writing it... a language that makes source code…

Seems like a popular thing to do, but probably time consuming (I probably have dozens more URLs but i'd have to search a lot of laptops, delicious, and... remember magnolia?)

http://blog.fogus.me/2012/05/02/a-functional-programming-influence-graph/

http://blog.fogus.me/2012/06/07/an-object-oriented-influence-graph/

https://news.ycombinator.com/item?id=3920619

http://www.info.ucl.ac.be/~pvr/paradigms.html

(the Dewey decimal system congeners) http://delivery.acm.org/10.1145/2380000/2371137/ACMCCSTaxonomy.html?ip=76.22.37.150&acc=OPEN&key=1B55DF923F77674F55057ED4F3766CA0&CFID=346311616&CFTOKEN=70828105&__acm__=1373473781_10bd00e024e5caa1c72dd84b743d610f

http://james-iry.blogspot.com/2010/05/types-la-chart.html

http://blog.ouseful.info/2012/07/03/mapping-how-programming-languages-influenced-each-other-according-to-wikipedia/

__________

vaguely related: the Right Tools survey

http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/viz/index.html

http://www.storytotell.org/essays/juxtaposition.html

http://www.cl.cam.ac.uk/teaching/1011/ConceptsPL/ (they spend a lot of time studying ML and the state of the art language)

http://www.cl.cam.ac.uk/teaching/exams/pastpapers/t-ConceptsinProgrammingLanguages.html (pretty sure i'd flunk)

http://www.cl.cam.ac.uk/teaching/1213/DenotSem/

I blogged recently about some problems I have with JIRA:

http://www.storytotell.org/constraints-and-semantics/

In a nutshell, I argue that the problem with most ticket systems is that they do not constrain the domain enough, so they wind up having similar problems to email (sifting through a chronologically-ordered pile of text rather than structured, semantically-ordered information).

Your comments make me think the crux of the problem is that people want tickets to be like email and use email to manage them. I'm not sure you can ever overcome the "chronological pile-up" problem if you allow email as a user interface to ticketing.