<br><br><div class="gmail_quote">On Thu, May 19, 2011 at 6:39 AM, Michael Turner <span dir="ltr"><<a href="mailto:michael.eugene.turner@gmail.com">michael.eugene.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Joe, with all due respect, I think you've misinterpreted DRY. It's not a matter of writing something again because you can't find where it's already implemented. In fact, the canonical example of DRY is to write something that works for one case, and then, rather than define it as a function, template or macro, and invoke it with varying parameters, instead copy-paste-mutate for each case. In fact, the most common violations of DRY are *precisely* when you know where the repeated code is, either because you've just found it or because you've just written it.<div>
<br></div><div>"<span style="color: rgb(33, 35, 36); font-family: Arial,Helvetica,sans-serif; font-size: medium;">DRY says that every piece of system knowledge should have one authoritative, unambiguous representation."</span></div>
<div><span style="color: rgb(33, 35, 36); font-family: Arial,Helvetica,sans-serif; font-size: medium;"><br></span></div><div><span style="color: rgb(33, 35, 36); font-family: Arial,Helvetica,sans-serif; font-size: medium;"><a href="http://www.artima.com/intv/dry.html" target="_blank">http://www.artima.com/intv/dry.html</a></span></div>
<div><br></div><div>Erlang function definition syntax has two representations in the parser -- for no good reason I can see. Why?</div><div class="im"><div><span style="color: rgb(33, 35, 36); font-family: Arial,Helvetica,sans-serif; font-size: medium;"><br>
</span></div><div>"Changing syntax is *incredibly difficult* project managers get apoplectic at the thought of retesting million lines of code -"</div><div><br></div></div><div>No existing code will use the syntax I suggest. So how can any of it break?</div>
<div><br></div><div>I have yet to get an answer: what could this proposed change possibly break, even *theoretically*?</div></blockquote><div><br>This is what happens. You change the language. Suppose this is supported in release R17 and thereafter.<br>
<br>A while later new programmers use R17 and do not know that the new syntax was not supported in R12.<br><br>The new programmer gets a job to fix a bug in some legacy code written using R12<br>they fix the code using the latest system (R17) and forget to test it on R12. When compiled<br>
with R14 the new code won't work - alternatively somebody writes a snazzy new library using R17<br>and the new features. Then somebody using R12 wants to include the new library.<br><br>You might say - "tell them to upgrade to R17" and then they give you a load of really good reasons<br>
why they cannot do this.<br><br>I'm not saying that this is a desirable state of affairs - I'm just describing what I see around me - the<br>fault lies in the build system and the organizations ability to adept to change.<br>
<br>project mangers say "it will cost me money and time to market" to change from R12 to R17 - but they might<br>well want to use libraries developed in R17 in the R12 system - they can't if R17 uses things not understood in R12.<br>
<br>It's worse than you think. An experienced programmer uses R17 and make a new library and <br>publishes the library.<br><br>A beginner (using R15) downloads the library tires to compile it - but the R15 compiler fails<br>
to compile the code and what is worse gives a completely incomprehensible warning that the program<br>is wrong (because it doesn't understand *future* syntax) - the problem is that the beginner does not<br>know that this is what has happened - it this point they can draw several false conclusions<br>
(Erlang is crap, the library is crap because it won't compile)<br><br>Next problem - the beginner buy a couple of magnificent books describing Erlang - they<br>then get *incredibly* confused to find that the syntax in published code using the new stuff<br>
is not described in the books anywhere - sign - "why did I buy this bloody book, grumble grumble ..."<br><br>Erlang is sufficiently mature that the syntax is now very difficult to change.<br><br>Yesterday evening I downloaded TWO different programs (not Erlang, but some other well-known<br>
and reasonably familiar language) - both claimed to run 'out of the box' - 'just type make'<br><br>
This is called *version nightmares*<br>
<br>
I'm sure they did work on the authors machine - but they didn't on mine. Make works if the right stuff<br>
is preinstalled.<br><br>For Erlang I have a very precise idea of what is the latest dev. environment. But when I play<br>with things written in python, or perl or ruby I get hit in the face all the time with this.<br><br>
Syntax was easy to change before we had thousands of users and millions of $ worth of software<br>written in Erlang <br><br>Erlang syntax has changed very infrequently and when it has changed it's been for a big benefit -<br>
I can think of a few examples, the introduction of (funs and list comprehensions) and the introduction<br>of the bit syntax. Here the benefit far outweighs the cost.<br><br>Small cosmetic changes to the language will not be made. If you want these make your own preprocessor<br>
and make sure it can cross compile into every past version of erlang and keep it updated for every future version.<br><br>/Joe<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br></div><font color="#888888"><div>-michael turner</div></font><div><div></div><div class="h5"><br><div class="gmail_quote">On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br><br><div class="gmail_quote"><div>On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer <span dir="ltr"><<a href="mailto:ixmatus@gmail.com" target="_blank">ixmatus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>-----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><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><font color="#888888"><div>/Joe</div></font><div><div></div><div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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><br>
Michael Turner <<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">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" target="_blank">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>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">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>-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></div></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br>