DRY principle and the syntax inconsistency in fun vs. vanilla functions

classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
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.,


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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
It's just been pointed out to me (in a possibly *unintentionally* private e-mail) that this topic was already taken up on a recent thread:


I don't really understand one of the objections: that newbies would find it strange. When I started learning Erlang, even with some experience in lisp and prolog, I found *lots* of things strange.

And yes, I understand that function clauses were borrowed from prolog. But an influence is not a stricture, especially when that influence is only partial, as it is here -- and maybe prolog wasn't doing it right either?

The better way to evaluate newbie-friendliness of the proposed syntactic change is to do it *scientifically*: teach some newbies both ways of writing function clauses, then see how well they do in timed code-comprehension tests where the only difference is the proposed change in syntax. I predict they'd actually have an easier time with what I propose, or at least do just as well.

-michael

On Wed, May 18, 2011 at 6:16 PM, Michael Turner <[hidden email]> 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.,


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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Michael Turner
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,


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 <[hidden email]> 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.,


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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Parnell Springmeyer-2
In reply to this post by Michael Turner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're being pedantic dude. I'm sure Joe Armstrong and the other
programmers that designed and work on Erlang are acutely aware of DRY,
PoLS, and a whole bunch of others.

Personally, I think it is a feature to state the function name when
defining another function clause.

    some_func(X, Y) ->
        %% Long bit of code
        ...;
    some_func(X, []) ->
        %% More code
        ....

Without it, scanning the source could get confusing.

Michael Turner <[hidden email]> writes:

> 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
> [hidden email]
> 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+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43
Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo
C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI
MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx
nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd
8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U=
=ypYB
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Parnell Springmeyer-2
In reply to this post by Michael Turner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Catering directly to the lowest common denominator is *not* a good
strategy. People should stop saying this: "We need to change feature X
to for reason Y for n00bs" and start saying this: "We need to write more
engaging documentation and have better idiomatic use case examples so
n00bs can /learn/".

It's easier to educate them than to not. Sure, learning Erlang is a
rough ride for your first year - but once you grok it, you have it for
life.

I would actually think they *wouldn't* have an easier time with that
sort of syntactic change because now you have to find that hidden set of
parentheses in a possible sea of code. See my previous email. It's a
nice idea in theory for small examples like factorial - but when you
have large functions that have multiple clauses, it is SOOOOOO nice
being able to scan down the left side of your editor window and see all
of those function names.

Michael Turner <[hidden email]> writes:

> It's just been pointed out to me (in a possibly *unintentionally*
> private e-mail) that this topic was already taken up on a recent
> thread:
>
>   http://erlang.org/pipermail/erlang-questions/2011-May/058323.html
>
> I don't really understand one of the objections: that newbies would
> find it strange. When I started learning Erlang, even with some
> experience in lisp and prolog, I found *lots* of things strange.
>
> And yes, I understand that function clauses were borrowed from prolog.
> But an influence is not a stricture, especially when that influence is
> only partial, as it is here -- and maybe prolog wasn't doing it right
> either?
>
> The better way to evaluate newbie-friendliness of the proposed
> syntactic change is to do it *scientifically*: teach some newbies both
> ways of writing function clauses, then see how well they do in timed
> code-comprehension tests where the only difference is the proposed
> change in syntax. I predict they'd actually have an easier time with
> what I propose, or at least do just as well.
>
> -michael
>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <
> [hidden email]> 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
> [hidden email]
> 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+LTAAoJEPvtlbpI1POLw1IH+QHYn/PuxcxZz6Xp6yzVuhnM
rPNkpp/kWpub2EBxo0qfyt/xhXE/FCdfHfgTy6T0mOXbuXx8vRRqVSQHP4OXwWSr
5NEnlavUQjIGtUjI8FX+ImSqNOWmvlT0RtMpwP7tuvFEiDpcc5XFf6+ba1ktJoK5
cNKNm1EFp6qLCN5y33Nrd/OavtTJf4o9nv/08gxpwRU3tIoee9Lh1uJTpmJ8EPh3
zfYRZ/wIR/7xMFIK40X+7YMyAEzmwy9TDM7RLAgwLrqMjbuphfRq0BDeLUVVRGhe
SMPS41QUjmxHkMY7W4t6S6KJy2BGey7pYeXNXjBbOhabiBknvHbl/Xd/APAU5/E=
=DpFL
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Parnell Springmeyer-2
In reply to this post by Michael Turner
-----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."

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 <[hidden email]> 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 <
> [hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Parnell Springmeyer-2
"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? 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.

And this is entirely apart from "long bit of code" being a classic Smell anyway:


-michael turner


On Thu, May 19, 2011 at 12:11 AM, Parnell Springmeyer <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're being pedantic dude. I'm sure Joe Armstrong and the other
programmers that designed and work on Erlang are acutely aware of DRY,
PoLS, and a whole bunch of others.

Personally, I think it is a feature to state the function name when
defining another function clause.

   some_func(X, Y) ->
       %% Long bit of code
       ...;
   some_func(X, []) ->
       %% More code
       ....

Without it, scanning the source could get confusing.

Michael Turner <[hidden email]> writes:

> 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
> [hidden email]
> 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+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43
Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo
C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI
MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx
nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd
8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U=
=ypYB
-----END PGP SIGNATURE-----


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

DRY principle and the syntax inconsistency in fun vs. vanilla functions

kevin montuori-2
On Wed, May 18, 2011 at 11:46 AM, Michael Turner
<michael.eugene.turner> wrote:

> Why is this less readable to you?

Because I can't use M-x show-matching-lines to find the heads.


k.

--
kevin montuori


Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Parnell Springmeyer-2
"Sorry, but Erlang doesn't *need* a better chance of survival."

Now, wait, I'm really pretty sure that, less than a year ago, I saw both Peyton-Jones and Armstong in a video, speculating about the future of their respective favorite languages, and openly wondering what the long-term future held. In the meantime, I haven't noticed a dramatic increase in the frequency of Erlang job postings, though perhaps it's gone up. However, a doubling would still leave the number small.

"Changing core language features that are solid,..."

Except that that what I proposes fixes a weak spot (among other things): failed syntactic consistency.

"... well thought out ..."

Except that Joe Armstrong has just admitted (on this thread, IIRC) that the reason for the inconsistency is that they just didn't think about it at the time...."

"... and non-harmful ..."

Implying that what I suggest here IS harmful? I've asked what would break in existing code if this change were made. Nobody has answered me yet. Certainly not you.

"... people /will/ follow it, almost to a religious end."

"Religious"? Speak for yourself. Worship of technology leads to more problems than it's worth.

"The issue you are attempting to get at is (again) an educational and experience one ..."

Actually not. No amount of education and experience will make repeating the function name with every clause a DRY issue, for those who find that repetition as more of an obstacle than otherwise. No amount of education and experience will keep people from wondering, "Why this strange inconsistency?" And better documentation and training will only make more people ask that question. I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. The current documentation makes it hard to find.
 
-michael turner

On Thu, May 19, 2011 at 12:29 AM, Parnell Springmeyer <[hidden email]> 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."

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 <[hidden email]> 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 <
> [hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Parnell Springmeyer-2
In reply to this post by Michael Turner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

How do you type more? When I type a ";" in my editor it auto-completes
the function clause for me, that is an empty argument for changing
something so trivial.

Practical considerations would be better defined through education for
core language features.

> 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
>                  ....

Because, now I would have:

    some_func
        (X, Y) ->
            %% Long bit of code
            ...;
        (X, []) ->
            %% More code
            ....

It makes the "structure" less flat when you start adding in indentation
levels (which you *have* to do if you are writing non-trivial functions
in order to be able to read them two weeks later).

Again, the style you are suggesting is really well suited for functions
with small and concise function bodies. Which, is well suited for the
lambda. I use this all the time for small functions:

    SomeFun = fun (X, Y)  -> %% Short peice of code;
                  (X, []) -> %% Short peice of code.

It's obviously much easier and quicker to read - but I don't beleive
that is the case with named functions.

> Why is this less readable to you? 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.

Then we would have someone like you complaining the opposite and
proposing we all do it the way it is now - that person would probably be
me.

> And this is entirely apart from "long bit of code" being a classic
> Smell anyway:
>
>   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

This is why I used the word "pedantic", don't I know abstraction and
orthogonality is preferred over monolithic functions? Of course I
do. But, what does one consider "long"? Some functions I write are
/better/ written as a long function to avoid unnecessary (read:
pedantic) abstraction that actually clouds the intent.

- --
Parnell "ixmatus" Springmeyer (http://ixmat.us)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY
peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv
+rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY
jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm
HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8
tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE=
=YwFM
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by kevin montuori-2
"Because I can't use M-x show-matching-lines to find the heads."

That would be "less browsable", rather than "less readable". That's a reasonable objection, and in fact the only truly concrete objection I've seen.  (If I may lump it together with "it breaks ctags", mentioned early, which is undoubtedly also true.) But programming tools are not carved in stone either. If, for example, somebody had to hack ctags to generate the right search strings for this function format, it's not the end of the world. It's just a matter of somebody wading into ctags and enduring the pain of it for a few days.

Finally, nobody would be making you do this to your own code, and where you had to deal with it in others, relatively trivial refactoring tools would make it possible to "toggle" code back and forth between the two allowed forms.

-michael turner

On Thu, May 19, 2011 at 1:06 AM, kevin montuori <[hidden email]> wrote:
On Wed, May 18, 2011 at 11:46 AM, Michael Turner
<[hidden email]> wrote:

> Why is this less readable to you?

Because I can't use M-x show-matching-lines to find the heads.


k.

--
kevin montuori


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Robert Raschke
In reply to this post by Parnell Springmeyer-2
Just 'cause it's this kind of a thread ;-)

"it would be frightening to estimate how much time programmers have
wasted formatting their text so comments line up and other such
idiocies.  proportional fronts are liberating because you get back all
that time.  if your program needs to be laid out with vertical
alignment to be understood, rewrite it."

    Rob Pike


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Daniel Goertzen-2
In reply to this post by Michael Turner


On Wed, May 18, 2011 at 11:08 AM, Michael Turner <[hidden email]> wrote
"I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. The current documentation makes it hard to find."



I think this is a key issue here: multi-clause funs just don't happen all that often.  It was very late in my Erlang learning experience that I found the need for multi-clause funs, and I easily found the documentation at the time.  I did notice the syntax inconsistency, but didn't care.   Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing.  Lots of funs make programs hard to debug.

Dan.
 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Parnell Springmeyer-2
"When I type a ";" in my editor it auto-completes the function clause for me, ..."

I apologize for being one of those cavemen who still uses vi. And for thinking, "If a program can autocomplete anything more than an identifier in context, it must be generating a pretty redundant piece of code to begin with."

-michael turner

On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

How do you type more? When I type a ";" in my editor it auto-completes
the function clause for me, that is an empty argument for changing
something so trivial.

Practical considerations would be better defined through education for
core language features.

> 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
>                  ....

Because, now I would have:

   some_func
       (X, Y) ->
           %% Long bit of code
           ...;
       (X, []) ->
           %% More code
           ....

It makes the "structure" less flat when you start adding in indentation
levels (which you *have* to do if you are writing non-trivial functions
in order to be able to read them two weeks later).

Again, the style you are suggesting is really well suited for functions
with small and concise function bodies. Which, is well suited for the
lambda. I use this all the time for small functions:

   SomeFun = fun (X, Y)  -> %% Short peice of code;
                 (X, []) -> %% Short peice of code.

It's obviously much easier and quicker to read - but I don't beleive
that is the case with named functions.

> Why is this less readable to you? 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.

Then we would have someone like you complaining the opposite and
proposing we all do it the way it is now - that person would probably be
me.

> And this is entirely apart from "long bit of code" being a classic
> Smell anyway:
>
>   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

This is why I used the word "pedantic", don't I know abstraction and
orthogonality is preferred over monolithic functions? Of course I
do. But, what does one consider "long"? Some functions I write are
/better/ written as a long function to avoid unnecessary (read:
pedantic) abstraction that actually clouds the intent.

- --
Parnell "ixmatus" Springmeyer (http://ixmat.us)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY
peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv
+rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY
jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm
HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8
tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE=
=YwFM
-----END PGP SIGNATURE-----


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Daniel Goertzen-2
"Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing.  Lots of funs make programs hard to debug."

I agree. On both points. But neither point is really relevant to my case here. I'm not proposing that people write more funs. I'm proposing that writing named functions enjoy one of the syntactic benefits of funs.

-michael turner

On Thu, May 19, 2011 at 1:17 AM, Daniel Goertzen <[hidden email]> wrote:


On Wed, May 18, 2011 at 11:08 AM, Michael Turner <[hidden email]> wrote

"I didn't ask that question until I *stumbled* on the extended syntax for funs; I didn't know about it before. The current documentation makes it hard to find."



I think this is a key issue here: multi-clause funs just don't happen all that often.  It was very late in my Erlang learning experience that I found the need for multi-clause funs, and I easily found the documentation at the time.  I did notice the syntax inconsistency, but didn't care.   Anyway, it is often a good idea to break funs out into full functions to reduce nesting and facilitate tracing.  Lots of funs make programs hard to debug.

Dan.
 



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
In reply to this post by Parnell Springmeyer-2
"Then we would have someone like you complaining the opposite and proposing we all do it the way it is now..."

Another strawman. Where do I advocate using multi-clause fun syntax for named functions *exclusively*? I don't. Clearly, even if the proposal here were wildly popular, there would be the problem of compatibility with existing code.

"Practical considerations would be better defined through education for core language features."

Where have I suggested changing even ONE single core language feature?

Strawmen, strawmen, strawmen.

-michael turner

On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

How do you type more? When I type a ";" in my editor it auto-completes
the function clause for me, that is an empty argument for changing
something so trivial.

Practical considerations would be better defined through education for
core language features.

> 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
>                  ....

Because, now I would have:

   some_func
       (X, Y) ->
           %% Long bit of code
           ...;
       (X, []) ->
           %% More code
           ....

It makes the "structure" less flat when you start adding in indentation
levels (which you *have* to do if you are writing non-trivial functions
in order to be able to read them two weeks later).

Again, the style you are suggesting is really well suited for functions
with small and concise function bodies. Which, is well suited for the
lambda. I use this all the time for small functions:

   SomeFun = fun (X, Y)  -> %% Short peice of code;
                 (X, []) -> %% Short peice of code.

It's obviously much easier and quicker to read - but I don't beleive
that is the case with named functions.

> Why is this less readable to you? 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.

Then we would have someone like you complaining the opposite and
proposing we all do it the way it is now - that person would probably be
me.

> And this is entirely apart from "long bit of code" being a classic
> Smell anyway:
>
>   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

This is why I used the word "pedantic", don't I know abstraction and
orthogonality is preferred over monolithic functions? Of course I
do. But, what does one consider "long"? Some functions I write are
/better/ written as a long function to avoid unnecessary (read:
pedantic) abstraction that actually clouds the intent.

- --
Parnell "ixmatus" Springmeyer (http://ixmat.us)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY
peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv
+rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY
jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm
HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8
tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE=
=YwFM
-----END PGP SIGNATURE-----


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Parnell Springmeyer-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alright dude, you seriously need to chill out - I know the "someone's
wrong on the internet" fever is hard to quench but at this point you're
nit picking and laying flame bait. Which I won't bite because I've
already wasted a good portion of my day on this exchange.

We're ultimately on the same side - I love the language as it is,
period. If you think something should be changed, go do it, other people
are writing different front-ends to the VM so I imagine it would be a
trivial change for you to make this particular change yourself. If it
catches on, I'm sure the maintainers would be happy to merge with
backwards compatibility for those (like me) that prefer the verbose
syntax.

Have a nice day and please stop taking these emails personally - it
truly is "whatevs". :)

Michael Turner <[hidden email]> writes:

> "Then we would have someone like you complaining the opposite
> and proposing we all do it the way it is now..."
>
> Another strawman. Where do I advocate using multi-clause fun syntax for
> named functions *exclusively*? I don't. Clearly, even if the proposal
> here were wildly popular, there would be the problem of compatibility
> with existing code.
>
> "Practical considerations would be better defined through education
> for core language features."
>
> Where have I suggested changing even ONE single core language feature?
>
> Strawmen, strawmen, strawmen.
>
> -michael turner
>
> On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer <[hidden email]
>> wrote:
>
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: SHA1
>    
>     > 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.
>    
>     How do you type more? When I type a ";" in my editor it
>     auto-completes
>     the function clause for me, that is an empty argument for changing
>     something so trivial.
>    
>     Practical considerations would be better defined through education
>     for
>     core language features.
>    
>     > 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
>     >                  ....
>    
>     Because, now I would have:
>    
>        some_func
>            (X, Y) ->
>                %% Long bit of code
>                ...;
>            (X, []) ->
>                %% More code
>                ....
>    
>     It makes the "structure" less flat when you start adding in
>     indentation
>     levels (which you *have* to do if you are writing non-trivial
>     functions
>     in order to be able to read them two weeks later).
>    
>     Again, the style you are suggesting is really well suited for
>     functions
>     with small and concise function bodies. Which, is well suited for
>     the
>     lambda. I use this all the time for small functions:
>    
>        SomeFun = fun (X, Y)  -> %% Short peice of code;
>                      (X, []) -> %% Short peice of code.
>    
>     It's obviously much easier and quicker to read - but I don't
>     beleive
>     that is the case with named functions.
>    
>     > Why is this less readable to you? 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.
>    
>     Then we would have someone like you complaining the opposite and
>     proposing we all do it the way it is now - that person would
>     probably be
>     me.
>    
>     > And this is entirely apart from "long bit of code" being a
>     classic
>     > Smell anyway:
>     >
>     >   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
>    
>     This is why I used the word "pedantic", don't I know abstraction
>     and
>     orthogonality is preferred over monolithic functions? Of course I
>     do. But, what does one consider "long"? Some functions I write are
>     /better/ written as a long function to avoid unnecessary (read:
>     pedantic) abstraction that actually clouds the intent.
>    
>     - --
>     Parnell "ixmatus" Springmeyer (http://ixmat.us)
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>     Comment: GPGTools - http://gpgtools.org
>    
>     iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY
>     peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv
>     +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY
>     jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm
>     HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8
>     tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE=
>     =YwFM
>     -----END PGP SIGNATURE-----
>

- --
Parnell "ixmatus" Springmeyer (http://ixmat.us)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJN0/WAAAoJEPvtlbpI1POLi7sIALtXMnbdt7pFvHGSUYsjGCzP
4yYfxdEcCgzcTlobee4I4WUhgtHFrk12tgA0zEG3s/hkFnY2up9h9PKnDxvAcD0U
h8ccxyNg6WRvhTfUq/82hyEYoo5NsOe/Y+4cmKSyhJILY/N8w2CqIJbSaQbnQ6rS
ELN5Xde5QS1mZU+H0fGxLZOEu6BIWL5pPXd27S/l+NON3wi/4Jl47S8AM/4kPX5Z
TKZzDxvNYZSk49G1g3QG5W2iNK7kL1lrxNFfUduhd80znDbbeHtyklxF69HJiPec
KgT+NloCufp/dImeTkl6taW9FhILZ/VgGGDYOSs0hx1kArHn1Xlc4XmPccvgAbA=
=0Xu4
-----END PGP SIGNATURE-----
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Mihai Balea
In reply to this post by Michael Turner
On May 18, 2011, at 12:13 PM, Michael Turner wrote:

> "Because I can't use M-x show-matching-lines to find the heads."
>
> That would be "less browsable", rather than "less readable". That's a reasonable objection, and in fact the only truly concrete objection I've seen.  (If I may lump it together with "it breaks ctags", mentioned early, which is undoubtedly also true.)

Here's another argument: after I spend 8 hours looking at code, I find that having the function name attached to each clause makes it easier to recognize where clauses begin and end.  I wouldn't worry about typing a few extra characters.  I find that I spend an order or magnitude more time reading code and thinking about it than typing it out. Maybe you are different and you are actually constrained by typing speed, but I doubt it. I care about readability and having function names in each clause makes things more readable for me.

> Finally, nobody would be making you do this to your own code, and where you had to deal with it in others, relatively trivial refactoring tools would make it possible to "toggle" code back and forth between the two allowed forms.


So basically you'd take a small source of inconsistency (because multiple clause funs aren't that common in the wild) and turn it into a huge one.

Isn't it bad enough that people are allowed to choose their own indentation style? (I kid, I kid... /ducks)

Mihai
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Michael Turner
I wish I could be nice here, but ... under provocation from another critic, forgive me for summing this up as just another strawman argument.  In particular, claiming what I propose is all about writeability, when I've actually already made an argument from readability (in the eye of the beholder, perhaps). Furthermore claiming that what I propose will increase "inconsistency", when at worst what it would increase would be stylistic variation -- about which people argue pointlessly anyway, so where's the loss?

There have a been two sensible counter-arguments here, both of them in the class "the existing tools wouldn't know about this move toward syntactic consistency." My answer to both is the same: yes, good point, but -- tools aren't carved in stone either.

I'm still waiting for the answer to the real showstopper question: would any existing code break, under my proposal?

-michael turner

On Thu, May 19, 2011 at 1:40 AM, Mihai Balea <[hidden email]> wrote:
On May 18, 2011, at 12:13 PM, Michael Turner wrote:

> "Because I can't use M-x show-matching-lines to find the heads."
>
> That would be "less browsable", rather than "less readable". That's a reasonable objection, and in fact the only truly concrete objection I've seen.  (If I may lump it together with "it breaks ctags", mentioned early, which is undoubtedly also true.)

Here's another argument: after I spend 8 hours looking at code, I find that having the function name attached to each clause makes it easier to recognize where clauses begin and end.  I wouldn't worry about typing a few extra characters.  I find that I spend an order or magnitude more time reading code and thinking about it than typing it out. Maybe you are different and you are actually constrained by typing speed, but I doubt it. I care about readability and having function names in each clause makes things more readable for me.

> Finally, nobody would be making you do this to your own code, and where you had to deal with it in others, relatively trivial refactoring tools would make it possible to "toggle" code back and forth between the two allowed forms.


So basically you'd take a small source of inconsistency (because multiple clause funs aren't that common in the wild) and turn it into a huge one.

Isn't it bad enough that people are allowed to choose their own indentation style? (I kid, I kid... /ducks)

Mihai


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: DRY principle and the syntax inconsistency in fun vs. vanilla functions

Jack Moffitt
> I'm still waiting for the answer to the real showstopper question: would any
> existing code break, under my proposal?

Assuming the answer is no, then I think it's fine to fix the
inconsistency an add this alternate notation. It would be nice to fix
it the other way to so that you could use the normal syntax in funs,
but I'm guessing that is a lot harder than just a parser change.

I could see using it for short functions.

I'll also point out that this is name-less clause syntax is the same
as in Clojure:

(defn
  mymax
  ([x] x)
  ([x y] (if (> x y) x y))
  ([x y & more]
   (reduce mymax (mymax x y) more)))

jack.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12345