[erlang-questions] Improve $handle_undefined_function

[Richard O'Keefe]

On 23/01/2013, at 7:30 AM, Evan Miller wrote:
> 
> Most people on this list seem to care about "big-scale" issues like
> reliability, predictability, processing kajillions of commercial
> transactions, and so forth. I happen to care a lot more about
> "small-scale" issues -- in particular, the programming experience of
> one person just trying to get something to work for the first time and
> having the code look nice.

I care a heck of a lot about small scale usability issues,
and that's precisely why I DISLIKE pmods -extends and so on.
Because I have learned from painful experience that reliability
and predictability ARE small scale usability issues.

The fact that -extends as currently conceived destroys our
ability to know what a module exports, well, words fail me.
It's such a *TERRIBLE* thing to do to plain simple-minded
programmers like me that it makes me want to smash things in
anger.  I make mistakes *all the time*, and not being able to
ask "have I actually defined everything that is either called
or exported" any more, well, how does THAT help me?

Let's face it, I can get pretty close to the effect of
-extends WITHOUT it.  I happen to have a small Erlang file
that lets me type
   > export_from:module(foobar).
in an Erlang shell and get an export list and a bunch of
glue definitions that I can paste into a source file.
It's careful to exclude module_info/[0,1], and it uses
the io module rather clumsily.  And it's under 50 SLOC.

Writing a parse transform that gets the info from a .beam file
would be harder, but easier for a programmer to use.  I'd rather
not do that, because simply saying "re-export EVERYTHING" is too
dangerous.

    -export_from(Module, Functors).

which I think I first proposed back in about 1996, permits so
much more checking, and makes life SO much nicer for the small-
scale programmer, that the contrast is almost dizzying.

> I think that's ultimately where innovation
> comes from -- one person experimenting around, seeing if things work,
> and not caring whether it's production-ready or fit to be seen by
> anyone.

Right.  And *not* from shoving half-baked ideas out the door
too early.  Quintus did that once, and ever since Prolog programmers
have been using an I/O approach that was significantly inefficient and
clumsy compared with what we _could_ have had if the ***** who shoved
it out the door had asked around the company if anyone had a better
idea.  The botch even made it into the standard!  (Heck, it even got
copied into Erlang...)

> For example, Erlang is missing one feature found in every other
> language that I've used that is missing from Erlang. It's the ability
> to write:
> 
>   Person.name

That's why Joe Armstrong and I have both proposed essentially the same
data structure (in my case, complete with details of how it can be
implemented and actual measurements from a pilot implementation in a
micro-VM) many years ago.

However, I would point out that this feature requires EITHER
a static type system (Pascal, C, C++, Oberon, Java, C#, &c)
OR a run-time search to find where the field is.

>  Every other language I can think of has something
> like this,

There are vastly more languages than you appear to be aware of.
The trick is to make something like this
 - work EFFICIENTLY
 - WITHOUT a strong static type system.

> person.name(). I wonder how many potential Erlang programmers moved on
> to something else because they couldn't find this very simple language
> construct while they were playing around with Erlang for the first
> time.

Only the hard-of-thinking who were unwilling to learn a new way to
program.
> 
> Thanks to Pmods and some code generation, I was able to come up with
> what I felt was acceptable alternative in Erlang: Person:name().

Did you ever measure how long that took?
Compared with Person#person_name?
Here's a hint:  if you are sick of having programs
run too fast, I've some old machines I could sell you.
There are easier ways to go slow than abusing the language.

Erlang is *NOT* an object oriented language.
That's deliberate:  the inventors of Erlang were well aware of OO
and chose not to use it.

If you try to use Erlang as if it were an object oriented language,
you are wasting your time.  F# will do a _much_ better job of
satisfying you, and it's a perfectly fine language available under
Mono as well as .NET.