I personally believe that it becomes hard to have even a programming language overcome cultural learning styles, and programmatic differences, because of nurture vs nature.
We can all program something which results in a similar return value, but overcoming the nurturing the internet provides, becomes an imperative. I'll just offer a reference to avoid personal mistakes in explaining something that relates to how programmers/computer scientists/electrical engineers approach their end results, and why those end results may still differ in the mentality of the individual, or group, outcome of developing A.I. systems: http://en.wikipedia.org/wiki/Ethnolinguistics http://en.wikipedia.org/wiki/Cognitive_anthropology http://en.wikipedia.org/wiki/Cognitive_science The latter probably explains what I mean in more depth than the two formers. On Mon, Mar 31, 2014 at 8:47 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon > <antoon.par...@rece.vub.ac.be> wrote: > > Op 31-03-14 19:40, Ian Kelly schreef: > >> That was an exaggeration on my part. It wouldn't affect my job, as I > >> wouldn't expect to ever actually have to maintain anything like the > >> above. My greater point though is that it damages Python's > >> readability for no actual gain in my view. There is nothing useful > >> you can do with a name that is the U+1F4A9 character that you can't do > >> just as easily with alphanumeric identifiers like pile_of_poo (or > >> куча_фекалий if one prefers; that's auto-translated, so don't blame me > >> if it's a poor translation). The kinds of symbols that we're talking > >> about here aren't part of any writing systems, and so to incorporate > >> them in *names* as if they were is an abuse of Unicode. > > > > Your argument doesn't has much weight. First of all it can be used > > for just restricting names to the ascii range. > > I disagree. Non-ASCII written names are useful to anybody who prefers > not to do all their programming in English. > > > Second of all I > > think a good chosen symbolic name can be more readable than a > > name in a character set you are not familiar with. A good chosen > > symbol will evoke a meaning with a lot of people. A name in a > > character set you are not familiar with is just gibberish to > > you. > > Well, this is the path taken by APL. It has its supporters. It's not > known for being readable. > > >> I don't think the comparisons to decorators and the if-else operator > >> are apt. > > > > I didn't make such a comparison. I just noted the arguments against > > were similar. > > That's the comparison to which I was referring. > > >> First, because while those may degrade readability, they do > >> so in a constrained way. A decorator application is just the @ symbol > >> and an identifier. > > > > And if abused, can totally change the working of your function. There > > is no guarantee that the function returned, has any relation with the > > original function. If that can't be a night mare for readability, > > I don't know what is. > > As Terry Reedy noted, this has nothing to do with the decorator > syntax, so it isn't much of an argument against having such syntax. > > >> The if-else is just three expressions separated by > >> keywords. > > > > Yes but if used unrestrained in arbitrary expressions will make those > > expressions hard to understand. > > I don't disagree. I hardly ever use it myself, certainly only if it > can fit comfortably into one line, which is rare. But it's still > quite limited in syntactic scope. > > >> In the case of arbitrary Unicode identifiers, we're talking > >> about approximately doubling the number of different characters (out > >> of a continuously growing set) that could be used, many of which are > >> easily confused with other characters. Of course the potential for > >> confusion already exists, but that's no justification for aggravating > >> it. > > > > So what if we double the number of different characters? I don't care > > about the number of them, I care about how meaningful they are. And > > as you say confusion is already possible. A good programmer knows > > how to deal with such a possible confusion, that the number of > > cases increases, doesn't need to be a problem for those that care > > about this. > > So tell me then, how would you deal with it? In the case of script > identifiers, it's often not hard to discern from context whether a > particular character is e.g. a Latin h or a Cyrillic һ. Assuming the > original author wasn't being intentionally obfuscatory, if the rest of > the identifier is Cyrillic then the character is probably also > Cyrillic. If it's a one-character identifier, then hopefully the rest > of the module is consistent and you can guess from that. If the > identifier in question is just one symbol though, then you have a lot > less context. > > > > >> Second, at least in the case of decorators, while I don't dispute that > >> they can harm readability, I think that in the majority of cases they > >> actually help it. > > > > But that is not a fair comparison now, is it. What you are doing here > > is comparing actual use, to a worst case doom scenario. > > I contend that there is no scenario with arbitrary Unicode identifiers > where readability is improved. > -- > https://mail.python.org/mailman/listinfo/python-list > -- Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*
-- https://mail.python.org/mailman/listinfo/python-list
