No matter how much you internalize the syntax of language X, as the sheer number of syntactic structures in the language increases, the higher the likelihood you’ll misread something.

If we had better tools, we wouldn’t necessarily be limited to just one user-facing syntax for a language. The syntax could simply be a preference in the tools. My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities.

Is that not all programming languages. Practically have identical syntax for the problem they are solving. The thing which differs is “standard” libraries, which is not part of the language but a side effect of.

The answer is that syntax is just the tip of the iceberg. Even ignoring major language differences (garbage collection, static vs. dynamic typing, lexical vs dynamic scoping, eager vs. lazy, threads vs. coroutines) there is an incredibly long list of very detailed semantics that you probably don't even realize you're dealing with when you move from one language to another. For example:

  - in a complex inheritance hierarchy, which method is selected for a.b?
  - how much precision do numeric types have?
  - what happens when numeric types overflow?
  - what order are arguments evaluated in?
  - what happens if fewer arguments are passed than were declared?
  - are keyword arguments supported?
  - are default arguments supported?
  - when are default arguments evaluated?
  - are simple types like integer and string classes?
  - can they be subclassed?
  - can they be monkey-patched?
  - will types be implicitly converted?  (ie 1 + "2")?
  - does 0 evaluate to true or false?  what about "0"?
  - are function arguments passed by value or by reference?
  - are values hashed by their identity or by their logical value?
  - what hooks can you define to customize the behavior of your object?

1. Other things matter more. How a language scales to 100 programmers working on 10 million lines over 20 years, say, matters more (in some environments) than the syntax does. Syntax contributes to that. But syntax contributes to that precisely by being pretty vanilla, uninteresting syntax. More, sexier syntax makes a language worse for that environment. (I'm talking about go here. But I could make a similar argument for other languages in other environments.) Syntax matters as a means to an end; the end matters. Syntax where the end is syntax doesn't matter so much.

2. I suspect (and assert without proof) that peoples' brains work in different ways, and that a person finds languages easier or harder as those languages conform or conflict with the way the person thinks. Ruby syntax gives you a headache? And the problem isn't that you just need to learn Ruby better. But for every you, there's (at least one) someone who has the same issue with J/K/APL. And that's fine. People whose way of thinking matches APL should program in APL, and those whose way of thinking matches Ruby should program in Ruby. We don't need one language to rule them all. They each have their target niche and their target audience.

Much worse. I think the problem is magnified by our obsession with languages - overlapping subsets of syntax features that have highly intricate relationships with programming techniques (making certain techniques easier to implement, others-harder, regardless of problem domain).

The only way I could see what you're proposing making sense is if you got the linguist to design a much higher level language that operated on more concrete concepts. Some kind of domain specific language.

It goes even further than that. When I code I instinctively take on the "mannerisms" of the surrounding code. Brace style, indentation, alignment, etc. This is all part of the same mechanism that helps one use the appropriate idioms in the right context.

Some differences really are arbitrary, and could theoretically be merged. Some are historical, e.g. someone worked on Unix for years and thinks in terms of verbs like "echo" because that's what shells used.

But usually, there are very good reasons for any differences.

One reason is the inherent complexity of a parser for a full programming language. It turns out that it's fairly easy to confuse a parser, because they're just not as good as human beings at correctly interpreting the "intent" of a statement. Most languages don't have a reason for being unless they introduce a bunch of unique constructs; and they're lucky if their own constructs can be parsed unambiguously, much less after adding support for extra "standard" constructs from other languages.

Yet another reason is that languages aren't as universal as you may think. For example, what would 'print "hello world"' mean in a makefile...when would the print-out occur? Would languages be allowed to ignore "standard" expressions that they can't logically use, or be forced to invent some interpretation of them?

A final reason is what would happen when languages are embedded in each other, which is even summed up by your example, PHP. If one language is embedded in another, it's a plus that they have different syntax: it clearly separates one from the other. This reduces the risk that you'll have to (for instance) escape or namespace every single name used by the embedded code, to avoid collisions with the surrounding file.