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