<br><br><div class="gmail_quote">On Wed, May 18, 2011 at 5:29 PM, 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></blockquote><div><br></div><div>Languages survive forever once they get to the point where</div><div><br></div><div> 1) legacy applications in the language still earn money</div><div> 2) it costs more to convert to a new language than maintain the</div>
<div> existing app in the old language</div><div><br></div><div>Erlang reached this point, many years ago.</div><div><br></div><div>Right now Erlang companies have a commercial advantage</div><div>over non-erlang companies and so there is not much point in </div>
<div>trying to spread the language further - you just loose your commercial advantage.</div><div><br></div><div>/Joe</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>
<div><div></div><div class="h5">-----END PGP SIGNATURE-----<br>
_______________________________________________<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>
</div></div></blockquote></div><br>