[erlang-questions] Any Erlang Devs Contemplating Elixir?

[Onorio Catenacci]

On Sun, Mar 6, 2016 at 11:32 AM, Garrett Smith <g@REDACTED> wrote:

> On Sat, Mar 5, 2016 at 10:04 PM Robert Virding <rvirding@REDACTED> wrote:
>
>> One definite benefit in having to explicitly write every callback even if
>> it is doing "default" stuff is that everything *IS* then explicit and you
>> can directly SEE what happens. And come on, writing a 2 line default case
>> for a few callbacks is really not that much to extra code.
>>
>> A major problem with having implicit "default" cases is that what people
>> consider to be a reasonable default handling varies depending on what just
>> that server is doing. There is no default that suits every server so I will
>> probably have to write it out and anyway.
>>
>> Hiding callbacks behind defaults also means that you don't SEE everything
>> that is there. This can be a major problem for newcomers.
>>
>
> A counter point to this is that by deferring increasingly complex cases by
> providing sensible defaults, a user can more quickly and correctly
> understand an API. A useful abstraction has a story line - and I think the
> simpler the better. Requiring the user to accommodate increasingly edge
> cases undermines the main story line.
>
> E.g. I like the pattern in Erlang functions that follows the getopt Tao of
> required params + options. Let me get to the gist of an operation with the
> fewest possible inputs and I can incrementally grow into the more complex
> cases.
>
> I think this is less about typing and more about clarity of intent.
>
> The challenge to getting this right is drawing that line between the
> essential interface and the incremental enhancements. Libraries fail when
> they outright hide important details and leave the user mystified with
> seemingly magical behavior.
>
>
Again, apologies--couldn't get away to respond till now:

1.) There's no question that explicit is better than implicit Robert.  But
on the other hand, if most of the explicit is going to be boilerplate code
then it should be hidden by default.  I don't know your experience but in
mine I've met very few developers who bother to investigate compiler
warnings.  And I mean _default_ compiler warnings.  This is because most of
them say "Well it compiles so it's ok right?"  Boilerplate code can
encourage that tendency too--I simply copy/paste the boilerplate from
another codebase and I don't worry about what it does.  So, in that case I
think it's ok to make an exception to the general rule that explicit is
better than implicit.

Explicit is better than implicit because it forces someone to actually
_think_.  Lots of boilerplate has the opposite effect wouldn't you agree?

2.) As I said in my original response, macros strike me as a very powerful
tool but quite dangerous in the hands of a noob developer.  I almost wish
there were a way to disable macros from the compiler level on a setting
that could be hidden from new developers.  Yes they're extremely powerful
(and yes I agree that LFE is even more powerful) but like so many other
powerful mechanisms they're also really dangerous in the hands of the
inexperienced.  Or even those that learn only part of the story but don't
get all of it. As Pope said "a little knowledge is a dangerous thing."

3.) I agree with Garrett.  Language defaults are a lot more important than
many developers seem to realize.  Every since I started developing code I
was always told to slap a const on immutable data and to pass arguments by
value as much as it could be managed.  This prevented accidental changes.
Yet in all my experience of writing C and C++ I almost never saw people
using #defaines for constants--let alone putting const modifiers on things
or trying to figure out how to pass by value rather than pass by reference.


This is part of the reason I think that FP is the future.  The default in
FP is immutable.  The default is the good choice not the bad one.  And
that's also part of my point about boilerplate code versus macros.  If the
default on the code that needs to be supplied is relatively intelligent
macros then it's one less thing for the developer to worry with--and most
developers won't spend time fighting language defaults.

This is part of what has always impressed me about Erlang too.  The default
is no shared memory.  We all know that's a heck of a lot more scalable than
what a lot of developers do with shared memory.  An intelligent default is
a great aid to productivity.

--
Onorio




-- 
Onorio Catenacci

http://onor.io
http://www.google.com/+OnorioCatenacci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160307/1cf145a2/attachment.htm>