[erlang-questions] Pmods, packages, Unicode source code and column numbers in compiler - what will happen in R16?

[Robert Virding]

Yes, I quite agree. You DO need to experiment with a language, especially with a language like Erlang which has always had a very pragmatic point of view and was developed through evolution. No creation here.

I see that there are two (at least) problems here:

1. People do not realise, or want to realise, that experiments are just experiments and they might be deemed to have failed and be removed. Even if I love them enough other people might not so they disappear. Going hard-line here I would say "tough, that's YOUR problem, we told you it was an experiment".

2. In this case I think they did the wrong thing. However you look at it pmods were the real "thing" being tested and the tuple modules were were just a quick hack to a allow you to test the idea; they weren't, or shouldn't have been considered to have been, a separate thing in their own right. So the choice should have been: pmods yes or no? If no then throw them AND their hack test implementation away. If yes, then keep them and do them properly by creating an opaque data type with a set of well defined ways of interacting with it, and throw away the hack test implementation.

This is how it was done with funs, they originated as a tuple with undefined "stuff" in them and later they were changed to an opaque data type. I don't know if anyone ever seriously tried to use the internal structure of the tuple but if they did they learned the hard way. IMAO this is what should have been with pmods.

I will admit that I would probably not be popular if I did this. But I do believe that this is what you have to do in the long run. Some people on the bleeding edge will get burned, but that is the price you pay for being there. Otherwise you do accumulate crud in your language. And I do see tuple modules as crud while pmods done properly wouldn't have been.

Is there anyone I have managed NOT to rile?

Robert

----- Original Message -----
> From: "Dmitry Belyaev" <be.dmitry@REDACTED>
> Sent: Friday, 19 October, 2012 2:04:14 PM
> 
> What is the point in the experiment if not to allow people use it?
> 
> I see pmods as a way to handle whole abstraction as one object in the
> language.
> 
> For example, in cowboy it is required to store socket and the
> appropriate protocol module. 2 objects that cannot work with some
> another protocol.
> Other libraries create its own absractions to handle the socket as
> some abstract socket that encapsulates underlying protocol like
> lhttpc_sock, ejabberd_socket and I suppose a lot more.
> 
> And pmods might become a standard way to handle such cases.
> 
> --
> Dmitry Belyaev
> 
> On 19.10.2012, at 14:58, Robert Virding wrote:
> 
> > ----- Original Message -----
> >> From: "Devin Torres" <devin@REDACTED>
> >> Sent: Thursday, 18 October, 2012 5:40:15 PM
> >> 
> >> On Thu, Oct 18, 2012 at 3:45 AM, Loïc Hoguin <essen@REDACTED>
> >> wrote:
> >>> Cowboy doesn't use undocumented features. That's one of the
> >>> biggest
> >>> Cowboy
> >>> claim. It protects both the project and its users from bad
> >>> surprises.
> >> 
> >> Missing the point, but okay. The point is: not removing the
> >> feature
> >> affects nobody different today. You can continue to ignore it
> >> forever
> >> and it will never make a difference to your daily life. Removing
> >> the
> >> feature adversely affects some.
> >> 
> >> Instead of removing features, why don't we let the OTP team focus
> >> on
> >> adding features that will make the lives of everyday Erlang
> >> programmers better? Like frames. :)
> > 
> > If you don't remove unused/experimental features then your language
> > will slowly accumulate crud and eventually become a right mess of
> > "features". I haven't got quite as far as removing something every
> > time you add something but close. I think the problem is that
> > people seem to misunderstand the meaning of "experimental" and
> > expect them to remain even if the experiment fails.
> > 
> > Robert
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> 
>