[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions

[Joe Armstrong]

On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer <ixmatus@REDACTED>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sorry, but Erlang doesn't *need* a better chance of survival. This
> language is not just growing, it's booming. Changing core language
> features that are solid, well thought out, and non-harmful (in other
> words, they are, FEATURES) to make it more "adoptable" is a lot like
> someone saying, "you have to quit that quirky smile so other people will
> like you more."
>

Languages survive forever once they get to the point where

   1) legacy applications in the language still earn money
   2) it costs more to convert to a new language than maintain the
        existing app in the old language

Erlang reached this point, many years ago.

Right now Erlang companies have a commercial advantage
over non-erlang companies and so there is not much point in
trying to spread the language further - you just loose your commercial
advantage.

/Joe


>
> Sometimes, yes, there are features in a language that could use
> refinement - but many times, in a mature language, the ratio between
> need and usefulness in refining a feature further, drops significantly.
>
> Instead of changing something that is solid, educate the people that
> have a hard time grasping it, build killer example applications that
> exhibit the quirky style and idioms to a T - people /will/ follow it,
> almost to a religious end.
>
> That's actually what I like about Erlang the most, the documentation has
> so many gems in it like the efficiency guide (where many common idioms
> are expressed with clear DO and DON'T DO examples) and style guide.
>
> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more
> consistent than many languages I've touched.
>
> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is
> less consistent than Erlang's is in my opinion. The issue you are
> attempting to get at is (again) an educational and experience one, not
> something that is inherently wrong with the language or its expression
> itself.
>
> I'm actually baffled by the efforts people are putting into different
> Erlang VM frontends that look like Ruby or Python. Good on them for
> exercising the freedom of open source but /why/? Erlang's syntax is
> almost beautiful to me now after using it, it's so well suited for what
> Erlang is good at!
>
> Erlang isn't that great for general purpose programming - you use
> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at fault
> tolerance, easy parallelism (which isn't easy!), and hot code
> loading. Features that are so difficult to do in the traditional
> imperative environment that (to date) I have not seen a single
> implementation of any one of those features that even approaches the
> completeness of Erlang's.
>
> Michael Turner <michael.eugene.turner@REDACTED> writes:
>
> > Another objection raised against this syntax change is that all
> > functional languages violate DRY in this manner, so it's OK if Erlang
> > does it too. This is a Principle of Least Surprise argument, and not
> > bad as far as it goes. But how far does it go?
> >
> > Erlang will have a better chance of greater success and survival if you
> > consider your recruitment base to be the overwhelming majority of
> > programmers. And from what I can tell,
> >
> >   http://www.langpop.com
> >
> > the overwhelming majority of programmers have no experience to speak
> > of, when it comes to functional programming languages. Appealing to the
> > "cross-training" benefit of coming from other FP languages seems like a
> > pretty weak argument. Especially since all I'm asking for here is
> > syntactic consistency *within* Erlang -- a PLoS argument in itself.
> >
> > Richard O'Keefe suggests that the syntactic consistency goal is better
> > met by allowing a kind of limited-scope special-case fun name,
> > permitting, e.g.
> >
> >   Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.
> >
> > I could get behind that too, but I don't follow his reasoning from
> > syntactic consistency, which is apparently that an unnamed fun has a
> > name, it's just the degenerate case of a name.  It's really there. We
> > just can't see it. Hm, really? If that were true in Erlang as it
> > stands, shouldn't I be able to write it this way?
> >
> >   Fact = fun (0) -> 1; (N) -> N*''(N-1) end.
> >
> > Looks like it's not quite that simple. It compiles, but it doesn't know
> > what module to look in for '', when it comes time to execute. In the
> > shell, I get an error indicating that it tried to resolve ''/1 as a
> > shell command. Even if I put it in a .erl file and compile it, there's
> > no obvious way to tell the compiler what module to look in. ?MODULE:''
> > doesn't work. Nor does '':'', which I tried just for the hell of it.
> >
> > What Richard's suggesting appears to require a rigorous re-think of how
> > scopes are defined in Erlang. What I'm suggesting amounts to simply
> > asking the compiler to do some of your tedious keying for you.
> >
> > -michael turner
> >
> >
> > On Wed, May 18, 2011 at 6:16 PM, Michael Turner <
> > michael.eugene.turner@REDACTED> wrote:
> >
> >     I can say
> >
> >        fun (1)->2;
> >             (2)->1
> >        end
> >
> >     but, oddly, I can't define a named function in the analogous way,
> >     e.g.:
> >
> >        factorial
> >          (1) -> 1;
> >          (N) -> N*factorial(N-1).
> >
> >     gives me a syntax error. I find the latter more readable than
> >
> >        factorial(1) -> 1;
> >        factorial(2) -> N*fact(N-1).
> >
> >     It's also less to type and to read, which is consistent with the
> >     DRY principle ("Don't Repeat Yourself").  And it lends itself to
> >     reading a function definition as a set of cases. I think for Erlang
> >     newbies, it should therefore would be preferred: it helps
> >     underscore the pattern-matching style of Erlang function
> >     invocation.
> >
> >     It also looks a *little* bit more like the mathematical convention
> >     for defining these sorts of functions, where you have "f(x) = ",
> >     centered vertically to the left of a big left "{" that (left-)
> >     encloses the list of expression/parameter-condition pairs in a
> >     two-column format, e.g.,
> >
> >      http://cnx.org/content/m29517/latest/Picture%2047.png
> >
> >     So there's a (weak) argument from the Principle of Least Surprise
> >     here as well.
> >
> >     It seems to me that, if anything, this requires only a
> >     *simplification* of the Erlang parser. That leaves only one obvious
> >     objection: would any existing code break if Erlang syntax were
> >     altered to allow this?
> >
> >     -michael turner
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> - --
> Parnell "ixmatus" Springmeyer (http://ixmat.us)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJN0+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX
> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN
> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S
> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf
> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw
> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc=
> =GGPU
> -----END PGP SIGNATURE-----
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110518/028a36b4/attachment.htm>