Erlang is getting too big

Kenneth Lundin kenneth@REDACTED
Wed Oct 15 16:37:28 CEST 2003


Well I just have to comment on this.
I don't think there are that many new features in the syntax the past 4 
years.

The single most important news is in my opinion the Bit-syntax.

Some of the other features referred to by Sean and others are not at all 
part of the language yet (but some are distributed as experimental).

- The Java style module naming is still distributed as experimental it 
is not supported and should not in my opinion be mentioned for 
beginners. It might be a good idea to make it official but we have not 
decided to do that yet.

- There is ONE syntactic sugar construct regarding records #rec{_ = xx} 
added.

- The new suggested syntactic sugar for type guards "f(I/integer) <-> 
f(I) when integer(I) is not added to the language yet and we have not 
decided that it will.

- There are some additions regarding guards and guard BIFs.

But where are the rest of the new features cluttering the language?
Do you think this is a lot of new things over a 4 year period?
Do you consider the functions in the kernel and stdlib to be part of the 
language? Well I think that is a different discussion.

I think the record syntax and semantics is something to regret. It is an 
important feature to have structured datatypes with names on them but 
not the way records are implemented.

In summary I agree that we should be careful with language extensions 
and I think that we really are.

/Kenneth (from the OTP team at Ericsson)

Kostis Sagonas wrote:
> On Mon, 13 Oct 2003, Sean Hinde wrote:
>  >
>  > I think there is and has been quite a bit of action since the bit 
>  > syntax. Duplicate guards, much new syntactic sugar for record 
>  > operations #rec{_ = xx}, Java style module naming, soon to be more 
>  > syntactic sugar for guards, Parameterised modules.. Some of these new 
>  > features have led to head scratching and questions to me from folks 
>  > here learning Erlang in the last few weeks. I think we *are* in severe 
>  > danger of making the core language "too big".
>  > 
>  > We haven't "taken anything out of the language" to add any of these 
>  > things, and none of them add new capabilities to the language. All of 
>  > them must be understood by anyone learning Erlang, and already they 
>  > cannot all be taught in a week.
> 
> Although I sympathise with Sean's concerns to some extent, I am having
> trouble sharing all his worries.  Erlang is a small language and I fail
> to see why some of the "recently added features" are needed to be taught
> in a course that introduces the language to developers, or scare away
> people.
> 
> Some examples to illustrate my point:
> 
>    1. "Duplicate guards": There is absolutely no need to teach the old
> 	guards.  Simply introduce the new is_* ones!
> 
>     [In fact, this is exaclty the point where the OTP team could have
>      been more agressive in issuing *warnings* about using old guards,
>      so that applications would be forced to upgrade sooner... but I
>      guess they want to be spared the hassle from the (paying) user
>      community. This way, things could even possibly be removed from
>      the language, and there would not even be a need to mention
>      the existence of the old ones.]
> 
>    2. "Java style module naming"
> 	Is this so difficult a concept to grasp? 
> 	If one thinks the answer is NO, then what's the problem?
> 	If the answer is YES, then is there really needed for this
> 	concept to be mentioned to somebody who wants to find out
> 	what Erlang is all about?
> 
>    3. "Parameterized modules"
> 	This extension is not even available anywhere yet... it is
> 	already being taught in courses?
> 
> Is there something I am missing?
> 
> Cheers,
> Kostis
> 
> PS. On Friday, I sent a mail about something I want added to the bit
>     syntax, but it is still unanswered ;-)
> 


-- 
Kenneth Lundin              Ericsson AB
kenneth@REDACTED     ÄT2/UAB/UKH/K
			    BOX 1505
+46 8 727 57 25 	    125 25 Älvsjö





More information about the erlang-questions mailing list