[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions
Fri May 20 16:11:58 CEST 2011
"It seems to me that Michael Turner's argument is an argument from
all of these languages write a function name once and only once at the
of a function."
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
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.
On Fri, May 20, 2011 at 5:07 PM, Richard O'Keefe <> wrote:
> On 19/05/2011, at 3:46 AM, Michael Turner wrote:
> > "You're being pedantic dude."
> > 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.
> > What you have as
> > some_func(X, Y) ->
> > %% Long bit of code
> > ...;
> > some_func(X, ) ->
> > %% More code
> > could, as I proposed above, also be written
> > some_func
> > (X,Y) -> %% long bit of code
> > ...;
> > (X,) -> %% More code
> > ....
> > Why is this less readable to you?
> For the same reasons it is less readable to me.
> Readable code PROVIDES HELPS FOR THE READER.
> > 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.
> It seems to me that Michael Turner's argument is an argument from
> all of these languages write a function name once and only once at the
> of a function. So therefore Erlang should do the same? Give me a break:
> languages that "the majority of programmers" are familiar with don't *have*
> multiple clause functions.
> Let's take an example *adapted* from "Pattern Matching in Scheme".
> (define parse
> [(and s (? symbol?) (not ’lambda))
> (make-Var s)]
> [(? number? n)
> (make-Const n)]
> [(’lambda args body)
> (make-Lam args (parse body))]
> [(f args ...)
> (make-App (parse f) (map parse args))]
> [x (error ’syntax "invalid expression")]))
> Now let's write that in Erlang:
> parse(S) when isatom(S), S \== lambda ->
> parse(N) when isnumber(N) ->
> parse([lambda,Args,Body]) ->
> make_lam(Args, parse(Body));
> parse([F|Args]) ->
> make_app(parse(F), [parse(Arg) || Arg <- Args]);
> parse(_) ->
> error(syntax, <<"invalid expression">>).
> That paper ends with a page full of code defining a single
> function, and looking at it, I can see what pattern is being
> matched, but not why, and can't really tell without the aid
> of a ruler.
> I've played with things like that, and I never want to do
> so again. I greeted SML, then Haskell, and Erlang, with load
> cries of joy.
> > And this is entirely apart from "long bit of code" being a classic Smell
> > http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
> > -michael turner
> You will find that some of the things in that taxonomy are, um,
> expressed in an over-general way in the interests of brevity.
> For example, I don't see any reason to ban switch statements
> from Java. They don't do anything that dynamic dispatch can
> do, and dynamic dispatch doesn't do what switches can do.
> "Long Methods" is very much a matter of taste; how long is too
> long? I've just recommended to someone that they add about
> another 100 lines of code to a certain method today; 90 of
> those lines are a table of strings. There is nothing evil
> about a table of strings.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions