You speak a language with three to six thousand "common" words and over one million total words. English speakers utilize no such hierarchical naming scheme, only practice.
Typical Mathematica notebooks (I won't say "programs") use a fair bit less than one hundred of the common functions, plus a handful of domain-specific functions from that the greater set of five thousand. At any time, you can enter ?FunctionName to access documentation far more comprehensive than most languages offer.
The UpperCaseForStandardLibrary and lowerCaseForYourCode convention actually makes a lot of sense in the context of Mathematica's primary use cases vs traditional software engineering projects. When I'm just trying to solve some problem in Mathematica, using my computer as a bicycle for the mind, I appreciate not having to putz with import statements or avoid name collisions.
And thus, given the large amount of effective communication that occurs in English, there's no reason to expect that there is much of a downside in eschewing this particular language design approach that you propose.
> given the large amount of effective communication that occurs in English
I wasn't aware that anyone thought English was an effective language for communicating. It's horrible. Even native English speakers have problems communicating all the time.
Actually, English has a fairly high entropy/syllables ratio. [1][2]
Also, given that we can infer with decent accuracy what people are saying even in noisy environments, I would say it's really not too bad.
You could do better of course, but in a good spoke natural language you want a good mix of density (for efficient communication) and redundancy (for dealing with environmental variables). Optimizing for one comes at the expense of the other, and English strikes a pretty decent balance. [citation needed]
> Miscommunication occurs in most pure english interactions
Citation needed.
[Edit: On reflection, this statement is probably true, if you define "miscommunication" to be "the message sent is not exactly the same as the message received". But I think that is an unreasonable definition.
I think it is more reasonable to define "miscommunication" as "the message sent is not substantially the same as the message received". If you claim that, I'd like to see your citations.]
I can't find the study I was thinking of which involved the extreme disparity between the sender's self rating for their ability to convey an intent and the receiver's impression.
Note that emotion is also conflated with aspects like priority and whether the response is a criticism or positive acknowledgement which will affect future interactions or even immediate attempts to "repair" non-existent faults.
I personally find it slightly easier to communicate with non-native speakers over email as any bilingual must have more experience handling ambiguous communication.
In working with native speakers in open floor plans, I have seen hilarious results that I would have found all the more hilarious if I were further away from the projectiles and had fully independent finances.
(But I will concede that English is a good language for talking abstractly about subjects that are clearly neutral where it matters little if nuances are misunderstood.)
I don't think unreasonable in the context of this discussion.
When we use English, having a bit of miscommunication is likely harmless, and probably goes unnoticed most of the time. When we write a computer program, we really want the compiler to understand exactly what we mean.
And thus given the large amount of effective websites that are programmed in PHP, there's no reason to expect that there is much of a downside in using this particular design.
Well, PHP is certainly efficient for programming websites. It just comes at the expense of everything else.
Yes, bashing PHP is fun, and yes, I do it all the time. PHP may be a joke, but there are a bunch of PHP websites because PHP is a very, very fast way to program websites, even widely used ones.
If you could program a simple website in Idris in 30 minutes starting from no prior knowledge, then a large amount of websites would be programmed in Idris (and the world would be a much nicer place). Since that's not the case, should we consider Idris a bad language with major downsides? Of course not, that's pointless, since it wasn't a language meant for building websites. PHP, however, is. Saying it has major downsides outside of its niche is somewhat irrelevant.
> PHP is a very, very fast way to program websites, even widely used ones
Sure, and none of that has anything to do with its horrible design decisions and inconsistent naming. This ability to whip up web sites quickly is not something that PHP achieves as the cost bad design, it achieves it despite unnecessarily bad design.
Typical Mathematica notebooks (I won't say "programs") use a fair bit less than one hundred of the common functions, plus a handful of domain-specific functions from that the greater set of five thousand. At any time, you can enter ?FunctionName to access documentation far more comprehensive than most languages offer.
The UpperCaseForStandardLibrary and lowerCaseForYourCode convention actually makes a lot of sense in the context of Mathematica's primary use cases vs traditional software engineering projects. When I'm just trying to solve some problem in Mathematica, using my computer as a bicycle for the mind, I appreciate not having to putz with import statements or avoid name collisions.