tags:

views:

596

answers:

10

There is a really big number of programming-languages that are heavily influenced by C-style syntax (curly-braced, semicola, etc.), maybe more than by any other syntactial style. And till this day, many modern and successful or even newly invented languages use this syntax - just think of Java, C++, C#, PHP, JavaScript, C, Perl etc.

Are there any objective reasons that could explain the great spread and success of this syntax? Are there certain advantages over the syntax of other languages?

+3  A: 

I think it is simply a matter of style rather than a matter of advantage.

Andrew Hare
I think it's more a matter of popularity. :) +1 though.
Bastien Léonard
+1  A: 

Block structured languages have to specify blocks somehow. The relative unpopularity of the Pascal language family seems to indicate keywords are not a good way of doing this. On the other hand, the popularity of Python may mean that in future more languages will use indentation alone to indicate structure - thougi I for one hope not.

anon
Indentation or braces, at least it isn't Lisp-style formatting. )()()()())((()))()
Aiden Bell
The advantage of having words as block delimiter is that you can determine which block you currently closed or where you missed it!Compare End If End While End Functionto } } }
Dario
-1 popularity of a language is usually not based on superficial syntax. Dangerous conclusions out of thin air.
Marco van de Voort
Hence my use of the words "seems" and "may".
anon
Wishy-washy phrasing doesn't make a point any more valid. For example: Your use of such words *seems to* indicate that you *may* beat your mother.
Chuck
So what I said was both "dangerous" and "wishy-washy"? I would have thought it must be one or the other.
anon
Well structured Lisp can actually look somewhat similar to Python code because it uses similar indention styling (blocks indent two spaces, function arguments are vertically aligned,) but I agree, the extraneous parentheses can be a bit much.
Cristián Romo
He said your conclusion was dangerous, you pointed out that you phrased it in a wishy-washy phrasing, and I said that doesn't make the conclusion any safer.
Chuck
A: 

C-style syntax is very compact. Depending on situations this is a drawback or an advantage. Anyway this is a productivity boost for senior C coders.

Many new languages officially claim heritage from C, e.g. C++, C#, Objective-C.

Moreover, I guess that many language creators have a big C background. Deliberately or not, they may reproduce in their new language what they know best and what they judge most efficient.

mouviciel
A: 

Afaik the popularity of C is directly linked to Unix' popularity, and not to its syntax. There are multiple facets to that point its lowlevel language(*) and thin mandatory library suitable for kernel development, the availability of compilers, the relative early attempts at cross-system compatibility.

If I had to name a second reason it would be the relative loose build model (compilation units only meet at the linker, only the linker sees the (mostly digested program) complete for the first time), which is great for low memory systems.

Code density is often said, but that is later revisionism. As for later languages adopting the syntax, that is more in the hope that it would make an upgrade path easier than superiority of syntax. This is clearly visible in something as C# which is quite far from C, except for the blocksyntax and name.

(*) I'm hinting more on the absense of lots of compiler helpers. IOW more or less the contents of libgcc if you cut it down to K&R level.

Marco van de Voort
+2  A: 

True be told why invent a completely new syntax when c is a concise and easily understood. It also helped that the majority of programmings were familiar with c AND the languages themselves were implemented in c. It's a case of why try to improve on something that already works very well.

ennuikiller
+4  A: 

As I see it, there are really only three major syntax elements that have been carried from C out to the rest of the world: blocks denoted by curly-braces, semi-colons to denote ends of lines, and a general "terseness" of style.

Wrapping blocks in a single character makes reasonably good sense; first, it's fast to type, doesn't take up a lot of screen real-estate (unlike a BEGIN-END keyword pair). Second, the syntax is fairly flexible, so you can format your blocks as you need/want to in special cases (which you can't really do in something like Python.) Finally, your code can be munged up quite a bit by something like an email client and still be readable by both humans and a compiler (which is the only real problem I have with python-style indents-for-blocks).

Why curly-braces, though? I don't know what the historical precedent for using them in C (or, more likely, BCPL) was, but I can hazard a guess. There aren't that many paired symbols on a "standard" American keyboard: {} [] () and <> are about it. If we want to make life easy on the compiler, we want unique symbols for BEGIN and END, so using something like | or # for the block ends is out. Of our pairs, {} is really the only one that doesn't already mean something - () and [] both have a lot of math baggage (which gets translated more or less directly with functions and arrays) and both < and > mean all kinds of things. I'd choose {} for blocks too.

With a new language, if you aren't going with keywords or indentation, why change it? Legions of programmers are used to using them to denote blocks, why invalidate all that muscle memory?

Much the same argument applies to using semicolons. Using something to denote the end of a line makes life much easier for the compiler. Using only a single character makes life a lot easier for the programmer. Scanning the single characters on the keyboard, the semi-colon is one of the few that doesn't mean much, mathematically speaking. From an English grammar point of view, the period (or maybe the comma) make the most sense, but they're already used as decimal points. And, if you squint a little, having a semi-colon as your line terminator has a reasonably similar meaning as it does in English. And again, if you're starting a new language, why change it?

As for the basic terseness, I'd posit that was the only one you could say, objectively, was a good idea. The fewer characters I can type to get the idea across to the computer while still being close enough to English to read, the better.

(You could argue that most C-type languages also borrow most of the keyword vocabulary, but really, most of C's keywords came from older languages like ALGOL, FORTRAN, and BCPL, and really - they're all (mostly) common sense. And again, once you've trained the programming community what a "while loop" is, why change the name?)

I'd argue that any language today that doesn't use a syntax a lot like C's is doing so because of some fundamental paradigm shift (like Python's approach with indents). If you're making a language that works basically the same way, why change anything? Your target audience can already hit the curly-brace key with their pinkies, why make that particular skill worthless?

Or, to take that last sentence a step further, if you're trying to sell the programming community on your new, game-changing language (Java, C#, etc.) you're going to have a lot less hurdles to jump if your customers all already know the syntax.

Electrons_Ahoy
BCPL didn't use braces, it uses $( and $) pairs. One of many vile things about it...
anon
Really? Things like dots for members, type/scope qualifiers on the first appearance of a variable and parens for function arguments don't seem that common to you?
Chuck
...well, yes. I was trying to stay as general as possible. :) But point taken.
Electrons_Ahoy
@Neil Butterworth: dang, really? Man, the more I learn about BCPL, the happier I am about not having learned it.
Electrons_Ahoy
@electrons Believe me, you have missed nothing. I learned some BCPL, way back when, because it looked like an easy language to write a compiler for. And it is, provided you don't write the compiler in BCPL. It's the only programming language I would never mention on my CV.
anon
+1  A: 

Are there any objective reasons that could explain the great spread and success of this syntax?

Not quite objective, but C had three main historic advantages:

  • it was a bit terser than other languages at the time ( use of {} rather than Algol's begin/end )
  • it had no obvious disadvantages ( eg Fortran had ambiguities and didn't support multiple statements on one line )
  • after it got popular, almost every other language designer knew C, and probably worked in C to build their language's toolset

Are there certain advantages over the syntax of other languages?

Well, having explicit block and statement delimiters allows multiple-statement expressions; for example, you can't do multi-statement lambda expressions in Python ( not that you have lambdas in C, though you do in the newest C++ ). Having to only type one character for blocks is a minor advantage, but not a massive one (it's probably easier to set up an editor to match "begin" to "end" than it is to match C's ("{" OR "??<") to ("}" OR "??>"), and if typing speed is the limiting factor in your programming, you're probably not automating a task you should be ).

Pete Kirkham
Re-reading some Brian Kernighan texts, it seems braces were added primarily as a clean way to eliminate dangling else whilst providing a token-based view of statement blocks.
Aiden Bell
it's probably easier to set up an editor to match "begin" to "end" than it is to match C's ("{" OR "??<") to ("}" OR "??>" -- although it's easier again to disable trigraphs.
Steve Jessop
A: 

People are used to it. When it was invented, every language was ugly as hell. Back then, C gained popularity for sucking less. (and perhaps for being more down-to-earth than LISP).

Today, other languages reuse the syntax because it's familiar to programmers.

I don't think there's much more to it than that. I prefer braces over begin/end (although the braces are a pain on many non-english keyboards), but there are still a lot of quirks of C syntax that could be done better. C++ is discovering that the return type might just fit better after the parameters (C++0x is allowing that syntax because it works better with other new features like decltype).

And most functional languages have realized that the parentheses around the parameters are often not necessary. For that matter, explicit typing often isn't necessary either. But most languages inherit that from C because "that's the syntax". Type first, then variable/function name.

And let's not even get into the abomination that is function pointers. Surely we can find a more elegant syntax for their types. Or try typedef'ing an array type.

Then there is the quirky choice of operators. Why not just use "and" instead of &&?

C's syntax isn't nice. It does the job, and we're so used to it that it's probably here to stay. But it's not "good".

jalf
A: 

As to why curly-braces caught on... Two reasons:

  1. The wind-tunnel effect. There are only so many good solutions to any given problem, and the more the problem is analysed the more alike the solutions to those problems are likely to become. Hence a 2009 Chevrolet more closely resembles a 2008 Ford than a 57' Chevy does a '57 Ford... The new Chevy and the new Ford where designed in the same wind tunnel. Curly-braces and semi-colons make simple engineering sense, making C substantially easier to parse (for both computers and humans) than comparable languages of "the block" style... Hence C# so closely resembles Java that I sometimes momentarily forget which langauge I'm using.

  2. (As previously stated) It's much easier for programmers to learn a new language which "looks and feels like" the previous model. Don't reinvent the wheel and it won't roll over on you ;-)

Cheers. Keith.

PS: I predict that within 50 years we'll be using "natural language" compilers... and reminiscing fondly about the good 'ole days of curly-brace languages, when men where men, and sheep where scared.

corlettk
+10  A: 
Meinersbur
+1 Note that easy to implement is slightly off. They also had a significant memory problem, and the system (with its separate preprocessor-compiler-assembler-linker) was designed to minimize the state needed in memory at once, to maximize the size of programs that could be compiled for a given memory size.
Marco van de Voort
+1 Macro with regard vintage memory capacity at the time of C's causing some design decisions. Also, anyone else love the bonkerness of Self?
Aiden Bell
Since some people put the opening brace on the next line, it may even be common for curly braces to take more space.
rpetrich
I disagree in that I believe a good syntax to be crucial. But other than that this is a really good summary.
Konrad Rudolph