optimization of list comprehensions

[Richard A. O'Keefe]

Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
	yes, that didn't come out very well did it :>
	alas, a certain amount of relativism is perhaps unavoidable?

Consider the case of temperature.  Two people may disagree about whether
the temperature is too high (even a husband and wife sharing a bed may
disagree about that), but if they get out their thermometers they will
agree about what the temperature *is*.  And if you get to know someone
well (e.g. if you are married to them for 15 years) each of them gets
to know whether the other will like a particular temperature or not.

So just because there are different preferences does not mean that
there is any unavoidable relativism.

	consider the code below.  i think foo/0 is a completely
	unacceptable eyesore, whilst bla/1 is merely annoying.

	i know for a fact that some people think foo/0 is perfectly fine
	erlang.  so how would you propose i argue they're wrong?
	
You wouldn't because what they think is really at least *two* things:
    - the properties of fragment X are such and such
	[this is objective]
    - I like that
	[this is opinion]

It may indeed be at least three things:
    - the properties of fragment X are such and such [objective]
    - I have such and such goals		     [about themselves]
    - those properties support those goals	     [objective/empirical]

	-export([foo/0,bla/1]).
	
Already I think that failing to put a space after a comma is a bad thing.
Property:	there is no space after the comma.
Goals:		readability.
Support:	spaces improve readability.

To argue that I am "wrong" about this you would have to show either that
I was wrong to have readability as a goal or that as an empirical matter
spaces did not improve readability.  (By the way, I'm following the Ada
Quality and Style Guidelines here.  That remains my very favourite style
guide for code because of its copious rationales.)

	-define(FOO,"FOO".
	foo()-> FOO = ?FOO "FOO".
	
Here one could argue along these lines:

(1) People make mistakes.
(2) If you can make it easy for a tool to help you catch mistakes
    without hurting anything else too much, that's a good thing,
(3) Mismatched parentheses are a fairly common kind of mistake.
(4) You don't *have* to leave out the ")" in that macro:
	-define(FOO, "FOO").
    works as well or better.

One could also appeal to Grice's maxims of conversation, and point out
that
(5) Code that mentions a variable when it doesn't need to is harder
    to read than code that doesn't, because it makes the reader stop
    and try to figure out *why* the maxims have been violated.

So

    -define(FOO, "FOO").
    foo() -> ?FOO "FOO".

does everything that the original did, in fewer tokens, with less
confusion.  Surely that's an argument?

Then one can make the point that tracing and test coverage are important
debugging tools, so that

    foo1() -> "FOO".
    foo() -> foo1() ++ "FOO".

allows foo1() to be instrumented in ways that ?FOO cannot.  If your
interlocutor does not value such things, then you just have to wait
for experience to teach them otherwise.

	bla(X) -> bla(tl(X),{hd(X)}).
	bla([H|T],A) -> bla(T,{H,A});
	bla([],A) -> A.
	
This has one overwhelming advantage over code that uses macros:
you can actually *read* it because the code is *there* for you to read.
	
But I have more trouble *believing* this code than the other.
I can more easily imagine someone wanting "FOOFOO" than I can
imagine someone wanting to turn [1,2,3] into {3,{2,{1}}}.

Apparently we are both annoyed by bla/1, and I am sure we would agree
about what the code *is*, but I wonder whether we are annoyed by the
same things?

 - Spacing?
 - The lack of intention-revealing names?
   [If you want to argue with someone about that, there's a book
    by Henry Ledgard and Joh Tauer.  (Two volumes, both paperback.)
    My copy went for a walk some years ago and never came back, so
    I'm not perfectly sure of the title, but I *think* the two
    volumes are
    1.	Professional Software: Software Engineering Concepts
    2.	Professional Software: Programming Practice.
    As I recall it, there was a good discussion of good naming
    practice in one of those volumes, probably the second.
   ]
 - The absence of comments?
 - The strange data type?
    -type t(T) -> {T} | {T,t(T)}.
 - The fact that the strange data type doesn't have an "empty" case?