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.

Except that they don't. Almost everyone agrees about the relative precedence and associativity of the two argument forms of addition, subtraction, multiplication and division, but that's about it.

And then there are the folks who think that multiplication is denoted by a space. They call themselves mathematicians. Don't they know that space is concatenation or ignored?

> One reason is the inherent complexity of a parser for a full programming language.

For some full programming languages maybe. Other languages are so easy to parse that they added support for roman numerals, turing-complete read macros, and other things.

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

It turns out that people aren't all that good either - they're subject to a 7+/-2 rule. Plus, very few people can reliably remember 10 levels of operator precedence.

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

Huh? Apart from some nastiness involving << and >> when C++ templates were introduced, how many programming languages have ambiguous parsings? (Yes, many parse things in ways that some humans find "unintuitive", but that's different.)

http://en.wikipedia.org/wiki/Lojban

http://pinstack.blogspot.com/2008/02/top-7-reasons-to-learn-...

http://www.lojban.org/tiki/tiki-index.php?page=Lojban+Introd...

http://www.xibalba.demon.co.uk/jbr/ranto/

Esperanto is not particularly easy to learn, despite the claims of its founder, so learners devote their time and effort to learning languages with much more return on investment once the language is learned.

To which an answer might be, latin doesn't support certain sounds, can't represent tones... and if it did, it would break chinese language interoperability.

If all languages required you to manage memory as in C I'd wager we'd have many fewer entry-level script hackers. Sure, every program would be lickety-split fast, but the App Store certainly wouldn't have 10,000+ apps.

And if every app were written in Java everything would be very portable but also quite slow. It's all about trade-offs and picking the right tool for the right job.

From what I've heard, programmers at Google put it in the same ballpark as C++.

This brings me to another point.. the choice of programming language often has more to do with image and branding as opposed to actual technical merit.

That's why we keep hearing the same old mantras:

Java -> uncool and slow

C/C++ -> fast

PHP -> hack

Ruby -> cool but slow

Cobol -> for dinosaurs

.. even after the problems are fixed, the image remains. It's pretty hard to change people's perceptions.

OpenOffice.. I'm looking at you! ;-)

The real question would be whether that AST syntax would be better than the language's own syntax. I'm guessing it would be harder to read, since a good syntax for an AST would describe only the semantics of the tree, making it harder to pick out the structure of the language itself.

edit: I guess what I'm really asking is there someway in lisp to make a construct that would look just like call/cc? If you could then that's just a feature difference, but if you can't I would agree that's a syntactical difference.

...and if you have the same syntax for all languages then what is the difference? All languages would just be extensions of the same basic language if the syntax is the same.

It is a good question though. Why have more than 3 or 4 programming languages at all?

What about a minimalist subset of Python with curly braces instead of indenting? I think I'd actually like that language. Add an easy mapping to Python libraries, and you're done. $1000 is still a bit on the low end for that, but $3000 would seem quite reasonable.

I will give one example of the tens upon tens of issues you will encounter: What's the one true syntax for a type declaration? Then, once you've answered that, how does that one true syntax manifest in Python/Perl/Javascript?

In general, there seem to be a plethora of values which can be considered in choosing the syntactic form of a language: aesthetics, productivity, tradition, etc. Having different syntax between languages allows different niches for languages within these values not to mention allowing the possibility of great innovations which could improve the experience of programming. Seems unlikely that any current language has the optimal syntax with respect to maximizing all these values and hence it seems foolish to cut off innovation.

This strikes me as a bizarre statement. What's more universal than "echo" and "$", which are found in nearly every UNIX shell? UNIX has always been the backbone OS of the Internet, thus a language designed specifically for that purpose would naturally bring along some of those conventions common to administrators experience. (Technically, it probably happened this way in PHP because of the restraints of the way PHP began, but that's not to say $ and echo wouldn't have been natural choices, even if PHP had been more ambitious early on.)

There are many things to complain about in PHP, but these two conventions were not invented for or by the PHP developers.

I get your point, of course...but when you use examples like this, picking on what is very likely the most popular language in the world for developing web applications, it just makes me think you're really saying, "Why does PHP suck?"

Why doesn't Ruby use PHP syntax? After all, if we're going to agree on syntax, shouldn't the one that the largest number of people are already fluent in be the one we choose? Should we go back to earlier languages? Should Python have gone with C-like syntax, like Perl, since C syntax is far more common? Who decides what the right syntax is for all languages to converge on?

I think I have to conclude your question is invalid.

I think the different syntaxes help you (or at least me) switch contexts and remember what language I'm using.

Also, why don't we all just use one operating system for everything, have one kind of coffee, and eat one perfectly balanced meal all the time?

The question was "If they did have the same syntax, would they be different languages?"

I replied: "Yes, they would be different because their semantics would be different"

I never said it would be a good thing. And by stretching your analogy to the territory of food it only becomes weaker (with food diversity is a goal by itself). Also it can be argued that using the same operating system for the vast majority of tasks is desirable.

I wanted to a) show how "one true syntax" would in itself be challenging and b) explain the utility that diversity has by analogy.

I agree that for most tasks, using a POSIX compliant unix-like system will suffice, but that's as much ground as I'm willing to concede on that point (for now ;)

Thus, everyone who gets programming and is exposed to lisp becomes a lisp programmer,

and people who suck at programming are left out.

True. But the Lisp programmer would reply that you need the things only Lisp can do in most non-trivial programs.

If you don't need the things that only Lisp can do, there's not as much of a reason to use it.

This is not an unreasonable thing to say, yet I'm skeptical. The problem is that a lot of the things that are natural to do in language X just wouldn't occur to you in language Y. I think this is a big problem with the way people compare programming languages. I've been meaning to write a post about it sometime.

Not that I completely agree with the GP's point.

No you can't. In fact, that's precisely what you can't do.

(Unless you're talking about writing a Lisp interpreter... but then your Lisp programs themselves would still be written in Lisp.)

No, but close. They were designing a language for other people who did. The original intention with Dylan was to create a Lisp that was made more accessible for mainstream programmers.

Ditto Guy Steele on Java: "we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

I didn't know that Dylan was considered a LFM rather than a LFSP by its creators, but I do know that at least of them gets s-expressions and still thinks they're a bad idea. See Dave Moon's suggestion: http://www.archub.org/arcsug.txt