It's a nice theory but I disagree. Programming languages are really just a poor effort towards a mathematical notation.
There are those adept in theory that can't practice well, but that's because to practice the art means dealing with a plethora of hacks, exceptions and miscellaneous trivia completely unrelated to the core problem at hand.
Personally, I don't think the answer is becoming 'fluent' in handling the exceptions and idiosyncrasies of the chosen language, framework and platform. Rather we need to work on building a notation that provides better abstraction mechanisms.
How is mathematical notation different from a written language like English? It conveys meaning using glyphs, uses nouns and verbs (and even adjectives). It expresses all sorts of ideas. One might even say that math's notation is a poor effort towards English.
Language can be expressive in ambiguous ways, with multiple valid ways to express the same emotion. Notation should be definable, unambiguous, and precise. The fewer ways to express something, the better.
> The fewer ways to express something, the better.
Your last sentence could be rewritten "It is better to express things in as few ways as possible", or "Having fewer ways to express something is better". English, however, allows you to omit the main verb for the causation in a parallel construction, you were able to write it shorter, and with a 3-syllable climax after a pause at the end for effect.
Shouldn't programming languages also provide many different ways to express things?
No, because that makes it harder to understand what it's doing. Remember that programming languages are not learned at a very young age and continuously trained for decades the way natural languages are.
No, because that makes it harder to understand what it's doing.
Without looking at an example of working code, how is it possible to say that one particular phrasing is so obviously better than any other that it and it alone should be allowed to exist?
I appreciate in Perl very much the postfix conditional expression syntax because it exploits the end weight linguistic property and allows me to emphasize the most important part of the statement when the situation warrants. I believe that makes my code clearer because it looks different from the Algol-standard conditional syntax.
> Perl ... allows me to emphasize the most important part of the statement when the situation warrants.
Yes. The ordering of elements in a sentence is its "thematic" structure, just as important in communicating as the "transitive" structure of sentences, i.e the relationship between nouns, verbs, etc. Most programming languages copy the transitive structure of natural languages, but not many allow the programmer to freely choose the thematic structure.
The era of programming languages is only beginning, and perhaps within a generation or two programming languages will be learnt at a young age and continuously trained for decades.
Perhaps there'll only be a small number of languages that people learn, so people will have a "native" programming language in the way people have a native natural language.
The problem is that the language becomes virtually unknowable. Perl has a ridiculous amount of syntax. I am sure that I could find half a dozen lines of Perl code that the average Perl developer would not understand because everyone only knows part of the language.
Who is the average Perl developer? I'm a student. I should probably know less about Perl than a junior Perl programmer - and I know almost all the keywords.
Is simple.wikipedia.org really better than wikipedia.org for the average English speaker? If your only argument is that simpler language lets more people understand, why bother saying words like "unknowable"? Why not say "not knowable"? Isn't it superfluous to have these words in your vocabulary?
Being able to accurately express an idea quickly has it's value.
Do you know all of the operators as well? All of the special variables? A significant portion of the regex syntax? The four different ways to call subroutines and the effects that each method has? The list goes on and on and on.
I work with about a dozen Perl developers and there are only a couple of us that know a significant portion of the language. Problems occur when someone uses a less common piece of syntax and no one else knows what it does. Everyone has their favorite ways to do things and people tend to have very strong preferences. This makes for code that is much more difficult to understand.
English is a far more complex topic. I am not sure where to even begin. I do think that it helps for a group of people to share a common set of language prescriptions.
You could have been easier to understand if you simply said "nope, you're wrong". But instead, you went on for three paragraphs describing your point of view. You even used a word I had forgotten the definition of: "operators" (Yes, I had to look up the exact definition). Yet I understood everything you said with no ambiguousness.
Was this incorrect? Was explaining your point of view inefficient or causing problems in understanding? I think you inadvertently showed how expressive language has enormous benefits, even if people can never understand it 100%.
Having more ways a statement can be interpreted does not make it easier to identify the correct interpretation, so I don't think this is really a reason people have a harder time understanding code or mathematical notation than they do their native language.
And mathematical notation offers plenty of ways to express a given statement (transform with De Morgan's law, contraposition, shuffling and negating quantifiers, etc.).
It is not the superficial appearance, it is the way it is used. Mathematics specifies a particular, limited, well-defined set of actions and relations. It is that character of those 'game rules' that make it mathematical, compared to general language.
There are those adept in theory that can't practice well, but that's because to practice the art means dealing with a plethora of hacks, exceptions and miscellaneous trivia completely unrelated to the core problem at hand.
Personally, I don't think the answer is becoming 'fluent' in handling the exceptions and idiosyncrasies of the chosen language, framework and platform. Rather we need to work on building a notation that provides better abstraction mechanisms.