average wrote: [...]

Well, you certainly have the issue of momentum for one part of the explanation. Many are not willing do ditch their old toolset even when a better one is presented.

So the real issue is the order in which toolsets get presented to newcomers to the field.

The other is that the most elegant languages are sometimes those understood by the fewest....

Besides, how do you define "elegant"? I've heard it said, in full seriousness, that BrainF*** is the most elegant language because it is a fully Turing-complete language in only six commands (plus two more for IO).

I can define it quite succinctly: Komolgorov semantic density. Each element of syntax of a language can be seen as a condensing down to its Kolmolgorov ideal the tightest expression of a common programmatic need.

An experience that early computers provided to programmers was that of having to save on code size because memory was too tight; and a lesson from that experience is that gains in information density of code have less to do with local optimization of expressions than with global optimizations in the sense of finding ways to fold apparently different code execution paths into variants of the same. IOW, algorithmic information density is concept overkill, when arguing about the standard representation of empty collections factory calls. And as far as elegance is concerned, I am in fact tempted to argue that the call syntax in list(), set() and dict() has over [] and {} the virtuous side-effect of reminding the reader that a distinct empty collection is made at each call, despite the invariability of the expression. Cheers, BB Completeness is a necessary but insufficient condition (so

BrainFuck is out of the question).

Personally, I see Python as an extremely elegant language, but that elegance is tempered by a very strong dose of practicality and realism. Gratuitously breaking backwards compatibility just so that there is a literal for the empty set is not what I call either practical or realistic.

The breaking of backwards compatibility is in no way gratuitous. It may be demolishing of a long-standing local-maxima, but hardly gratuitous.

Just a few ideas, nothing I'm trying to make a religious war on...

marcos

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

average wrote: [...]

Well, you certainly have the issue of momentum for one part of the explanation. Many are not willing do ditch their old toolset even when a better one is presented.

So the real issue is the order in which toolsets get presented to newcomers to the field.

The other is that the most elegant languages are sometimes those understood by the fewest....

Besides, how do you define "elegant"? I've heard it said, in full seriousness, that BrainF*** is the most elegant language because it is a fully Turing-complete language in only six commands (plus two more for IO).

I can define it quite succinctly: Komolgorov semantic density. Each element of syntax of a language can be seen as a condensing down to its Kolmolgorov ideal the tightest expression of a common programmatic need.

An experience that early computers provided to programmers was that of having to save on code size because memory was too tight; and a lesson from that experience is that gains in information density of code have less to do with local optimization of expressions than with global optimizations in the sense of finding ways to fold apparently different code execution paths into variants of the same. IOW, algorithmic information density is concept overkill, when arguing about the standard representation of empty collections factory calls. And as far as elegance is concerned, I am in fact tempted to argue that the call syntax in list(), set() and dict() has over [] and {} the virtuous side-effect of reminding the reader that a distinct empty collection is made at each call, despite the invariability of the expression. Cheers, BB Completeness is a necessary but insufficient condition (so

BrainFuck is out of the question).

Personally, I see Python as an extremely elegant language, but that elegance is tempered by a very strong dose of practicality and realism. Gratuitously breaking backwards compatibility just so that there is a literal for the empty set is not what I call either practical or realistic.

The breaking of backwards compatibility is in no way gratuitous. It may be demolishing of a long-standing local-maxima, but hardly gratuitous.

Just a few ideas, nothing I'm trying to make a religious war on...

marcos

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas