I don't suppose there's and Erlang 3000 project in the works?
The Python people set out to create Python 3000, throwing backwards compatibility out the window in favour of fixing language and library design errors.
I mentioned earlier the variety of ways that the Erlang libraries signal returning a value or not. Some examples:
proplists:get_value(Key, List) -> undefined | Value
All these operations on standard ADTs are roughly equivalent, and yet they have different or conflicting naming conventions, different return value protocols, and different orderings of their arguments.
While ets:lookup and dets:lookup return a tuple, one of whose members is the key, gb_tree:lookup return the value of a {key,value} pair.
gb_tree:lookup, dict:find and proplists:get_value all perform the same operation, and though the return value protocol is different in each case, at least the arguments are the same.
The key asset for any well designed language or library is learnability, which comes from regularity, i.e. having learned something in one situation, one can apply that knowledge to similar situation with a high probability of success.
Erlang already does a lot of things differently from other languages, but when every single library module does things differently from the others, well, that's a lot of heterogeneity for a novice to deal with.
I wasted an hour so so tonight trying to figure out a problem that stemmed from proplists having a different argument ordering to ets - I just instinctively assumed they had the same argument ordering, and why shouldn't I? _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://www.erlang.org/mailman/listinfo/erlang-questions
Also I forgot to mention that perhaps it should be called Erlang 2011 because I don't really want to wait until the year 3000 to see it. Or just perhaps Erlang2 and drop the pseudo years which never hold anyway.
What you suggesting can be divided into 2 tasks: 1. New language spec 2. New standard library
As there is a lot of legacy products in today's Erlang/OTP, I guess OTP team's first priority is backward compatibility. I heard, that some attempts to fork the language failed. It looks like each module in stdlib was developed by people from different galaxies :-) One of the problem, that Erlang is dynamicaly-typed language, and module writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, error, etc.), when in statically-typed language you return boolean, with only two known values.
Anyway, you can see here the difference between languages, which require some discipline and those which don't. It very hard, to write libraries like this in Java or C++ (but very easy in Perl or other scripting languages).
I think, the best path to approach this problem, is to start writing new stdlib, the basis of which will be gen_collection behaviour (something like STL in C++ for Erlang). For simplicity it will be just common API wrappers for various collections ADTs in Erlang stdlib. Even if there are will be some performance loss, it will make code much more readable and maintainable.
The next step is to add to gen_collection data-parallel APIs (in the style of plists module). By data parallel constructs I not only mean, usual map / fold / filter, but also various methods, like lookup for multiple keys or adding multiple key/value pairs by single function call, or operating coillections as a whole.
For this you do not need OTP team involvent, just start open source project on github.
> I don't suppose there's and Erlang 3000 project in the works?
> The Python people set out to create Python 3000, throwing backwards > compatibility out the window in favour of fixing language and library > design errors.
> I mentioned earlier the variety of ways that the Erlang libraries > signal returning a value or not. Some examples:
> proplists:get_value(Key, List) -> undefined | Value
> All these operations on standard ADTs are roughly equivalent, and yet > they have different or conflicting naming conventions, different > return value protocols, and different orderings of their arguments.
> While ets:lookup and dets:lookup return a tuple, one of whose members > is the key, gb_tree:lookup return the value of a {key,value} pair.
> gb_tree:lookup, dict:find and proplists:get_value all perform the same > operation, and though the return value protocol is different in each > case, at least the arguments are the same.
> The key asset for any well designed language or library is > learnability, which comes from regularity, i.e. having learned > something in one situation, one can apply that knowledge to similar > situation with a high probability of success.
> Erlang already does a lot of things differently from other languages, > but when every single library module does things differently from the > others, well, that's a lot of heterogeneity for a novice to deal with.
> I wasted an hour so so tonight trying to figure out a problem that > stemmed from proplists having a different argument ordering to ets - I > just instinctively assumed they had the same argument ordering, and > why shouldn't I? > _______________________________________________ > erlang-questions mailing list > erlang-questi...@erlang.org > http://www.erlang.org/mailman/listinfo/erlang-questions
> One of the problem, that Erlang is dynamicaly-typed language, and > module > writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, > error, > etc.), when in statically-typed language you return boolean, with > only two > known values.
> Anyway, you can see here the difference between languages, which > require > some discipline and those which don't. It very hard, to write > libraries like > this in Java or C++ (but very easy in Perl or other scripting > languages).
Quite honestly, I would say that the situation is worse in Erlang than most dynamically typed languages, because of:
a) the existence of symbols, b) the lack of a canonical undef or nil object, and c) to a lesser degree, the strangeness of the if statement
Fortunately hungarian notation is just a convention, otherwise if it was in someway included in Erlang2 (or 3000) there would very soon be a new project Erlang 3, started by me. It sucks greatly.
I must honestly say that I am not that convinced in having too many generic libraries. I think that generally you know, and need to know, the representations you use. They are not equivalent even if you hide them behind a interface which tries to make them so. This is not to say that you can't make the interfaces similar if it is possible.
I see now in your nabble link you suggest something along these lines.
There are many levels in an language definition/standard library and a big problem is working out where the limits are. What goes in the language and what is part of a library.
The main problem is not the actual coding, well perhaps if you intend to rewrite the erlang VM, but working out the design and the design principles. Once these are done the coding is not that bad.
> What you suggesting can be divided into 2 tasks: > 1. New language spec > 2. New standard library
> As there is a lot of legacy products in today's Erlang/OTP, I guess OTP > team's first priority is backward compatibility. I heard, that some > attempts > to fork the language failed. > It looks like each module in stdlib was developed by people from different > galaxies :-) > One of the problem, that Erlang is dynamicaly-typed language, and module > writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, error, > etc.), when in statically-typed language you return boolean, with only two > known values.
> Anyway, you can see here the difference between languages, which require > some discipline and those which don't. It very hard, to write libraries > like > this in Java or C++ (but very easy in Perl or other scripting languages).
> I think, the best path to approach this problem, is to start writing new > stdlib, the basis of which will be gen_collection behaviour (something like > STL in C++ for Erlang). For simplicity it will be just common API wrappers > for various collections ADTs in Erlang stdlib. Even if there are will be > some performance loss, it will make code much more readable and > maintainable.
> The next step is to add to gen_collection data-parallel APIs (in the style > of plists module). > By data parallel constructs I not only mean, usual map / fold / filter, but > also various methods, like lookup for multiple keys or adding multiple > key/value pairs by single function call, or operating coillections as a > whole.
> For this you do not need OTP team involvent, just start open source project > on github.
> Zvi
> Damien Morton-2 wrote:
> > I don't suppose there's and Erlang 3000 project in the works?
> > The Python people set out to create Python 3000, throwing backwards > > compatibility out the window in favour of fixing language and library > > design errors.
> > I mentioned earlier the variety of ways that the Erlang libraries > > signal returning a value or not. Some examples:
> > proplists:get_value(Key, List) -> undefined | Value
> > All these operations on standard ADTs are roughly equivalent, and yet > > they have different or conflicting naming conventions, different > > return value protocols, and different orderings of their arguments.
> > While ets:lookup and dets:lookup return a tuple, one of whose members > > is the key, gb_tree:lookup return the value of a {key,value} pair.
> > gb_tree:lookup, dict:find and proplists:get_value all perform the same > > operation, and though the return value protocol is different in each > > case, at least the arguments are the same.
> > The key asset for any well designed language or library is > > learnability, which comes from regularity, i.e. having learned > > something in one situation, one can apply that knowledge to similar > > situation with a high probability of success.
> > Erlang already does a lot of things differently from other languages, > > but when every single library module does things differently from the > > others, well, that's a lot of heterogeneity for a novice to deal with.
> > I wasted an hour so so tonight trying to figure out a problem that > > stemmed from proplists having a different argument ordering to ets - I > > just instinctively assumed they had the same argument ordering, and > > why shouldn't I? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@erlang.org > > http://www.erlang.org/mailman/listinfo/erlang-questions
2008/11/16 Steve Davis <steven.charles.da...@gmail.com>
> On Nov 15, 6:07 pm, Zvi <ex...@walla.com> wrote: > > What you suggesting can be divided into 2 tasks: > > 1. New language spec > > 2. New standard library
> Of course 1.is vastly harder than 2.
> My estimate is that writing and getting consensus on 1 would indeed > take until 3000AD.
At least! :-) Seriously I don't think you can aim for complete consensus, you will never get it. You need to start out with some form of rationale which lays down the basic ideas/principles for the new erlang, and explains the reasons behind them. This is something which, unfortunately, we never did.
Once this is done it is easier to design and develop the system.
> wrote: > A few opinions from me here... > > a) the existence of symbols, > Atoms are good. Good-er than they may first appear to be. > > b) the lack of a canonical undef or nil object, and > Nulls are bad. Bad-er than they may first appear to be. > > c) to a lesser degree, the strangeness of the if statement > Can't say I found a use for it yet...
2008/11/16 Kevin Scaldeferri <ke...@scaldeferri.com>
> Quite honestly, I would say that the situation is worse in Erlang than > most dynamically typed languages, because of:
> a) the existence of symbols, > b) the lack of a canonical undef or nil object, and > c) to a lesser degree, the strangeness of the if statement
I don't understand your reasons at all:
Why do you want/need an undef or nil object in language where everything has a value? And where you have immutable data?
Many complain about the if *expression* but I don't really understand why it warrants so much interest. I personally find that I don't use it much anyway, and that because I don't *need* to use it. I find that having pattern matching has changed my style of coding. I just checked my code for LFE and I found that where I most use a "tradional" if is is my checker module where I only check and don't produce anything.
I honesty don't see how this can make it difficult to write libraries. I have written quite a few and that was not the problem in writing them.
You have mentioned a very real problem, although some of the things you point out are actually justified. For example ets/dets explicitly handle tuples where one of the elements is the key while dict/orddict/gb_trees work with separate keys and values so a difference here is expected. It is a pity that gb_trees does not have a dict compatible api where it is possible.
That argument ordering is different and that sometimes the thing worked upon comes first, or last, or sometimes even in the middle is unfortunate. The different, or rather inconsistent, ways of indicating success/failure is also unfortunate.
Reworking Erlang to fix many of these errors would probably worth the effort, though it might split the user group. One could also fix the syntax, although making it look more like C#/Java would probably be last on my list of priorities, if it ever got there in the first place. I mean the idea is to look forwards and try and get rid of old blemishes of the past and not import someone elses old crud.
It would also be fun, though I think it would be more difficult than many believe.
> I don't suppose there's and Erlang 3000 project in the works?
> The Python people set out to create Python 3000, throwing backwards > compatibility out the window in favour of fixing language and library > design errors.
> I mentioned earlier the variety of ways that the Erlang libraries > signal returning a value or not. Some examples:
> proplists:get_value(Key, List) -> undefined | Value
> All these operations on standard ADTs are roughly equivalent, and yet > they have different or conflicting naming conventions, different > return value protocols, and different orderings of their arguments.
> While ets:lookup and dets:lookup return a tuple, one of whose members > is the key, gb_tree:lookup return the value of a {key,value} pair.
> gb_tree:lookup, dict:find and proplists:get_value all perform the same > operation, and though the return value protocol is different in each > case, at least the arguments are the same.
> The key asset for any well designed language or library is > learnability, which comes from regularity, i.e. having learned > something in one situation, one can apply that knowledge to similar > situation with a high probability of success.
> Erlang already does a lot of things differently from other languages, > but when every single library module does things differently from the > others, well, that's a lot of heterogeneity for a novice to deal with.
> I wasted an hour so so tonight trying to figure out a problem that > stemmed from proplists having a different argument ordering to ets - I > just instinctively assumed they had the same argument ordering, and > why shouldn't I? > _______________________________________________ > erlang-questions mailing list > erlang-questi...@erlang.org > http://www.erlang.org/mailman/listinfo/erlang-questions
> therefore, far better, to change oneself than the language.
I am coming around to that conclusion. I recently understood that whilst I had various initial concerns, I honestly couldn't think of a "better way of doing things" once I'd really thought through all the angles.
For a "certified Java professional", this has all been a bit of a culture shock. So yes -- I too realize that it is (mostly) me that has needed/does need to change.
Erlang/OTP may not have had a cathedral-like architectural plan but it does have something buried in each line of library code that, while intangible, is **much more important** - practical real-world experience. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://www.erlang.org/mailman/listinfo/erlang-questions
On Sun, Nov 16, 2008 at 8:56 AM, Robert Virding <rvird...@gmail.com> wrote: > You have mentioned a very real problem, although some of the things you > point out are actually justified. For example ets/dets explicitly handle > tuples where one of the elements is the key while dict/orddict/gb_trees work > with separate keys and values so a difference here is expected. It is a pity > that gb_trees does not have a dict compatible api where it is possible.
Its also a pity gb_trees isn't simply named trees. The gb_ part is just obscure - why does it matter that the implementation of trees is of the type gb_ but the implementation of dict and set is not. 99% of users simply wont care.
> That argument ordering is different and that sometimes the thing worked upon > comes first, or last, or sometimes even in the middle is unfortunate. The > different, or rather inconsistent, ways of indicating success/failure is > also unfortunate.
One of their library designers, Rico Mariani, had this to say:
The flip side of this is that it must not only be easy to use the API, but it must be easy to use the API in the best possible way. Think carefully about what patterns you offer and be sure that the most natural way to use your system gives results that are correct, is secure against attacks, and has great performance. Make it hard to do things the wrong way.
A few years ago I wrote this: The Pit of Success: In stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail.
True productivity comes from being able to easily create great products— not from being able to easily create junk. Build a pit of success.
> Reworking Erlang to fix many of these errors would probably worth the > effort, though it might split the user group. One could also fix the syntax, > although making it look more like C#/Java would probably be last on my list > of priorities, if it ever got there in the first place. I mean the idea is > to look forwards and try and get rid of old blemishes of the past and not > import someone elses old crud.
Though there were worries that the Python 3000 effort might split the community, that doesn't seem to have happened. Tools have been produced that make porting to py3000 possible, and I understand that the language changes are relatively modest, removing the most glaring of language warts, and regularising and reorganising libraries.
Probably the most useful part of the process is a document like this one: http://www.python.org/dev/peps/pep-3099/ "Things that will Not Change in Python 3000".
My 2c worth - the focus of the effort should be in making the language and libraries more accessible. In the end, languages aren't only selected for utility, but also for learnability. Python has made huge inroads, I think, because its original focus on being a teaching language.
> It would also be fun, though I think it would be more difficult than many > believe.
I wonder. It depends on the scope of the changes. If its mostly a refactoring ....
The Python 3000 process did provoke an orgy of proposals, but if the limits were set by the erlang luminaries early in the process, then perhaps the energies of the community could be better focussed.
On Nov 15, 2008, at 6:46 PM, Robert Virding wrote:
> 2008/11/16 Kevin Scaldeferri <ke...@scaldeferri.com>
> Quite honestly, I would say that the situation is worse in Erlang than > most dynamically typed languages, because of:
> a) the existence of symbols, > b) the lack of a canonical undef or nil object, and > c) to a lesser degree, the strangeness of the if statement
> I don't understand your reasons at all:
> Why do you want/need an undef or nil object in language where > everything has a value? And where you have immutable data?
Perhaps I was overly terse. I was not saying that any of the above are necessarily bad, but simply that they contribute to the situation where there are many modules with interfaces which are similar, but not quite the same. I.e. the complaint in the original email:
> proplists:get_value(Key, List) -> undefined | Value
and the statement that I was responding to, but that you eliminated from the quote:
> One of the problem, that Erlang is dynamicaly-typed language, and > module > writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, > error, > etc.), when in statically-typed language you return boolean, with > only two > known values.
> Anyway, you can see here the difference between languages, which > require > some discipline and those which don't. It very hard, to write > libraries like > this in Java or C++ (but very easy in Perl or other scripting > languages).
I was saying that, contrary to this statement, other dynamic languages do not suffer this particular problem. It seems to me that one reason is that most of these languages have a null/undef/nil entity which is the natural thing to return when a lookup fails. Even in languages like Ruby which also have symbols/atoms, one would never return :error or :none or what have you, because nil is available.
> Many complain about the if *expression* but I don't really > understand why it warrants so much interest. I personally find that > I don't use it much anyway, and that because I don't *need* to use > it. I find that having pattern matching has changed my style of > coding. I just checked my code for LFE and I found that where I most > use a "tradional" if is is my checker module where I only check and > don't produce anything.
With regards to my point (3), what I am saying is that in languages with a "normal" if-statement, one often writes something like:
if (thing = lookup(foo)) { ... do stuff with the thing...
} else {
... it wasn't there
}
Of course, this relies on (a) having an if-statement that works like this, and (b) nil/undef/null being false in boolean context. Neither is the case in Erlang, so one instead tends to use a case, and it doesn't really matter if the return value of lookup is useful in boolean context.
> I honesty don't see how this can make it difficult to write > libraries. I have written quite a few and that was not the problem > in writing them.
I did not say anything of the sort. I was saying that these may be factors that contribute to there not being a single, natural interface for this class of functions.
As you suggest, the 'minimal' change is to wrap the current set of collections and create a set of behaviours to regularise naming. From this a set of library guidelines could be born to guide other efforts in other modules. Can a module have multiple behaviours applied to it? What happens with conflicts, can one function satisfy two or more behaviour requirements?
> What you suggesting can be divided into 2 tasks: > 1. New language spec > 2. New standard library
> As there is a lot of legacy products in today's Erlang/OTP, I guess OTP > team's first priority is backward compatibility. I heard, that some > attempts > to fork the language failed. > It looks like each module in stdlib was developed by people from different > galaxies :-) > One of the problem, that Erlang is dynamicaly-typed language, and module > writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, error, > etc.), when in statically-typed language you return boolean, with only two > known values.
> Anyway, you can see here the difference between languages, which require > some discipline and those which don't. It very hard, to write libraries > like > this in Java or C++ (but very easy in Perl or other scripting languages).
> I think, the best path to approach this problem, is to start writing new > stdlib, the basis of which will be gen_collection behaviour (something like > STL in C++ for Erlang). For simplicity it will be just common API wrappers > for various collections ADTs in Erlang stdlib. Even if there are will be > some performance loss, it will make code much more readable and > maintainable.
> The next step is to add to gen_collection data-parallel APIs (in the style > of plists module). > By data parallel constructs I not only mean, usual map / fold / filter, but > also various methods, like lookup for multiple keys or adding multiple > key/value pairs by single function call, or operating coillections as a > whole.
> For this you do not need OTP team involvent, just start open source project > on github.
> Zvi
> Damien Morton-2 wrote:
> > I don't suppose there's and Erlang 3000 project in the works?
> > The Python people set out to create Python 3000, throwing backwards > > compatibility out the window in favour of fixing language and library > > design errors.
> > I mentioned earlier the variety of ways that the Erlang libraries > > signal returning a value or not. Some examples:
> > proplists:get_value(Key, List) -> undefined | Value
> > All these operations on standard ADTs are roughly equivalent, and yet > > they have different or conflicting naming conventions, different > > return value protocols, and different orderings of their arguments.
> > While ets:lookup and dets:lookup return a tuple, one of whose members > > is the key, gb_tree:lookup return the value of a {key,value} pair.
> > gb_tree:lookup, dict:find and proplists:get_value all perform the same > > operation, and though the return value protocol is different in each > > case, at least the arguments are the same.
> > The key asset for any well designed language or library is > > learnability, which comes from regularity, i.e. having learned > > something in one situation, one can apply that knowledge to similar > > situation with a high probability of success.
> > Erlang already does a lot of things differently from other languages, > > but when every single library module does things differently from the > > others, well, that's a lot of heterogeneity for a novice to deal with.
> > I wasted an hour so so tonight trying to figure out a problem that > > stemmed from proplists having a different argument ordering to ets - I > > just instinctively assumed they had the same argument ordering, and > > why shouldn't I? > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi...@erlang.org > > http://www.erlang.org/mailman/listinfo/erlang-questions
> Fortunately hungarian notation is just a convention, otherwise if it was in > someway included in Erlang2 (or 3000) there would very soon be a new project > Erlang 3, started by me. It sucks greatly.
Down with Hungary and its bloody awful notation.
> I must honestly say that I am not that convinced in having too many generic > libraries. I think that generally you know, and need to know, the > representations you use. They are not equivalent even if you hide them > behind a interface which tries to make them so. This is not to say that you > can't make the interfaces similar if it is possible.
Genericity isn't really possible with erlang. What is possible is regularity. A 'dictionary' behaviour and a 'collection' behaviour would just about cover the various abstract data types. Maybe also an 'ordered' behaviour, and some distinction between set/bag would be useful. I think some kind of iterator/stream protocol might also be needed, but I dont see it used anywhere in erlang, and there might be a good reason for that.
There are many levels in an language definition/standard library and a big
> problem is working out where the limits are. What goes in the language and > what is part of a library.
So lets just focus on the library. Any language changes will likely have to accommodate the current libraries with only minor changes.
> The main problem is not the actual coding, well perhaps if you intend to > rewrite the erlang VM, but working out the design and the design principles. > Once these are done the coding is not that bad.
So, if you were to rewrite the collection classes from scratch - what principles would you follow?
>> What you suggesting can be divided into 2 tasks: >> 1. New language spec >> 2. New standard library
>> As there is a lot of legacy products in today's Erlang/OTP, I guess OTP >> team's first priority is backward compatibility. I heard, that some >> attempts >> to fork the language failed. >> It looks like each module in stdlib was developed by people from different >> galaxies :-) >> One of the problem, that Erlang is dynamicaly-typed language, and module >> writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, >> error, >> etc.), when in statically-typed language you return boolean, with only two >> known values.
>> Anyway, you can see here the difference between languages, which require >> some discipline and those which don't. It very hard, to write libraries >> like >> this in Java or C++ (but very easy in Perl or other scripting languages).
>> I think, the best path to approach this problem, is to start writing new >> stdlib, the basis of which will be gen_collection behaviour (something >> like >> STL in C++ for Erlang). For simplicity it will be just common API wrappers >> for various collections ADTs in Erlang stdlib. Even if there are will be >> some performance loss, it will make code much more readable and >> maintainable.
>> The next step is to add to gen_collection data-parallel APIs (in the style >> of plists module). >> By data parallel constructs I not only mean, usual map / fold / filter, >> but >> also various methods, like lookup for multiple keys or adding multiple >> key/value pairs by single function call, or operating coillections as a >> whole.
>> For this you do not need OTP team involvent, just start open source >> project >> on github.
>> Zvi
>> Damien Morton-2 wrote:
>> > I don't suppose there's and Erlang 3000 project in the works?
>> > The Python people set out to create Python 3000, throwing backwards >> > compatibility out the window in favour of fixing language and library >> > design errors.
>> > I mentioned earlier the variety of ways that the Erlang libraries >> > signal returning a value or not. Some examples:
>> > proplists:get_value(Key, List) -> undefined | Value
>> > All these operations on standard ADTs are roughly equivalent, and yet >> > they have different or conflicting naming conventions, different >> > return value protocols, and different orderings of their arguments.
>> > While ets:lookup and dets:lookup return a tuple, one of whose members >> > is the key, gb_tree:lookup return the value of a {key,value} pair.
>> > gb_tree:lookup, dict:find and proplists:get_value all perform the same >> > operation, and though the return value protocol is different in each >> > case, at least the arguments are the same.
>> > The key asset for any well designed language or library is >> > learnability, which comes from regularity, i.e. having learned >> > something in one situation, one can apply that knowledge to similar >> > situation with a high probability of success.
>> > Erlang already does a lot of things differently from other languages, >> > but when every single library module does things differently from the >> > others, well, that's a lot of heterogeneity for a novice to deal with.
>> > I wasted an hour so so tonight trying to figure out a problem that >> > stemmed from proplists having a different argument ordering to ets - I >> > just instinctively assumed they had the same argument ordering, and >> > why shouldn't I? >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questi...@erlang.org >> > http://www.erlang.org/mailman/listinfo/erlang-questions
A natural question at this point (at least for me) would be: Why do we want to change the language? I'll dare to put forward a view that claims that there is *nothing wrong with ERLANG*. My justification for this view is as follows:
If you use ERLANG as much as I do, sooner or later you have to realize that it is far easier. well, if not easier than - profitable and more useful; therefore, far better, to change oneself than the language. It is true: whenever I hit the wall, all I had to do was to think a bit differently (*) and I'd be on a high ground again.
So, why indeed do we try to change the language? If the goal is to make it a better, we should stick to what worked so far - gradual evolution as opposed to change-the-syntax-and-everything-but-vm-revolution.
If the purpose is to gain the "masses" (**), as I understood it once, well, no amount of changes to the language will help. For that one just need money and marketing - hence lots of money.
BR.
V.
(*) Mind you, in some other environments (say, languages, run-times, etc.) no amount of thinking differently would help.
(**) Or critical mass, which is, IMHO, just euphemism for masses.
----- Original Message ----- From: Robert Virding To: Steve Davis
Cc: erlang-questi...@erlang.org Sent: Sunday, November 16, 2008 4:51 AM Subject: Re: [erlang-questions] Erlang 3000?
2008/11/16 Steve Davis <steven.charles.da...@gmail.com>
On Nov 15, 6:07 pm, Zvi <ex...@walla.com> wrote: > What you suggesting can be divided into 2 tasks: > 1. New language spec > 2. New standard library
Of course 1.is vastly harder than 2.
My estimate is that writing and getting consensus on 1 would indeed take until 3000AD.
At least! :-) Seriously I don't think you can aim for complete consensus, you will never get it. You need to start out with some form of rationale which lays down the basic ideas/principles for the new erlang, and explains the reasons behind them. This is something which, unfortunately, we never did.
Once this is done it is easier to design and develop the system.
> As you suggest, the 'minimal' change is to wrap the current set of > collections and create a set of behaviours to regularise naming. From this > a > set of library guidelines could be born to guide other efforts in other > modules.
Yes, this is what I proposed.
This is the fastest way to start prototyping new stdlib, for the begining I propose to use new module names (i.e. for example gc_set instead set, gc_dict, instead dict , etc., where "gc_" perfix mean gen_collection), i.e. to not interfere with legacy code.
I have 2 ideas here:
1. Maybe there is a reason from the beginning to have 2 collection behaviours, like in Python: a. gen_mapping (for dict, ets, dets, i.e. any key=>[value] mapping, maybe even funs) b. gen_sequence (for list, tuple, array, set, ordset, etc.). In some languages you may use index as a key - so maybe everything can be gen_mapping?
2. Use parametrized types, to specify ADT implementation details / policies. For example in case of distributed/SMP map/fold , using something as plists "malt" (i.e. how to split tasks between cores/nodes or just use sequential code - this is just example).
Zvi
Damien Morton-2 wrote:
> Can a module have multiple behaviours applied to it? What happens with > conflicts, can one function satisfy two or more behaviour requirements?
On Sun, Nov 16, 2008 at 11:33 PM, Zvi <ex...@walla.com> wrote:
> This is the fastest way to start prototyping new stdlib, for the begining I > propose to use new module names (i.e. for example gc_set instead set, > gc_dict, instead dict , etc., where "gc_" perfix mean gen_collection), i.e. > to not interfere with legacy code.
> I have 2 ideas here:
> 1. Maybe there is a reason from the beginning to have 2 collection > behaviours, like in Python: > a. gen_mapping (for dict, ets, dets, i.e. any key=>[value] mapping, maybe > even funs) > b. gen_sequence (for list, tuple, array, set, ordset, etc.). In some > languages you may use index as a key - so maybe everything can be > gen_mapping?
I think that what defines sequence is an iterator protocol rather than indexing.
sequence module could then be a behavior AND a set of functions for operating on iterators (map, fold, ets)
> 2. Use parametrized types, to specify ADT implementation details / > policies. > For example in case of distributed/SMP map/fold , using something as plists > "malt" (i.e. how to split tasks between cores/nodes or just use sequential > code - this is just example).
Are parametrized types ready for prime-time? Like records, they aren't exactly first-class members of the language, and reading Richards paper on them, he has some concerns about performance.
"damien morton" <dmor...@bitfurnace.com> writes: > Is there anything you can do with an if statement that cant be done with a > case statement?
no.
and there is nothing you can do with a 'case' that you can't do with a 'try'.
i think a reasonable goal for Erlang v2 (Etwo?) is to get rid of cruft like 'if', 'case', 'catch', 'and', 'or', the old guards etc. and perhaps provide a more consistent API to the libraries (in a new namespace?)
> Though there were worries that the Python 3000 effort might split > the community, that doesn't seem to have happened. Tools have been > produced that make porting to py3000 possible, and I understand that > the language changes are relatively modest, removing the most > glaring of language warts, and regularising and reorganising > libraries.
I don't follow what's going on in the Python community, but just as a counterpoint, there seems like a strong possibility that Perl 6 will split the community. Quite bizarrely, the closer a complete, working implementation gets, the louder some people become about their opinion that it will never be a finished or viable platform.
> I created a forum on Google Moderator for collecting together ideas on > Erlang 3000. > The forum is called Next(Erlang) and can be found at > http://moderator.appspot.com/#15/e=bbc4&t=b355
> Google Moderator is a combination of a discussion group with up/down voting > on particular discussions.
>> I created a forum on Google Moderator for collecting together ideas on >> Erlang 3000. >> The forum is called Next(Erlang) and can be found at >> http://moderator.appspot.com/#15/e=bbc4&t=b355
>> Google Moderator is a combination of a discussion group with up/down >> voting >> on particular discussions.
