Hacker News new | ask | show | jobs
by jerf 4764 days ago
"I've noticed long-time Erlang users tend to have this mystical ability to see the underlying elegance expressed by the Erlang syntax while ignoring the syntactic awkwardness."

It's just practice. It no longer trips me up, but I still find it klunky and unpleasant after nigh on 6 years of medium-duty usage.

    lists:map(fun (X) -> X + 1 end, [1, 2])
vs.

    map (+1) [1, 2]
Augh. Yes, I'm cheating perhaps a bit with the (+1), but Erlang syntax has enough other stuff in the way for it to still be fair in the end. For instance, the example Joe gave, where you end up with this long sequence of

    IdentifierA = operationA(ArgA),
    IdentifierB = operationB(IdentifierA, Something),
    ...
3 comments

"Ant turd tokens", or .,; are a big pain in the neck when refactoring stuff. For instance

    case Something of
       {ok, Val} ->
          do_something();
       _Error ->
          barf()
    end,
The ; and the , are easy to forget about. Indeed, the , might be changed to a . if you eliminate the next expression, and those things can be easy to miss when fiddling with code.
[ fun(N) -> N + 1 end || N <- [1,2] ]
That will produce a list of 2 funs. I think you meant:

    [ N + 1 || N <- [1,2] ].
I picked that as a simple example. Yes, I suppose I should have used a fold, or any of the other "everything else" functions that don't have syntax support. My point still stands.
Comparing Haskell and Erlang syntax isn't even fair. Haskell threw homoiconicity and homogeneity way out the window in exchange for some very nice, mathematical notation.
Erlang is hardly homoiconic, unless you mean Lisp-Flavoured Erlang.
No, it's not. I wasn't being precise. I believe Erlang to have a less complex syntax than Haskell, though, being based on Prolog.