| Author |
Message |
|
| sean.hinde at mac.com |
 Posted: Mon Oct 13, 2003 10:23 am |
 |
|
|
Guest
|
Hi,
An observation from the trenches.
There are huge problems out in the real world getting companies (or
even other departments) to adopt Erlang. One of the arguments in favour
of Erlang has been that it is a "small" language so the overhead of
learning it and, vastly more important, supporting the applications
written in it is small.
This is no longer the case, and from what I see on the mailing list and
in conferences there is a strong push towards adding more obfuscation
to an already large and (for C++ types) confusing language.
Please let us stop this profligate adding of new features otherwise we
will kill the takeup of Erlang stone dead.
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| lennart.ohman at st.se |
| Posted: Mon Oct 13, 2003 10:56 am |
|
|
|
Guest
|
I agree with the previous "speaker".
/Lennart
Sean Hinde wrote:
> Hi,
>
> An observation from the trenches.
>
> There are huge problems out in the real world getting companies (or even
> other departments) to adopt Erlang. One of the arguments in favour of
> Erlang has been that it is a "small" language so the overhead of
> learning it and, vastly more important, supporting the applications
> written in it is small.
>
> This is no longer the case, and from what I see on the mailing list and
> in conferences there is a strong push towards adding more obfuscation to
> an already large and (for C++ types) confusing language.
>
> Please let us stop this profligate adding of new features otherwise we
> will kill the takeup of Erlang stone dead.
>
> Sean
>
--
-------------------------------------------------------------
Lennart Ohman phone : +46-8-587 623 27
Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735
Sehlstedtsgatan 6 fax : +46-8-667 8230
SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman_at_st.se
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Mon Oct 13, 2003 10:56 am |
|
|
|
Guest
|
> There are huge problems out in the real world getting companies (or
> even other departments) to adopt Erlang. One of the arguments in favour
> of Erlang has been that it is a "small" language so the overhead of
> learning it and, vastly more important, supporting the applications
> written in it is small.
>
> This is no longer the case, and from what I see on the mailing list and
> in conferences there is a strong push towards adding more obfuscation
> to an already large and (for C++ types) confusing language.
>
> Please let us stop this profligate adding of new features otherwise we
> will kill the takeup of Erlang stone dead.
As I feel hit by that  I am compelled to answer.
My goal would be to make Erlang _better_, which in some cases might mean
"'bigger', but 'easier'" or "'bigger', but 'faster to develop in'". It's not
"add features just for the fun of it".
I am very much aware about the situation Erlang is in, being both commercial and
open-sourced, and I am certain that it's very difficult to keep the balance.
Well, not really - I suppose if there's a real conflict, the paying customers
will always win. Discussing about enhancements can't hurt, I think, just because
the OTP team is (and needs to be!) quite conservative when it comes to new
stuff.
On the other hand, saying "let's stop any development of the language, it's good
enough as it is" is in my humble opinion at least as bad as bloating Erlang just
for the sake of it.
If Erlang will gain terrain in the commercial area, then it will become harder
and harder to change anything, because there will be many more paying customers.
If we see something that can be improved, the proper timing to do it is as soon
as possible.
Maybe the experimental stuff should be moved to a parallel development branch,
as it was already proposed before? It doesn't feel good about saying that...
Just some 2 cents rambling 
/Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| sean.hinde at mac.com |
| Posted: Mon Oct 13, 2003 11:34 am |
|
|
|
Guest
|
>
> My goal would be to make Erlang _better_, which in some cases might
> mean
> "'bigger', but 'easier'" or "'bigger', but 'faster to develop in'".
> It's not
> "add features just for the fun of it".
>
> I am very much aware about the situation Erlang is in, being both
> commercial and
> open-sourced, and I am certain that it's very difficult to keep the
> balance.
> Well, not really - I suppose if there's a real conflict, the paying
> customers
> will always win. Discussing about enhancements can't hurt, I think,
> just because
> the OTP team is (and needs to be!) quite conservative when it comes to
> new
> stuff.
>
> On the other hand, saying "let's stop any development of the language,
> it's good
> enough as it is" is in my humble opinion at least as bad as bloating
> Erlang just
> for the sake of it.
Perhaps I should clarify slightly more than I did. I am not arguing for
not changing anything. The bit syntax is something so awesome to behold
and simplifies so much that is core to the Erlang problem domain that I
totally approve of the decision to add that.
My concern is of adding new features which are a bit tweaky, language
researchy which do not contribute to the singular vision of Erlang,
which to me is all about building massive systems which are
maintainable by non "CS genius" people who can be trained in the
language in a week.
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| mike at erix.ericsson.se |
| Posted: Mon Oct 13, 2003 11:34 am |
|
|
|
Guest
|
Sean,
Thanks, I have been shouting this for anout the last four years.
At this stage of Erlang's development, it is far better to live
with what we have got "warts and all". It is easy to add things,
it is impossible to take things away. Continuously adding things to
the language will just land us with a monster which nobody will
addopt.
/mike
In article <219ABE6A-FD67-11D7-8668-000A95927CCE_at_mac.com>,
sean.hinde_at_mac.com (Sean Hinde) writes:
|> Hi,
|>
|> An observation from the trenches.
|>
|> There are huge problems out in the real world getting companies (or
|> even other departments) to adopt Erlang. One of the arguments in favour
|> of Erlang has been that it is a "small" language so the overhead of
|> learning it and, vastly more important, supporting the applications
|> written in it is small.
|>
|> This is no longer the case, and from what I see on the mailing list and
|> in conferences there is a strong push towards adding more obfuscation
|> to an already large and (for C++ types) confusing language.
|>
|> Please let us stop this profligate adding of new features otherwise we
|> will kill the takeup of Erlang stone dead.
|>
|> Sean
|>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Mon Oct 13, 2003 11:43 am |
|
|
|
Guest
|
From: "Sean Hinde" <sean.hinde_at_mac.com>
> My concern is of adding new features which are a bit tweaky, language
> researchy which do not contribute to the singular vision of Erlang,
> which to me is all about building massive systems which are
> maintainable by non "CS genius" people who can be trained in the
> language in a week.
Ah! Then there we agree.
There is one minor point that I'd like to make: discussing about new features
(even tweaky ones) might prove useful anyway. Maybe someone comes up with a
simple way of using an until that point tweaky feature, making it extremely
useful. If I'm not confusing issues, the bit syntax also had some tweaky
ancestors.
[side note]
In my own experience with trying to introduce Erlang to new "markets", the
problem was about not being able to strip down easily the parts that are not
needed (like in my case for example ASN, Corba). It can surely be done (Wings
proves it by distributing a slim Erlang system), but as far as I know it's a
manual job.
[/]
regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Mon Oct 13, 2003 12:38 pm |
|
|
|
Guest
|
> Hi,
>
> An observation from the trenches.
>
> There are huge problems out in the real world getting companies (or
> even other departments) to adopt Erlang. One of the arguments in favour
> of Erlang has been that it is a "small" language so the overhead of
> learning it and, vastly more important, supporting the applications
> written in it is small.
On Mon, 13 Oct 2003, Sean Hinde wrote:
Yes
> This is no longer the case, and from what I see on the mailing list and
> in conferences there is a strong push towards adding more obfuscation
> to an already large and (for C++ types) confusing language.
I think there is a lot of talk here but not much action :-)
Sure there is a lot of talk about things that would be nice, but
this does not mean to say that the language is growing in an
incontrollable manner - I have ofter argued that "If we add something"
we should "take something out" and I think this is still and always
the case.
IMHO Erlang is perceived as being large because the distribution
keeps growing in size - this is because the language and the
applications are not distributed separately - so it becomes very
difficult to distinguished exactly "what is Erlang".
I would very much like to see the distribution split as follows:
1) "The language" + the *minimal set of libraries necessary to
compile and run a simple application.
2) A set of applications
- o -
Now 1) is (roughly) the compiler, the run-time system + *half* of
the modules in stdlib and kernel. This is not large. My earlier
stand-alone Erlang sytems achieved 1) in less than 1.44 MBytes.
2) Is potentially huge
- o -
The Erlang OTP system is actually three things
- The language
- OTP
- A number of applications
But the boundaries are not clearly visible.
I think it would greatly improve things if we could release the
basic language stuff, OTP and the applications separately - so that the"
distinctions become clearer.
/Joe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cyberlync at yahoo.com |
| Posted: Mon Oct 13, 2003 1:15 pm |
|
|
|
Guest
|
--- Mike Williams <mike_at_erix.ericsson.se> wrote:
> Sean,
>
> Thanks, I have been shouting this for anout the last
> four years.
> At this stage of Erlang's development, it is far
> better to live
> with what we have got "warts and all". It is easy to
> add things,
> it is impossible to take things away. Continuously
> adding things to
> the language will just land us with a monster which
> nobody will
> addopt.
Why is it impossible to take something away? If you
give ample warning, say depricating a feature two or
three releases before it goes away, and provide a very
clear migration path to new features it should not be
a problem to remove features. If a client doesn't want
to modify his source he always has the option of not
upgrading past the point where a depricated feature is
removed.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| sean.hinde at mac.com |
| Posted: Mon Oct 13, 2003 1:47 pm |
|
|
|
Guest
|
On Monday, October 13, 2003, at 01:38 pm, Joe Armstrong wrote:
>> Hi,
>>
>> An observation from the trenches.
>>
>> There are huge problems out in the real world getting companies (or
>> even other departments) to adopt Erlang. One of the arguments in
>> favour
>> of Erlang has been that it is a "small" language so the overhead of
>> learning it and, vastly more important, supporting the applications
>> written in it is small.
>
>
> On Mon, 13 Oct 2003, Sean Hinde wrote:
>
> Yes
>
>> This is no longer the case, and from what I see on the mailing list
>> and
>> in conferences there is a strong push towards adding more obfuscation
>> to an already large and (for C++ types) confusing language.
>
> I think there is a lot of talk here but not much action :-)
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.
The questions coming to me are from people who have been on their
Erlang course and simply didn't have time to cover all of the language
syntax.
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| bjarne at cs-lab.org |
| Posted: Mon Oct 13, 2003 1:58 pm |
|
|
|
Guest
|
What an excellent discussion topic
for the after beer session at the coming
Erlang/OTP User Conference !
http://www.erlang.se/euc/03/
CU
Bjarne
----- Original Message -----
From: "Joe Armstrong" <joe_at_sics.se>
To: "Sean Hinde" <sean.hinde_at_mac.com>
Cc: "Erlang Questions" <erlang-questions_at_erlang.org>
Sent: Monday, October 13, 2003 2:38 PM
Subject: Re: Erlang is getting too big
> > Hi,
> >
> > An observation from the trenches.
> >
> > There are huge problems out in the real world getting companies (or
> > even other departments) to adopt Erlang. One of the arguments in favour
> > of Erlang has been that it is a "small" language so the overhead of
> > learning it and, vastly more important, supporting the applications
> > written in it is small.
>
>
> On Mon, 13 Oct 2003, Sean Hinde wrote:
>
> Yes
>
> > This is no longer the case, and from what I see on the mailing list and
> > in conferences there is a strong push towards adding more obfuscation
> > to an already large and (for C++ types) confusing language.
>
> I think there is a lot of talk here but not much action
>
> Sure there is a lot of talk about things that would be nice, but
> this does not mean to say that the language is growing in an
> incontrollable manner - I have ofter argued that "If we add something"
> we should "take something out" and I think this is still and always
> the case.
>
> IMHO Erlang is perceived as being large because the distribution
> keeps growing in size - this is because the language and the
> applications are not distributed separately - so it becomes very
> difficult to distinguished exactly "what is Erlang".
>
> I would very much like to see the distribution split as follows:
>
> 1) "The language" + the *minimal set of libraries necessary to
> compile and run a simple application.
>
> 2) A set of applications
>
> - o -
>
> Now 1) is (roughly) the compiler, the run-time system + *half* of
> the modules in stdlib and kernel. This is not large. My earlier
> stand-alone Erlang sytems achieved 1) in less than 1.44 MBytes.
>
> 2) Is potentially huge
>
> - o -
>
> The Erlang OTP system is actually three things
>
> - The language
> - OTP
> - A number of applications
>
> But the boundaries are not clearly visible.
>
> I think it would greatly improve things if we could release the
> basic language stuff, OTP and the applications separately - so that the"
> distinctions become clearer.
>
>
> /Joe
>
>
>
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vances at motivity.ca |
| Posted: Mon Oct 13, 2003 6:22 pm |
|
|
|
Guest
|
On Mon, Oct 13, 2003 at 02:38:36PM +0200, Joe Armstrong wrote:
}
} I think it would greatly improve things if we could release the
} basic language stuff, OTP and the applications separately - so that the"
} distinctions become clearer.
I could't agree more. The fact that if one were to want to take Erlang
for a test drive that they would find themselves building things with
Java, CORBA, SNMP, etc. is exactly what Sean is warning about.
I think it is important to understand what OTP is (and isn't). This is
difficult for people new to the environment as it is because there are
no clear lines. Having an erlang:spawn and a proc_lib:spawn is just
confusing when you're just trying to learn the language. A core
language distribution would make things much clearer.
As to the addition of new features I wouldn't want to think that we
were going to stagnate. What of try/cond which have been on the way
for a long time? I'd like to see them added.
-Vance
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| sean.hinde at mac.com |
| Posted: Mon Oct 13, 2003 6:50 pm |
|
|
|
Guest
|
On Monday, October 13, 2003, at 07:22 pm, Vance Shipley wrote:
> On Mon, Oct 13, 2003 at 02:38:36PM +0200, Joe Armstrong wrote:
> }
> } I think it would greatly improve things if we could release the
> } basic language stuff, OTP and the applications separately - so that
> the"
> } distinctions become clearer.
>
>
> I could't agree more. The fact that if one were to want to take Erlang
> for a test drive that they would find themselves building things with
> Java, CORBA, SNMP, etc. is exactly what Sean is warning about.
Err, actually it isn't. This is what Joe is worrying about. I am more
concerned about there being so much syntax - wayyy before getting as
far as libraries.
>
> I think it is important to understand what OTP is (and isn't). This is
> difficult for people new to the environment as it is because there are
> no clear lines. Having an erlang:spawn and a proc_lib:spawn is just
> confusing when you're just trying to learn the language. A core
> language distribution would make things much clearer.
But then what would distinguish it from the other 500 languages out
there? This needs a book, or a lightweight way into OTP, not discarding
it.
>
> As to the addition of new features I wouldn't want to think that we
> were going to stagnate. What of try/cond which have been on the way
> for a long time? I'd like to see them added.
To join begin ... end, which I've never figured out the point of? What
was that about Perl - a hundred different ways to achieve the same
thing? If try/cond is a true revolution in clarity and "so obvious it
must be correct" programming, and can replace a couple of other
structures then yes, but otherwise no.
I don't want to see Erlang stagnate at all. I just think we are loading
it down so much it is starting to sink under its own weight.
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| robert.virding at telia.c |
| Posted: Mon Oct 13, 2003 7:29 pm |
|
|
|
Guest
|
----- Original Message -----
From: "Eric Merritt" <cyberlync_at_yahoo.com>
To: <erlang-questions_at_erlang.org>
Sent: Monday, October 13, 2003 3:15 PM
Subject: Re: Erlang is getting too big
> Why is it impossible to take something away? If you
> give ample warning, say depricating a feature two or
> three releases before it goes away, and provide a very
> clear migration path to new features it should not be
> a problem to remove features. If a client doesn't want
> to modify his source he always has the option of not
> upgrading past the point where a depricated feature is
> removed.
Have you ever tried to remove, or change, anything in a distribution.
I think not. It is in principle impossible to make a backwards
incompatible change, no matter how sesnible and approved. I know
I have tried for many years when I was working with it. That is one
reason why the language keeps growing, you can add improvements
but can't remove the old stuff.
We were very restrictive in adding new stuff but some things
slipped through and got a user base before they could be cleaned
up. It's a bit like the urban legend about Make.
Robert
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vances at motivity.ca |
| Posted: Mon Oct 13, 2003 7:34 pm |
|
|
|
Guest
|
On Mon, Oct 13, 2003 at 07:49:55PM +0100, Sean Hinde wrote:
}
} On Monday, October 13, 2003, at 07:22 pm, Vance Shipley wrote:
} >
} >I could't agree more. The fact that if one were to want to take Erlang
} >for a test drive that they would find themselves building things with
} >Java, CORBA, SNMP, etc. is exactly what Sean is warning about.
}
} Err, actually it isn't. This is what Joe is worrying about. I am more
} concerned about there being so much syntax - wayyy before getting as
} far as libraries.
OK, however I believe it has the same effect.
} But then what would distinguish it from the other 500 languages out
} there? This needs a book, or a lightweight way into OTP, not discarding
} it.
I certainly have no interest in discarding OTP! It is OTP which drew me
to Erlang in the first place. By having an Erlang without an OTP I
believe it makes it much clearer what OTP is.
} To join begin ... end, which I've never figured out the point of?
I've used begin before in this sort of way:
init() ->
case catch begin
case foo:init() of
ok -> ok;
_ -> throw(foo)
end,
case bar:init() of
ok -> ok;
_ -> throw(bar)
end,
end of
ok -> ok;
Error -> io:fwrite("module ~w failed to initialize~n", [Module])
end.
That's not really a good example of the "Erlang way" of error handling
however it demonstrates the use of 'begin'.
Good examples are the best way of demonstrating the application of these
things. I think the following is a good one.
For a long time I couldn't figure out what 'if' brought to the table.
It seemed totally redundant with 'case'. Over the years I have used
'if' more and more. A few days ago I wrote the following and was very
happy with the clear expressiveness it achieved:
if
not ConnectionOriented and not SequenceControl -> Class = 0;
not ConnectionOriented and SequenceControl -> Class = 1;
ConnectionOriented and not SequenceControl -> Class = 2;
ConnectionOriented and SequenceControl -> Class = 3
end,
Yes, it could have been written using case:
case ConnectionOriented of
false ->
case SequenceControl of
false ->
Class = 0;
true ->
Class = 1
end;
true ->
case SequenceControl of
false ->
Class = 2;
true ->
Class = 3
end
end,
I think you'll agree the former is much clearer.
-Vance
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| sean.hinde at mac.com |
| Posted: Mon Oct 13, 2003 8:30 pm |
|
|
|
Guest
|
On Monday, October 13, 2003, at 08:56 pm, 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.
I don't think the language is actually that small anymore..
One reason for the training issue is that these people are more and
more likely to find their first job is maintaining code from others. If
there are basic syntax features which can't be fitted in the course it
leads to a sense of "well, what else was left out?", and "will I ever
figure out the whole thing?". This is the feedback I am getting from
our newcomers.
>
> 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!
>
> 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?
Maintenance again, and an increasing danger of making code less
readable.
>
> 3. "Parameterized modules"
> This extension is not even available anywhere yet... it is
> already being taught in courses?
No, but it is a proposal which looks like it could well be on its way.
I could list more examples, but my point is that the accumulation of
features is the problem rather than any individual new feature.
Erlang is really only just getting started in the outside world and its
size is causing problems already.
> PS. On Friday, I sent a mail about something I want added to the bit
> syntax, but it is still unanswered ;-)
I have come across this as well, and I agree with your suggestion.
Sean
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 4
Goto page 1, 2, 3, 4 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
