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

[Daniel Dormont]

Speaking as a relative newb with experience in other languages, I agree.
Perhaps my experience is unusual (though honestly, I don't think so) in that
I've spent some quality time with Haskell and Standard ML before coming to
Erlang, but this particular feature makes perfect sense to me in its current
form.

What I'd love is to have this in nested functions too. I don't care much
care about syntactic consistency for its own sake (heck, Perl is one of my
favorite languages, what does that tell you) so that's not my motivation;
what excites me is being able to have recursive closures.

dan

2011/5/19 Frédéric Trottier-Hébert <fred.hebert@REDACTED>

> I don't agree with complaints either -- I have no issue with Erlang's
> syntax, lisp/scheme/racket's syntax or any other language. The reality,
> however, is that while programmers can pick up Erlang's syntax quickly,
> there's still an initial struggle to break what has been committed to muscle
> memory by many of the people I have taught it to.
>
> The syntax might be the scapegoat of the difficulty in learning foreign
> concepts like functional paradigms, concurrent ideas or pattern matching,
> but in any case, it is a hurdle that newcomers have to step over. It's not
> because they can beat challenges that we have to make it harder on purpose
> by introducing new elements like the alternative function syntax.
>
> --
> Fred Hébert
> http://www.erlang-solutions.com
>
>
>
> On 2011-05-19, at 18:49 PM, Edmond Begumisa wrote:
>
> >> People already complain that Erlang's syntax is too ugly or complex;
> >
> > I've always found this complaint to be rather quibble.
> >
> > Programmers have brains that are extremely well adjusted to parsing new
> syntax. This is one thing all programmers are inherently good at. Yet when
> asked to put this skill towards learning a new language, they complain. "No"
> they say, "give me a syntax I'm already familiar with. Why are you trying to
> be different?" they ask.
> >
> > I learned Erlang by reading Joe's book. Within half an hour I wasn't
> seeing the syntax anymore. My brain, quickly made the necessary mental
> mappings. I strongly believe this to be the case with all programmers when
> encountering an unfamiliar syntax -- rapid adjustment with relatively little
> effort.
> >
> > Other professions are not so lucky. I once witnessed two non-programmers
> trying to learn HTML at the same time. One a medical doctor, the other a
> graphic designer. Both got the concepts down very quickly (links, images,
> tables, etc), but both really struggled with syntax. "How can one possibly
> read this?" they kept asking.
> >
> > Yet most programmers learn HTML/XML syntax in a matter of minutes while
> watching TV. Gut give them Erlang and they groan and complain loudly.
> >
> > IMHO, complaints about Erlang's syntax being "too weird" are completely
> unwarranted. A programmer could learn a language written using Klingon
> symbols in a unbelievably short period of time. Just look at all those
> non-English speakers who program in languages heavily biased towards
> English. And many of them come from languages using non-latin scripts!!!
> >
> > - Edmond -
> >
> > PS: The exception is Lisp. All those parentheses are just obfuscating :)
> >
> >
> >
> > On Thu, 19 May 2011 21:41:50 +1000, Frédéric Trottier-Hébert <
> fred.hebert@REDACTED> wrote:
> >
> >> I would rather have one clear but slightly verbose way of doing things
> rather than two potential ways to do the same thing in slightly different
> manners prompting religious wars to get the same result I already have.
> >>
> >> The idea to revisit the syntax isn't bad in itself, but looking at the
> examples Steve Davis provided, I can only see your concept being useful for
> very short functions.
> >>
> >> When it comes to learning Erlang, I can tell you that in my experience,
> new users struggle a lot more with clause separators (;), expression
> separators (,), form terminators (.), records, 'if' or funs (in concept)
> than they do with function syntax. They do not seem to see the current way
> to write function heads as problematic. Then, all Erlang users are also used
> to it.
> >>
> >> Adding more ways to do things that currently have a single way to be
> done is a net loss in my opinion. People already complain that Erlang's
> syntax is too ugly or complex; I do not think that adding more syntax is the
> way to solve that. It would not benefit new users and it would not benefit
> the majority of all users, only increase the ways they can read code and get
> confused.
> >>
> >> In the other thread, someone called it 'syntactic salt', and I think
> this is a good way to describe how things are right now. It's not a bad
> thing in my opinion.
> >>
> >> On 2011-05-19, at 06:47 AM, Michael Turner wrote:
> >>
> >>> "But how interesting is whether existing code would break or not?"
> >>>
> >>> Not very. I mean, who uses Erlang for anything important? Hardly
> anybody, right?
> >>>
> >>> [/sarcasm]
> >>>
> >>> "It would, as others have pointed out, also be much harder to jump into
> a module and _know_ what the clause does since the function's name can be
> pages away."
> >>>
> >>> It would only be harder ("much"??) if you *chose*, in such cases, to
> use the syntax I propose to bring over from multi-clause funs. In the case
> you bring up, it might be wiser not to. And what I propose clearly allows
> everyone to continue with the present syntax. So your argument for
> readability in this case comes down to "somebody might not use this language
> feature wisely." (*facepalm*).
> >>>
> >>> -michael turner
> >>> _______
> >>> erlang-questions mailing list
> >>> erlang-questions@REDACTED
> >>> http://erlang.org/mailman/listinfo/erlang-questions
> >>
> >> --
> >> Fred Hébert
> >> http://www.erlang-solutions.com
> >
> >
> > --
> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110519/38882fe7/attachment.htm>