[nbouscal]

No. The math notation that is used across all branches of mathematics is consistent and unambiguous (the notation of formal logic, naive set theory, etc). The only ambiguity typically comes from traversing different branches of the discipline, which is inevitable considering how many branches there are and how deep they go.

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.

[ccdan]

>>No. The math notation that is used across all branches of mathematics is consistent and unambiguous (the notation of formal logic, naive set theory, etc). << Nonsense. Actually, ambiguity starts with basic arithmetic. Take multiplication for example. We have several kinds of notation for it. Which is inconsistent. In the case of juxtaposition, it's ambiguous because two or more juxtaposed letters don't necessarily imply multiplication. And I'm talking about arithmetic only. Then, ambiguity only builds up. Cross product, Dot product & crap.

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

[nbouscal]

You are simultaneously arguing that we should be using a natural language and that the language of mathematics is too ambiguous. I think you have not looked very closely at natural languages.

[ccdan]

A programming language can be created such that it resembles a natural language but it also avoids the ambiguities of that natural language. Anyway, the main idea is that FP languages are way too cryptic and ambiguous, they use too many symbols with multiple meanings which don't make any logical sense at a first glance. If you have to go to great lengths to explain the meaning of a simple symbol, then its use is wrong in a language that is claimed to be general purpose, clear, easy to read and so on. Either that, or the language is not general purpose and/or doesn't have those claimed qualities (clear, etc.) in a general sense.

[nbouscal]

Or, you simply have not learned enough yet to understand the language. Programming languages are not designed to be easy to pick up with no prior knowledge, they're designed to be powerful when used by professionals who actually know what they are doing.

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.

[ccdan]

Or, maybe the language is very poorly designed. There are many programming languages. From Basic to LISP to C to Java to Haskell to ... Brainfuck. Some of them are used in the software industry and some are not. There are many claims about many languages: language x is good because [insert some random ramblings], language y is good because [...] However, no language is adopted by the industry solely based on claims (and btw. I have seen some utterly ridiculous claims made by those who try to promote Haskell.) Every once in a while, some companies try out new languages. Very few such languages get adopted and as you can see functional languages are almost completely absent from the industry. And there's a very good reason for it: they're simply not suitable for producing professional grade commercial software. If it had been otherwise, someone would have figured it out. The funny thing is that the start-ups that try to use them (usually founded by FP advocates themselves) also fail one after another. But some people never learn. Furthermore, many companies forbid the use of functional style or characteristics implemented in certain imperative languages. The code of good, proper lanaguages for general purpose software engineering, is almost self describing! What is unclear should be sorted out quite easily using the documentation.

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

[nbouscal]

Honestly, I'm chalking this up to Poe's Law at this point. Take care.