[erlang-questions] Re: Will parameterized modules become an official part of Erlang?

[Garrett Smith]

On Mon, Feb 22, 2010 at 4:53 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
> Garrett Smith writes:
>  > On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson <mikpe@REDACTED> wrote:
>  > > Garrett Smith writes:
>  > >  > > We still have time to ditch them :)
>  > >  >
>  > >  > +1
>  > >  >
>  > >  > I think the concept is fine, but if they take off they're going to
>  > >  > bifurcate Erlang APIs into traditional API modules that take explicit
>  > >  > process refs/state and this other breed that somehow gets by without
>  > >  > them. Yuck!
>  > >  >
>  > >  > IMO, this meme (coupling state and behavior) is way too fundamental to
>  > >  > have two major variants in a language.
>  > >
>  > > The parameters in parametrized modules are no more about state than
>  > > the free variables in function closures ('fun' expressions) are.
>  > >
>  >
>  > Okay.
>  >
>  > Throw in the fact that you can call functions on a module that have
>  > access to these arguments and you have a coupling between these
>  > argument values and functionality. Sorry if "state" wasn't pedantic
>  > enough for you.
>
> I mentioned fun expressions for a reason, namely that they are pretty
> much the same as parametrized modules. Both constructs instantiate
> free variables at runtime, resulting in new first-class runtime values.
> They only differ in scope: one wraps a single anonymous function, the
> other wraps an entire module's worth of functions.

Good point.

> By criticizing this coupling in the case of parametrized modules,
> you're effectively also criticizing fun expressions with free variables,
> aka lambdas, one of the cornerstones of functional programming.

I'm not criticizing it in principle. I have personally chosen to not
use parameterized modules primarily because they make my APIs look
different from the rest of the OTP apps. Secondarily, I'm not a fan of
the "free variables" they hide. And I haven't needed to.

>  > My point is that this pattern is handled adequately without needing
>  > parameterized modules and to have two approaches for something this
>  > fundamental in a language is bad. I've observed practiced Erlang
>  > developers look sideways at mochiweb's Req:respond(...), look confused
>  > for a moment, and then conclude that it must be this unofficial
>  > feature called parameterized modules. What's the point of this? It's
>  > not unlike stumbling on the use of the process dictionary: "ah,
>  > *that's* how they're doing it!" IMO, this should be avoided wherever
>  > possible - and it's very avoidable in the case of parameterized
>  > modules.
>
> I don't know that 'this pattern' and 'this fundamental' refer to, but
> mochiweb/OTP/gen_server/etc are just libraries. They use the Erlang
> language but do not define it. They can invent whatever APIs they like,
> however sane or insane, clear or confusing, old-fashined or bleeding-edge.
> You're not required to use them, and if sufficiently many agree with you
> better APIs will be created and the bad ones will die. End of problem.
>

APIs die? Gosh I've seen not a few, really bad ones, live on and on.

You may then be more comfortable with the range of naming and API
"conventions" used in Erlang than I am. IMO, it makes it difficult to
design an Erlang API because, at times, there's no clear/obvious cue
from Erlang/OTP. It also makes it hard to remember things. There've
been a few rants lately here on this topic.

Of course, this is true of any language/framework/platform - it's
impossible to tightly control every aspect of its evolution. This
isn't even necessarily a problem. But the more "ways of doing
something" there are in a system, the harder it is to learn that
system, generally.

I recognize this is not a universal, incontrovertible opinion :) Some
developers prefer flexibility and like more language features. I tend
to prefer fewer features/options provided I can get the job done.

Garrett