Various (and almost completely unrelated) questions and opinions

[Thomas Lindgren]

David Gould:
> In the countercase (why is it always C++?), overloading something
> like "+" combined with some overuse of inheritance and a macro or
> two makes it almost impossible to tell what "+" gets resolved to
> without stepping it in a debugger or reading the entire program and
> libraries.

So, what can one say about the Erlang construct "F(X1,X2,X3)"?
A casual reader can not in general see what F is supposed to do.

I think the use of higher-order functions suffers from the same defect
as overloading or objects (esp. with before- and after-methods and
suchlike), namely that it is hard to follow what actually will happen
in the general case. (The benefits may outweigh this disadvantage, but
that's beside the point.)

Well-known idioms (foldl, forall) can be managed, but it's easy to get
lost in a maze of anonymous functions and function-valued parameters.
Conclusion: use carefully.

Apply can occasionally be even worse. I _have_ heard one correspondent
on this list defend the use of sending "some term" across the network,
constructing an atom from it and doing an apply on the result. But not
in public :-)

(The idea of doing apply on dynamically constructed atoms has been
independently rediscovered at least once. In the module
lib/asn1/src/asn1rt.erl in R7B0, we find the following code:

encode(ber,Module,Type,Term) ->
    Call = list_to_atom(lists:concat(['enc_',Type])),
    case catch apply(Module,Call,[Term,[]]) of
       ...
    end;
...

)

			Thomas
-- 
Thomas Lindgren					thomas+junk@REDACTED
Alteon WebSystems