[erlang-questions] Erlang4Android

[Richard O'Keefe]

On 20/01/2013, at 1:30 PM, Evan Miller wrote:

> If folks don't like pmods, -extends(), and error_handler, than ban them from your organization.

How, exactly?

I'm reminded of what we used to be told about PL/I: sure it's a complicated language
with all sorts of traps for young players but if you don't use them they won't hurt
you.  Problem is, you could use them by accident.  Now parameterised modules could
not be used by accident, but the *implementation* of them could, and that hurts
everyone.  -extends is pretty much a solution in search of a problem (there's not
much you can do that way you can't do with -include and a little thought); you can't
use it by accident, but that doesn't mean you can't run into the *implementation* of
it by accident.  And again with the error handler: error handling machinery always
limits the freedom of compilers to transform your programs because they have to be
able to (re)construct the information the error handler is expecting to see.

If you can tell me the erlc command line switch that will banish
parameterised modules, extends, and explicit use of the error_handler,
I shall be very happy to use it.

> Why is it so important to people to prevent other developers from using them?

Because there is no feature that is not a limitation on something else.
TANSTAAFL.

> I love Erlang, but sometimes I feel oppressed by zealous Puritanism in the community.

It's not Puritanism.  People distrust these things each for their own
feature-specific reasons, not simply because they are features.
Let me quote Oliver Cromwell:  consider it *possible* that you *may* be wrong.
What *good* reasons might people who disagree with you about these features have?

Let's take one example from the past.

Way back when I was still at RMIT I was doing some work on trying to
derive properties of functions.  Not a type system as such, but an
effects system.  At that time, Erlang didn't have anonymous functions.
Then *pow*, suddenly it did.  And all my work became so much junk.
Yes, anonymous functions are a very handy feature, BUT they were ALSO
a huge limitation on what I could easily discover.  This was work that
*would* have allowed user-defined functions in guards.

If anyone had been interested in my opinion back then, I would have
pressed for an extended version of list comprehensions in preference
to anonymous functions, because I could have analysed that.

As for parameterised modules, I've wanted module parameters for a long
time for something else entirely:  automatic logic-programming-style
configuration.  Maybe nobody else wants that; my point is that we cannot
have BOTH.  There is not feature that is not a limitation.

I have written enough OO code in enough languages to be painfully aware
that -extends, whatever its merits, makes code significantly less readable
and quite a bit harder to maintain.  (See "Fragile base class problem.")

There comes a point where throwing new features at a language is a bad
idea and it's time to stop and redesign from the beginning, possibly
keeping the VM backwards compatible.  Java is pretty much at the point
where there are enough good ideas to make a coherent usable language but
that language would not be Java.