"<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">It seems to me that Michael Turner's argument is an argument from conservatism.<br>Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl,<br>
all of these languages write a function name once and only once at the beginning<br>of a function."</span><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">But which of those allow more than one argument list? It isn't just that people are used to the function name being written only once. (That isn't true for C++ member functions, and there are *lots* of C++ programmers out there.) I think the indentation style I suggest also makes it more immediately obvious that Erlang features a kind of pattern-directed invocation.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">As for what you claim is more readable, remember: the intuitive is the familiar. Someone who is entirely new to Erlang will perceive things differently. The only way to make the proposition "syntax X is more readable" a scientific one is to test -- on people *new* to Erlang. After all, someday, all of us will have passed from the scene and it will be only the new people who matter.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">-michael turner</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font><br><div class="gmail_quote">On Fri, May 20, 2011 at 5:07 PM, Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On 19/05/2011, at 3:46 AM, Michael Turner wrote:<br>
<br>
> "You're being pedantic dude."<br>
><br>
> If I argued only from syntactic consistency, you'd have a point. Frankly, I don't really care about syntactic consistency, if it doesn't get me something. Having to type less gets me something. Having more readable code gets me something. Those are practical considerations, not mere pedantic ones. Dude.<br>
><br>
> What you have as<br>
><br>
> some_func(X, Y) -><br>
> %% Long bit of code<br>
> ...;<br>
> some_func(X, []) -><br>
> %% More code<br>
><br>
> could, as I proposed above, also be written<br>
><br>
> some_func<br>
> (X,Y) -> %% long bit of code<br>
> ...;<br>
> (X,[]) -> %% More code<br>
> ....<br>
><br>
> Why is this less readable to you?<br>
<br>
</div>For the same reasons it is less readable to me.<br>
Readable code PROVIDES HELPS FOR THE READER.<br>
<div class="im"><br>
> You could answer, "Because it's not what I'm used to seeing in Erlang programs," but that begs the question. If people were more used to seeing the latter -- because making Erlang syntactically more self-consistent made it possible -- that argument wouldn't have much force -- except as an argument from pure conservatism.<br>
<br>
</div>It seems to me that Michael Turner's argument is an argument from conservatism.<br>
Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl,<br>
all of these languages write a function name once and only once at the beginning<br>
of a function. So therefore Erlang should do the same? Give me a break: those<br>
languages that "the majority of programmers" are familiar with don't *have*<br>
multiple clause functions.<br>
<br>
Let's take an example *adapted* from "Pattern Matching in Scheme".<br>
<br>
(define parse<br>
(match-lambda<br>
[(and s (? symbol?) (not ’lambda))<br>
(make-Var s)]<br>
[(? number? n)<br>
(make-Const n)]<br>
[(’lambda args body)<br>
(make-Lam args (parse body))]<br>
[(f args ...)<br>
(make-App (parse f) (map parse args))]<br>
[x (error ’syntax "invalid expression")]))<br>
<br>
Now let's write that in Erlang:<br>
<br>
parse(S) when isatom(S), S \== lambda -><br>
make_var(S);<br>
parse(N) when isnumber(N) -><br>
make_const(N);<br>
parse([lambda,Args,Body]) -><br>
make_lam(Args, parse(Body));<br>
parse([F|Args]) -><br>
make_app(parse(F), [parse(Arg) || Arg <- Args]);<br>
parse(_) -><br>
error(syntax, <<"invalid expression">>).<br>
<br>
That paper ends with a page full of code defining a single<br>
function, and looking at it, I can see what pattern is being<br>
matched, but not why, and can't really tell without the aid<br>
of a ruler.<br>
<br>
I've played with things like that, and I never want to do<br>
so again. I greeted SML, then Haskell, and Erlang, with load<br>
cries of joy.<br>
<div class="im"><br>
> And this is entirely apart from "long bit of code" being a classic Smell anyway:<br>
><br>
> <a href="http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm" target="_blank">http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm</a><br>
><br>
> -michael turner<br>
<br>
</div>You will find that some of the things in that taxonomy are, um,<br>
expressed in an over-general way in the interests of brevity.<br>
For example, I don't see any reason to ban switch statements<br>
from Java. They don't do anything that dynamic dispatch can<br>
do, and dynamic dispatch doesn't do what switches can do.<br>
<br>
"Long Methods" is very much a matter of taste; how long is too<br>
long? I've just recommended to someone that they add about<br>
another 100 lines of code to a certain method today; 90 of<br>
those lines are a table of strings. There is nothing evil<br>
about a table of strings.<br>
<br>
</blockquote></div><br></div>