[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

[Anthony Ramine]

I agree with most of what you said in your mail, except for the part I quoted.

The generic behaviours in OTP are quite usable and what you call boilerplate, I call it being explicit about what is happening. Parse transforms would just confuse the hell out of any beginner, it obfuscates code and doesn’t help.

In my opinion, e2 vs OTP all comes down to convention-over-configuration vs explicitness. I will take the explicitness anytime.

-- 
Anthony Ramine

Le 16 févr. 2014 à 18:44, Garrett Smith <g@REDACTED> a écrit :

> I don't see this coming from today's OTP code. Usability was (clearly)
> never a priority for these modules. e2 tries to wrap this complexity
> and I think does a pretty reasonable job. It could be made easier, but
> I'm inclined to think at that point we're talking about another
> language -- or some serious parse transforms.
> 
> e2 was originally meant to use parse transforms to really dig out from
> under the gen_server/supervisor-spec baggage. But the problem I ran
> into quickly is that there's only so far you can go in simplifying the
> "generic server" API. At a certain point, the programmer loses touch
> with the client/server connection, and you've created an abstraction
> that leaks way too often to be any good. So e2 is now just an API
> wrapper.
> 
> But this is clearly not a priority, even remotely, for most Erlang
> programmers. I honestly don't understand it. If these APIs were easier
> to use, people would use them more often. They'd have canonical Erlang
> programs without a sense they're using some heavy weight framework
> (comparisons to J2EE? really?).