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.

There's no reason to expect a language like English which evolved organically to have an elegant or efficient design.

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]

1: Pellegrino, et al. University of Lyons, 2011 <http://www.ddl.ish-lyon.cnrs.fr/fulltext/pellegrino/Pellegri... 2: There has been some valid criticism made to [1].

The issue is understanding, not transcribing.

The existence of politicians (and politics) proves that it's easy to misunderstand.

I only mentioned that there is a large amount of effective communication the occurs in English. Surely this is not a controversial claim.

False. Even native English speakers have occasional problems communicating.

False. Miscommunication occurs in most pure english interactions but only occasionally is significant and even more rarely actually kills someone.

There is excellent research on text/email communication.

> 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.

Here is a similar abstract: http://pro.sagepub.com/content/56/1/1491.abstract

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.)

> But I think that is an unreasonable definition.

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.

True, and good point.

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.

Agreed. It makes me think of the amazing Guy Steele talk "Growing a Language."

https://www.youtube.com/watch?v=_ahvzDzKdB0

This is less of a problem when you consider that peripheral functions tend to have verbose, descriptive names. Is GeoProjection really fundamentally worse than Geo.Projection? The upper case convention by itself greatly reduces the chance of collisions with user-defined functions and variables.

Yes it is.

Either all of your geography related function start with "Geo" followed by a capital. In that case you're basically using a namespace while reaping none of the benefits. You can't use the namespace to avoid repeating yourself in some local context, you can't rename it, you can programmatically inspect its content, etc.

Either they do not, in that case you have an inconsistent mess.

Ok. So they basically use a namespace. Now, your objection is that the implementation of the builtin functions repeats Geo too much?

As a user, why should I care?

No, that's the weakest advantage, I've cited others. For instance, being able to rename the namespace is very important if you're using third party libraries which may have conflicting names.

Half the reason for Wolfram Language's large standard library is that you should almost never need a third party library of any kind. If there was a third party library that was particularly useful to typical Mathematica use cases, Wolfram would just put it in to the standard library...

& claim the code as their own

Mathematica has hierarchical namespaces (known as Contexts) with backtick as the separator.

PHP has no namespace, inherits many C-functions and is quite popular.

It's easier to recall a function name than recall the namespace and the function name, isn't it? With modern IDEs this is a none issue anyway. Though from my experience with Mathematica 5-7, the language feels a bit weird. Nevertheless it's quite an achivement that WolframAlpha (the AI search engine) runs on Mathematica code.