Ask HN: Can someone explain to me why all languages don't try to have the same syntax?
59 comments
In some important cases, languages already have common syntax (such as mathematical operators, regular expressions, and string interpolation such as "\n"). And in those cases, the simplest explanation seems to be: "there was no other sane way to do it".
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.
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.
> In some important cases, languages already have common syntax (such as mathematical operators
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.)
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.)
A better question is why doesn't everyone in the world speak Esparanto.
Because it has to complete with English which is already a world language(at least in the business world)
There is an answer to that question:
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.
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.
Or even, why isn't every language written using the latin alphabet?
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.
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.
Analogy with human languages isn't ideal, because they have almost all grown up organically, whereas programming languages are, to a large extent, designed. The reason that every language doesn't use the Latin alphabet is, amongst others, geographic -- so many others grew up in isolation from the West, they'd never come across that alphabet before. The same isn't really true of programming languages.
The problem with standardization is that you iron out all of the innovations. Certain language constructs are simply better for certain tasks. Lisp is built for recursion so it's great with lists. Object-oriented languages in theory are great for modularity and maintainability. Granted all these aspects have a lot to do with the coder in addition to the language.
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.
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.
I don't mean to be pedantic, but the 'Java is slow' thing simply isn't true anymore. It certainly used to be slow back in the day, but it's actually pretty good these days.
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.
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.
JIT compiled languages are slow to load, because they have to compile each bit of code the first time they run it. That is why Java is known as a slow language, even though it does fine in benchmarks: because loading is the one operation that's slow enough for the user to notice.
Counter-example: LuaJIT (http://luajit.org/luajit_performance.html), largely because the compiler / optimizer themselves are extraordinarily small.
The thing is, even compiled C++ apps are no better when loading a bunch of shared libraries etc.
OpenOffice.. I'm looking at you! ;-)
OpenOffice.. I'm looking at you! ;-)
A lot of java software implementations are still very very slow. Try restarting a tomcat servlet container (web server) for some java web project and then try the same with some apache or django dev server. One takes 10 seconds, the other is done in a blink in of an eye. Look at eclipse/netbeans vs. xcode, swing applications vs. wxwidgets applications and so on. Java very bad start up times still makes it effectively slow.
Give me a break. What are you running the tomcat on? an 386? let's go back to Assembly yeii! eat some stones baby
He asked why we need different syntaxes, not languages. Most of what you said doesn't relate to syntax at all.
How could you have two different languages with the same syntax? The only thing I can think of is one is a subset of the other.
Since you can write down all abstract syntax trees using the same syntax, and you can convert most languages into an abstract syntax tree (all the popular ones), it would be easy enough to write down most languages using the same syntax.
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.
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.
scheme and common lisp?
Isn't scheme a subset of common lisp (at least loosely speaking)?
For one thing, scheme has continuations, a powerful construct that Common Lisp lacks. But it's true that Common Lisp is generally more "featureful".
That's a feature that scheme has that common lisp doesn't, but is this supported by a new syntax? I think that it is not clear cut what is a syntactical difference versus a difference in the feature set.
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.
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.
No, not even close.
Because syntax is one of the features of a language.
and often times new syntax is created to support features in a language...
...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?
...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?
We have programming languages because people make them. The only way to have only 3 or 4 is to eradicate all but those and stop people from making more. However if we did that, I have a feeling we would now choose 1 or 2 that wouldn't exist if someone had done the same thing a decade ago.
A professor of mine once quipped: "What's the definition of a 'gentleman computer scientist?' Someone who knows how to make a their own computer language, but doesn't."
What about someone who knows how to get people on eLance to bid to make them for $1,000, no matter how impossible, but doesn't?
If you strip down a language so far that there's not much to it at all, then $1000 for a new language isn't so far fetched. Just don't ask for support for libraries, a JIT VM, etc. Then again, you could implement it on top of a pre-existing VM, and get access to libraries.
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.
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.
This question can not be fully answered in prose. It can only be answered with a challenge: Learn four or five diverse languages reasonably well, then try to create the single syntax that works well for all of them. You'll understand when you're done... or perhaps rather, when you find you'll never be done.
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?
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?
The one true syntax for type definitions is: don't have special syntax for them. Totally unnecessary. A good general syntax can handle them without a special case.
Because people have different syntactic preferences? Because some people hate c-style brackets while others hate python-style white-space? While it would make life easier in the short-run for those trying to learn a language who have pre-existing knowledge of the standardized syntax, it's quite possible that some other syntax would lead to wildly improved programmer productivity or, at the very least, much more readable/aesthetically pleasing code.
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.
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.
Python-style colon + whitespace.
Why does PHP need to use crap like echo and all those dollar signs instead of something more universal?
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.
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.
It's certainly not the only reason, but the same syntax with different semantics could get very confusing.
I think the different syntaxes help you (or at least me) switch contexts and remember what language I'm using.
I think the different syntaxes help you (or at least me) switch contexts and remember what language I'm using.
If every language had its own syntax, how would we make jokes about LISP programs which end with a page of right parentheses?
Because the people who designed them didn't agree on what was the best solution for the problem. And the people who use the various languages don't agree, either. Do you really think that you could sit down with a Lisp fanatic and a Java fanatic and get them to decide on a single syntax that they'd each rather use than their own favourite? They'd each prefer to do it their own way.
Let's say (however unlikely) that all current languages agreed on standard, and the next release of all these languages used this standard. There would inevitably be a group of people who don't agree with the standard and so they go and write a new language that uses their preferred syntax. Now we are back where we started.
hard to market something that is the same as everything else
I can live with differences in language syntax since in many cases there are semantic reasons behind them. The thing that really gets on my nerves are minor differences in the representations of common data structures (lists, tables, dictionaries, etc).
Yes. I think all languages should be written with s-expressions.
If they did have the same syntax, would they be different languages?
Different semantics
Same syntax, different semantics.. that does not sound easier to me. At all.
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?
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?
It seems you're disagreeing with a statement I never made.
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.
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 don't think I disagreed with you.
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 ;)
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 ;)
I think it is for the same reason that not all cars are shaped the same. Also, to crack wise about lisp.
Because then they would all have the same syntax.
It's because some people don't like s-expressions, so they've been making up a bunch of other stuff.
My theory: people who don't like s-expressions don't get programming;
Thus, everyone who gets programming and is exposed to lisp becomes a lisp programmer,
and people who suck at programming are left out.
Thus, everyone who gets programming and is exposed to lisp becomes a lisp programmer,
and people who suck at programming are left out.
I know many people who are counterexamples to your theory. Languages like Perl and Python have a strong advantage in libraries. If you don't need the things that only Lisp can do, there's not as much of a reason to use it.
If you don't need the things that only Lisp can do, there's not as much of a reason to use it.
True. But the Lisp programmer would reply that you need the things only Lisp can do in most non-trivial programs.
True. But the Lisp programmer would reply that you need the things only Lisp can do in most non-trivial programs.
I think the parent comment was probably trolling, but as someone who loves Lisp I have to say that some people have deeper reasons for not liking it than "libraries". A few of the best programmers I know just don't like Lisp. They tell me s-expressions don't fit the way their brains work. I'm not inclined to dismiss this as laziness, stupidity, or ignorance - though it's tempting :)
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.
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.
The (derisive) saying used to be "You can write FORTRAN in any language" but you can also write Lisp in any language.
Not that I completely agree with the GP's point.
Not that I completely agree with the GP's point.
you can also write Lisp in any language
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 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.)
I'm a big fan of Lisp, but this is definitely not true. Do you think the CMUCL (a popular Common Lisp application) team who went on to make non-sexp based Dylan are just people who suck at programming? Or the functional programming community in general? Some of the members of that community who are of a certain age would have cut their teeth on Lisp, but they ended up designing/using *ML and Haskell. Or how about Alexander Stepanov, who went from Scheme to C++ and designed the STL? Or Guy Steele, who invented Scheme but went on to help design Java and Fortress? These are not stupid people.
Do you think the CMUCL team who went on to make non-sexp based Dylan are just people who suck at programming?
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."
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 get to this in a timely manner due to a Christmas vacation, but I'll bite anyway.
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
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
I suspect that this is your hypothesis, rather than your theory.
Why can't all those projects come together and figure out a single universal standard for writing syntax? So that writing code would be exactly the same, no matter what technology you choose to use. At least for the simple stuff.
Why do programmers need to waste time remembering 20 different ways to write something as stupid as a Hello World application?