Furthermore, mathematics is all about communication. The language of mathematics exists to codify concepts so that they can be talked about concisely. Being able to say 'group' instead of 'set with an associative binary operation with identities' is essential if you want to be able to build on top of that concept without taking an hour to read one theorem.
The handicap in communication isn't on the mathematics end, it's on your end. You seem to expect them to be able to explain structures to you that took years of work to build by using the same language that you use to talk about sports or social events. The reality is that you are not the target audience of their communication, and they are okay with that. You should be too.
The weirdest assertion that you made is that high-level programming languages ought to be as close as possible to human languages. The two categories of languages exist to communicate fundamentally and widely different groups of concepts. Words represent categories of analogous concepts, and the relevant categories in human life are nothing like the relevant categories in programming. In Haskell, 'functor', 'applicative functor', and 'monad' are highly relevant categories. They pop up everywhere and can be leveraged with great benefit. In human life these concepts are far less common, and thus do not merit words in the common vernacular. Were we to use a programming language modeled on English, we would miss the benefit of these abstractions, trading them for categories like 'dog' and 'car' which have very little practical use in typical programming.
>>>Being able to say 'group' instead of 'set with an associative binary operation with identities' is essential <<< OK, but the word "group" should be used for no other meaning...
>>>The reality is that you are not the target audience of their communication, and they are okay with that. You should be too.<<< As you can see pretty much anyone is the audience of some math and its inconsistency and ambiguity. It just varies the level and the amount of it.
>>>The weirdest assertion that you made is that high-level programming languages ought to be as close as possible to human languages. The two categories of languages exist to communicate fundamentally and widely different groups of concepts. Words represent categories of analogous concepts, and the relevant categories in human life are nothing like the relevant categories in programming. In Haskell, 'functor', 'applicative functor', and 'monad' are highly relevant categories. They pop up everywhere and can be leveraged with great benefit.<<<
False. Computers and software are mainly used to emulate some real world stuff (objects, actions etc.) and to help people with real world stuff in a more automated way. They aren't used too much to prove theorems or some other math stuff. And pretty much no one cares about proving the so called "mathematical correctness" of a program - a concept that doesn't even make sense in most cases. Old misconception among FP advocates, even Dijkstra himself admitted that he was kinda wrong about how computer would evolve and what they'd used for. But the associated misconceptions live on. A language close to human language also helps avoiding errors. That's why you won't see functional languages in critical systems, but rather languages like Ada which is probably the closest programming language to human language. The claims of clarity of FP languages are pretty much at odds with the evidence the real world provides.
If you're going to make the claim that functional languages use ambiguous symbols, you're going to need to back that up with some examples. I find it exceedingly hard to believe that there is any ambiguity in the operators of a statically and strongly typed language like Haskell.
Those "professionals who actually know what they are doing" don't seem to exist when it comes to functional languages. The evidence is the very fact there's not a single piece of important commercial software written in such a language. The question is rather: can such specialists exist? Because I'm afraid they can't exist because the functional approach is fundamentally wrong.
Examples of ambiguity in FP? What is the following line supposed to mean and what part of it suggest anything about that:
a b c
How is ~ an intuitive replacement for minus? How is (* 5 5) supposed to be as clear as 5 * 5 ?
ps. dynamic typing and type inference are two awfully bad things and either of them can lead to trouble in large programs
And yes, I am a "real programmer" and don't use Haskell at work myself (for the run-time performance reasons).
I also disagree overall with your assessment of mathematical notation. But it doesn't really matter because Haskell doesn't actually use any math notation. It does use some math terminology, though, and overall mathematicians are absurdly pedantic about terminology. Mathematicians may not be great at telling jokes at parties (though you may be surprised!), but it's their job to make sure they are writing in consistent and unambiguous ways.
Haskell wasn't created for "most people". It's not some replacement for Python or Ruby, it was designed for formality.
I've tinkered with other functional languages (Erlang, Scheme and Clojure), but Haskell is a stranger beast.
Also, ML? I know OCaml a bit, but according to this comparison: http://adam.chlipala.net/mlcomp/ Standard ML has a "ref" type, which in effect allows mutable state. While it lack a bit of a syntactic sugar for this, OCaml's mutable record fields are implemented in terms of refs, so in the end SML isn't "more functional" in this than OCaml. Also, according to this answer (didn't check specs) SML has at least a WHILE loop: http://stackoverflow.com/questions/818324/loops-in-sml-nj which is typical to imperative languages. OCaml makes no attempt to outlaw side-effect (I suppose SML is similar), it allows them explicitly by introducing functions which return () (unit type), which are called purely for their side-effects. There is even List.iter function, which accepts a function executed for each element only for side-effects. And side-effects are not restricted in any way.
On the other hand Erlang has nothing like that - no loops, no mutable state in the language and it's side-effects are restricted to message passing.
While Scheme and Clojure, too, allow mutable state and non-pure functions, the default is immutable and pure for almost everything. In Racket the most used data-structure, a pair (and lists by extensions) is immutable by default and all the functions working on pairs and lists are pure. There is another type, "mutable pair", which is used to construct mutable lists, but I haven't seen it used yet.
Coq is not even turing complete.
Anyway, I much prefer talking about "functional style" than "functional programming"/"functional languages". If you think that one cannot use monads outside of Haskell - you're wrong. The same applies for lazy evaluation, which is available in many languages as extension or special syntactic construct in the language itself.
EDIT: I realized that parent probably thought of AGDA instead of ADA. And so I just installed it to check it out :)
Edited for fun and grammar!
They were PL researchers. Used to ML, Common Lisp, Ada, and, most importantly, Mathematics and Category and Type Theory.
`data` introduces an algebraic data type, so it makes sense to use data as a keyword. `type` and `newtype`, on the other hand, are programmer's conveniences: both carry no runtime cost, they are not actually part of the semantics of the backend language.
`map` is a function that's really just a specialization of `fmap`. Now, my category theory is a bit weak, but if I'm thinking correctly here, `fmap f` is an endofunctor in the category of functors, and so it makes perfect sense to call "mappable" Functor. There's also "Traversable," which works pretty much like a fully-fledged "mappable" with all extras, but also requires a Functor instance.
Keywords, and idiosyncrasies of a syntactic nature are really just superficial. The actual elegance of the language is its type system. (The actual warts of the language are, for the most part, also in the type system; records for example.) The latter criticism about `mappable` is really just due to the fact that you haven't gotten used to the underlying theory (and I don't blame you, it's hard.) But getting used to it can be rewarding. I'm not saying it's going to make you a better programmer (I'm not necessarily of that opinion,) but it's rewarding in its own right.
Oh, and the difference between data constructors, type names, and, later, kind names (with promotion, since 7.4,) can be confusing. I sometimes find it an oversight that they are not distinguished syntactically, I think that would greatly help most newbies, and sometimes even make things easier to read and understand for veterans, too.