C风格语法的客观优势

时间：2022-05-17 00:43:27

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.

有很多编程语言受C风格语法(花括号,半音等)的影响很大,可能比任何其他语法风格更多。直到今天,许多现代的,成功的甚至是新发明的语言都使用这种语法 - 只需要考虑Java,C ++,C#,PHP,JavaScript,C,Perl等。

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?

是否有任何客观原因可以解释这种语法的巨大传播和成功?其他语言的语法是否有某些优势?

10 个解决方案

#1

IMHO, the only thing that makes C-style syntax popular is that most people know it. And thus, using C-style for a new language makes it possible to apply old habbits (like naming conventions). This is a good thing! Although I think, the syntax is the least concern for learning a new language. But a good syntax can help to avoid errors.

恕我直言,唯一使C风格语法流行的是大多数人都知道它。因此,使用C风格的新语言可以应用旧的habbits(如命名约定)。这是件好事!虽然我认为,语法是学习新语言最不重要的。但是一个好的语法可以帮助避免错误。

Microsoft did a lot of effort to make VB.NET as important as C# (remember all the "null (Nothing in Visual Basic)" in the MSDN, which quite annoys me), but still C# is the dominant language for the .NET platform. It seems that VB.NET has a problem with the bad reputation of its predecessors. And still, using C-style seems to make a more professional look.

微软做了很多努力使VB.NET和C#一样重要(记住MSDN中的所有“null(在Visual Basic中都没有)”,这让我非常恼火),但C#仍然是.NET平台的主要语言。似乎VB.NET的前辈声誉不好。而且,使用C风格似乎更具专业外观。

After all, one of C's design goals was to make the compiler easy to implement. It was easier to use a preprocessor than defining a new language construct for constants. Or the semantics of a[5]. This does not apply to C++, which is very difficult to implement, partly because it tries to stay compatible with C.

毕竟,C的设计目标之一是使编译器易于实现。使用预处理器比为常量定义新的语言构造更容易。或者[5]的语义。这不适用于C ++,这很难实现,部分原因是它试图与C保持兼容。

Examples:

  • Case sensitiveness, although case insensitivity is more natural to humans (NOT to computers). This doesn't mean that you should spell identifiers differently than they have been declared (beware!), but can lead to confusion. Real-world example (Java): getWhiteSpace() or getWhitespace()?

    • 区分大小写,虽然不区分大小写对人类更为自然(不是计算机)。这并不意味着拼写标识符的方式与声明标识符不同(请注意!),但可能导致混淆。真实世界的例子(Java):getWhiteSpace()或getWhitespace()?

EDIT: Another nice example: What is the worst gotcha in C# or .NET?. But of course, once you are used to it and with the help of an IDE, this isn't much of a problem anymore, sometimes even more natural because it resembles better how computers actually work.

编辑:另一个很好的例子:C#或.NET中最糟糕的问题是什么?但是,当然,一旦你习惯了它并且在IDE的帮助下,这不再是一个问题,有时甚至更自然,因为它更像计算机实际工作的方式。

  • Operator precedence

  • = for assignment and == for comparison. if (a = b) anyone? Similar, the && and &, || and |, (! and ~) are syntactically too close although they mean different things. Personally, I'd prefer and and or, because symbols should just support syntax instead of being the main part.

    =用于分配,==用于比较。如果(a = b)有人吗?类似的,&&和&,||和|,(!和〜)在语法上太接近了,尽管它们意味着不同的东西。就个人而言,我更喜欢and和or,因为符号应该只支持语法而不是主要部分。

  • ++ and -- operators; Makes some statements just a little bit shorter, but introduces side effects to expressions (a = b+++b++). Originally, compilers could compile this more efficiently than i = i + 1.

    ++和 - 运算符;使一些语句稍微短一些,但会对表达式引入副作用(a = b +++ b ++)。最初,编译器可以比i = i + 1更有效地编译它。

  • for(init;condition;step) loop; Although best practise is to use it to increment a variable only, no explicit syntax exists for this. Instead, this for construct is redundant as it (nearly) the same as

    for(init; condition; step)loop;虽然最佳做法是仅使用它来递增变量,但是没有明确的语法。相反,这个构造是多余的,因为它(几乎)相同

    init;
while (condition) {
  statement;
  step;
}

  • switch statement; ever forgotten a break? Why not allowing ranges as case labels, as most other languages do?

    开关声明;曾经忘记休息了吗?为什么不像大多数其他语言那样允许范围作为案例标签?

  • if(condition) statement. Using parenthesis wasn't a that good choice as it can be used in the condition expression itself:

    if(条件)陈述。使用括号不是一个好的选择,因为它可以在条件表达式本身中使用:

    if (!(var & 0x02))

  • Preprocessor

  • Braces. This is controversial. I don't agree to arguments that state that these "don't use a lot of screen estate", are terser or are faster to write. First, a language should be designed to be easy to read, not easy to write. Second, depending on your style, braces uses uses the exact same amount of screen space than keywords: You write them in a single line. Isn't that a lot of wasted space?

    牙套。这是有争议的。我不同意那些声称这些“不要使用大量屏幕空间”的论点,更简洁或写得更快。首先,应该将语言设计为易于阅读,不易编写。其次,根据您的风格,大括号使用的屏幕空间大小与关键字完全相同:您可以将它们写在一行中。是不是浪费了很多空间?

    Additionally, people criticise LISP for its clutter of parentheses. Never happened to you that you have to count your braces to find out where you have missed one? I sometimes add a comment after the closing brace to indicate what is supposed to end here. BASIC syntax has this already included. And doesn't even need an equivalent to an opening brace. Partly I agree that braces are good: They are nearly invisible and indention is the dominant visual characteristic. Seen this way, python is the next step.

    此外,人们批评LISP的括号混乱。从来没有发生过你必须计算你的牙套以找出你错过的地方?我有时会在结束括号后添加一条注释来表示这里应该结束的内容。 BASIC语法已包含此功能。甚至不需要相当于一个开口支架。部分我同意牙箍是好的:它们几乎是不可见的,并且凹痕是主要的视觉特征。从这个角度看,python是下一步。

  • Semicolons as statement terminator or separator. Why is a single semicolon a valid statement?

    分号作为语句终止符或分隔符。为什么单个分号是有效的声明?

    if (condition);
  DoSomething();

  • Indistinguishable sequences of keywords

    无法区分的关键字序列

    public static string main()

    Is it a method declaration? Or a variable declaration? Or a function prototype? Or something else? Some punctuation (and keywords for every declaration type) could have helped here, for instance, to clearly separate the return type. This is what makes C++ hard to parse.

    这是方法声明吗?还是变量声明?还是功能原型?或者是其他东西?例如,一些标点符号(以及每种声明类型的关键字)可以帮助明确区分返回类型。这就是使C ++难以解析的原因。

  • Orthogonality. {} while (condition) does fit to the other language constructs where the statement is followed by the block. I think VB's

    正交性。 {} while(condition)适合其他语言结构,其中语句后面跟着该语句。我认为是VB的

    do [while/until condition]
  Statements
loop [while/until condition]

    a nice solution because you have 4 possible combinations with different semantics: until/while after the do/loop keyword.

    一个很好的解决方案,因为你有4种不同语义的可能组合:在do / loop关键字之后/之后。

  • Strange order of variable type modifiers.

    变量类型修饰符的奇怪顺序。

    int * const & i [];

  • Type and variable name just appear after each other, no marker that it is a local variable declaration. Scala uses val and var do indicate a declaration of a final/mutable variable and the type is separated by a colon. On most other things, Scala uses Java syntax.

    类型和变量名称只是在彼此之后出现,没有标记它是局部变量声明。 Scala使用val和var do表示final / mutable变量的声明,类型用冒号分隔。在大多数其他事情上,Scala使用Java语法。

  • Assignment operator returning a value; No distinction between statements (with effects) and expressions (which just return a value)

    赋值运算符返回值;语句(带效果)和表达式(只返回一个值)之间没有区别

EDIT: Some more examples here: https://*.com/questions/163026/what-is-your-least-favorite-syntax-gotcha

编辑:这里有更多的例子:https://*.com/questions/163026/what-is-your-least-favorite-syntax-gotcha

You certainly won't agree on many of these points, and not all of them are necessarily negative (semicolons, for instance), or that I knew a solution that is better for all cases. Even if I would, the resulting language would not be the perfect language. Programming languages will always evolve and newly invented languages hopefully learn from its predecessors. So, why not staying at a known syntax instead of designing a new one from every ten years?

你当然不会就这些问题达成一致意见,并且并非所有这些都必然是否定的(例如,分号),或者我知道一种解决方案对所有情况都更好。即使我愿意,结果语言也不会是完美的语言。编程语言将不断发展,新发明的语言有望从其前身中学习。那么,为什么不保持一种已知的语法而不是每十年设计一个新语法呢?

However, when a language designer has the possibility to avoid programming errors which are just typing errors, why not changing it? For instance this was done in C#'s switch statement, which makes break (or goto) mandatory. And once the worst drawbacks have been removed, the benefit that most programmers know the rest of the syntax syntax far outweighs the advantages of redesigning a language from scratch. But I am still astonished why so many programmers still defend C-syntax so eager, although these are used to that progress in computer science requires revision of nearly everything regularly.

但是,当语言设计人员有可能避免编程错误时,只是输入错误,为什么不改变呢?例如,这是在C#的switch语句中完成的,它使break(或goto)成为必需的。一旦消除了最严重的缺点,大多数程序员知道其余语法语法的好处远远超过了从头开始重新设计语言的优势。但我仍然感到惊讶的是,为什么这么多程序员仍然如此急切地捍卫C语法,尽管这些已经习惯于计算机科学的进步需要定期修改几乎所有内容。

To conclude, I think the only reason that C syntax is dominant is because it known to nearly all professional programmers, these a just used to it. The actual syntax is less important, although other languages might have advantages. This is the same reason why electrical engineers use the convention of electric charge as it is.

总而言之,我认为C语法占主导地位的唯一原因是几乎所有专业程序员都知道,这些只是习惯了它。虽然其他语言可能具有优势,但实际语法不太重要。这与电气工程师原样使用电荷惯例的原因相同。

C风格语法的客观优势

(Maybe there will be a comic about a programmer visiting Dennis Ritchie, too: "Please, don't make breaks in switch statements optional!")

(也许会有一个关于程序员访问Dennis Ritchie的漫画:“请不要在switch语句中选择休息!”)

#2

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.

正如我所看到的,实际上只有三个主要的语法元素从C out传递到世界其他地方:用大括号表示的块,用冒号表示行的末尾的块,以及一般的“简洁性”样式。

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

在单个字符中包装块具有相当好的意义;首先,键入速度快,不会占用大量的屏幕空间(与BEGIN-END关键字对不同)。其次,语法相当灵活,所以你可以根据需要/想要在特殊情况下格式化你的块(你不能用像Python这样的东西。)最后,你的代码可以通过某种东西来提升像一个电子邮件客户端,仍然可以被人类和编译器读取(这是我用python风格的缩进块的唯一真正的问题)。

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.

为什么大括号呢?我不知道在C中使用它们的历史先例(或者更有可能是BCPL),但我可以冒险猜测。 “标准”美式键盘上没有那么多配对符号:{} []()和<>是关于它的。如果我们想在编译器上轻松生活,我们需要BEGIN和END的唯一符号,所以使用类似|的东西或#块结束了。在我们的对中,{}实际上是唯一一个没有意义的东西 - ()和[]都有很多数学包袱(它们或多或少直接用函数和数组翻译)并且 <和> 都意味着各种各样的事情。我也会选择{}作为块。

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?)

(你可以说大多数C型语言也借用了大部分的关键词词汇,但实际上,大多数C的关键词来自ALGOL,FORTRAN和BCPL这样的老语言,而且实际上 - 它们都是(大多数)常识。再一次,一旦你训练了编程社区什么是“while循环”,为什么要更改名称?)

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?

我认为今天任何语言都没有使用类似C语法的语言,这是因为一些基本的范式转换(比如Python的缩进方法)。如果你的语言工作方式基本相同,为什么要改变呢?你的目标观众已经可以用他们的小指来敲击大括号的键,为什么这个特殊的技能毫无价值?

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.

或者,如果您试图以新的,改变游戏规则的语言(Java,C#等)销售编程社区,那么最后一句话就更进一步了,如果你想要跳过编程社区,那么你的客户都已经知道了语法。

#3

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

我认为这仅仅是一种风格而非优势问题。

#4

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.

块结构化语言必须以某种方式指定块。 Pascal语系的相对不受欢迎程度似乎表明关键字不是一个很好的方法。另一方面,Python的流行可能意味着将来更多的语言将单独使用缩进来表示结构 - thougi我只希望不是。

#5

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.

真实的是,当c简洁易懂时,为什么要发明一种全新的语法。它也有助于大多数程序熟悉c和语言本身在c中实现。这是为什么要尝试改进已经运作良好的东西的情况。

#6

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

人们已经习惯了。当它被发明时,每种语言都是丑陋的。那时候,C因吸吮而受欢迎。 (也许是为了比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).

我认为除此之外还有更多。我更喜欢大括号而不是开头/结尾(虽然大括号在许多非英语键盘上很痛苦),但仍有很多C语法的怪癖可以做得更好。 C ++发现返回类型可能在参数之后更适合(C ++ 0x允许该语法,因为它与其他新功能如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.

大多数函数式语言已经意识到参数周围的括号通常是不必要的。就此而言,通常也不需要显式打字。但大多数语言都是从C继承的,因为“这就是语法”。键入first,然后键入变量/函数名称。

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.

让我们甚至不进入功能指针的可憎之处。当然,我们可以为他们的类型找到更优雅的语法。或者尝试typedef'ing数组类型。

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

C的语法不太好。它完成了这项工作,我们已经习惯了它可能会留下来。但它并不“好”。

#7

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.

C风格的语法非常紧凑。根据情况,这是一个缺点或优点。无论如何,这对于高级C编码员来说是一种生产力提升。

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

许多新语言正式声称来自C的遗产,例如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.

而且,我猜许多语言创作者都有很大的C背景。无论是否有意,他们可以用他们的新语言复制他们最了解的内容以及他们认为最有效的内容。

#8

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:

不太客观,但C有三个主要的历史优势:

  • it was a bit terser than other languages at the time ( use of {} rather than Algol's begin/end )

    • 它当时比其他语言略胜一筹(使用{}而不是Algol的开头/结尾)

  • it had no obvious disadvantages ( eg Fortran had ambiguities and didn't support multiple statements on one line )

    • 它没有明显的缺点(例如Fortran有歧义并且不支持一行上的多个语句)

  • after it got popular, almost every other language designer knew C, and probably worked in C to build their language's toolset

    • 在它受欢迎之后,几乎所有其他语言设计师都知道C,并且可能在C中工​​作以构建他们的语言工具集

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

好吧,有明确的块和语句分隔符允许多语句表达式;例如,你不能在Python中做多语句lambda表达式(不是你在C中有lambdas,尽管你在最新的C ++中做过)。只需要为块输入一个字符是一个小优势,但不是一个大的(设置编辑器以匹配“开始”到“结束”比匹配C的更容易(“{”OR“?? <“)到(”}“或”??“),如果打字速度是你编程的限制因素,你可能不会自动完成你应该做的任务)。

#9

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.

    风洞效应。对于任何给定的问题,只有这么多好的解决方案,分析的问题越多,这些问题的解决方案就越可能变得相似。因此,2009款雪佛兰与2008款福特车更为相似,而57款雪佛兰则拥有57款福特......新雪佛兰和新款福特在同一个风洞中设计。大括号和分号具有简单的工程意义,使得C(对于计算机和人类而言)比“块”式的可比语言更容易解析...因此C#非常类似于Java,我有时会忘记哪个语言我正在使用。

  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.

PS:我预测,在50年内,我们将使用“自然语言”编纂者......并且深情地回忆起那些男人和羊在害怕的男人们的好日子。

#10

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.

Afaik C的受欢迎程度与Unix的受欢迎程度直接相关,而不是其语法。这一点有多个方面;它的低级语言(*)和瘦的强制库适用于内核开发,编译器的可用性,相对早期的跨系统兼容性尝试。

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.

通常会说代码密度,但那是后来的修正主义。至于采用语法的后来的语言,更希望它能使升级路径比语法的优越性更容易。除了blockyntax和名称之外,这在C#中显而易见,它与C相距甚远。

(*) 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.

(*)我更多地暗示了许多编译器助手的缺席。如果你将它降低到K&R级别,或多或少地了解libgcc的内容。

#1

IMHO, the only thing that makes C-style syntax popular is that most people know it. And thus, using C-style for a new language makes it possible to apply old habbits (like naming conventions). This is a good thing! Although I think, the syntax is the least concern for learning a new language. But a good syntax can help to avoid errors.

恕我直言,唯一使C风格语法流行的是大多数人都知道它。因此,使用C风格的新语言可以应用旧的habbits(如命名约定)。这是件好事!虽然我认为,语法是学习新语言最不重要的。但是一个好的语法可以帮助避免错误。

Microsoft did a lot of effort to make VB.NET as important as C# (remember all the "null (Nothing in Visual Basic)" in the MSDN, which quite annoys me), but still C# is the dominant language for the .NET platform. It seems that VB.NET has a problem with the bad reputation of its predecessors. And still, using C-style seems to make a more professional look.

微软做了很多努力使VB.NET和C#一样重要(记住MSDN中的所有“null(在Visual Basic中都没有)”,这让我非常恼火),但C#仍然是.NET平台的主要语言。似乎VB.NET的前辈声誉不好。而且,使用C风格似乎更具专业外观。

After all, one of C's design goals was to make the compiler easy to implement. It was easier to use a preprocessor than defining a new language construct for constants. Or the semantics of a[5]. This does not apply to C++, which is very difficult to implement, partly because it tries to stay compatible with C.

毕竟,C的设计目标之一是使编译器易于实现。使用预处理器比为常量定义新的语言构造更容易。或者[5]的语义。这不适用于C ++,这很难实现,部分原因是它试图与C保持兼容。

Examples:

  • Case sensitiveness, although case insensitivity is more natural to humans (NOT to computers). This doesn't mean that you should spell identifiers differently than they have been declared (beware!), but can lead to confusion. Real-world example (Java): getWhiteSpace() or getWhitespace()?

    • 区分大小写,虽然不区分大小写对人类更为自然(不是计算机)。这并不意味着拼写标识符的方式与声明标识符不同(请注意!),但可能导致混淆。真实世界的例子(Java):getWhiteSpace()或getWhitespace()?

EDIT: Another nice example: What is the worst gotcha in C# or .NET?. But of course, once you are used to it and with the help of an IDE, this isn't much of a problem anymore, sometimes even more natural because it resembles better how computers actually work.

编辑:另一个很好的例子:C#或.NET中最糟糕的问题是什么?但是,当然,一旦你习惯了它并且在IDE的帮助下,这不再是一个问题,有时甚至更自然,因为它更像计算机实际工作的方式。

  • Operator precedence

  • = for assignment and == for comparison. if (a = b) anyone? Similar, the && and &, || and |, (! and ~) are syntactically too close although they mean different things. Personally, I'd prefer and and or, because symbols should just support syntax instead of being the main part.

    =用于分配,==用于比较。如果(a = b)有人吗?类似的,&&和&,||和|,(!和〜)在语法上太接近了,尽管它们意味着不同的东西。就个人而言,我更喜欢and和or,因为符号应该只支持语法而不是主要部分。

  • ++ and -- operators; Makes some statements just a little bit shorter, but introduces side effects to expressions (a = b+++b++). Originally, compilers could compile this more efficiently than i = i + 1.

    ++和 - 运算符;使一些语句稍微短一些,但会对表达式引入副作用(a = b +++ b ++)。最初,编译器可以比i = i + 1更有效地编译它。

  • for(init;condition;step) loop; Although best practise is to use it to increment a variable only, no explicit syntax exists for this. Instead, this for construct is redundant as it (nearly) the same as

    for(init; condition; step)loop;虽然最佳做法是仅使用它来递增变量,但是没有明确的语法。相反,这个构造是多余的,因为它(几乎)相同

    init;
while (condition) {
  statement;
  step;
}

  • switch statement; ever forgotten a break? Why not allowing ranges as case labels, as most other languages do?

    开关声明;曾经忘记休息了吗?为什么不像大多数其他语言那样允许范围作为案例标签?

  • if(condition) statement. Using parenthesis wasn't a that good choice as it can be used in the condition expression itself:

    if(条件)陈述。使用括号不是一个好的选择,因为它可以在条件表达式本身中使用:

    if (!(var & 0x02))

  • Preprocessor

  • Braces. This is controversial. I don't agree to arguments that state that these "don't use a lot of screen estate", are terser or are faster to write. First, a language should be designed to be easy to read, not easy to write. Second, depending on your style, braces uses uses the exact same amount of screen space than keywords: You write them in a single line. Isn't that a lot of wasted space?

    牙套。这是有争议的。我不同意那些声称这些“不要使用大量屏幕空间”的论点,更简洁或写得更快。首先,应该将语言设计为易于阅读,不易编写。其次,根据您的风格,大括号使用的屏幕空间大小与关键字完全相同:您可以将它们写在一行中。是不是浪费了很多空间?

    Additionally, people criticise LISP for its clutter of parentheses. Never happened to you that you have to count your braces to find out where you have missed one? I sometimes add a comment after the closing brace to indicate what is supposed to end here. BASIC syntax has this already included. And doesn't even need an equivalent to an opening brace. Partly I agree that braces are good: They are nearly invisible and indention is the dominant visual characteristic. Seen this way, python is the next step.

    此外,人们批评LISP的括号混乱。从来没有发生过你必须计算你的牙套以找出你错过的地方?我有时会在结束括号后添加一条注释来表示这里应该结束的内容。 BASIC语法已包含此功能。甚至不需要相当于一个开口支架。部分我同意牙箍是好的:它们几乎是不可见的,并且凹痕是主要的视觉特征。从这个角度看,python是下一步。

  • Semicolons as statement terminator or separator. Why is a single semicolon a valid statement?

    分号作为语句终止符或分隔符。为什么单个分号是有效的声明?

    if (condition);
  DoSomething();

  • Indistinguishable sequences of keywords

    无法区分的关键字序列

    public static string main()

    Is it a method declaration? Or a variable declaration? Or a function prototype? Or something else? Some punctuation (and keywords for every declaration type) could have helped here, for instance, to clearly separate the return type. This is what makes C++ hard to parse.

    这是方法声明吗?还是变量声明?还是功能原型?或者是其他东西?例如,一些标点符号(以及每种声明类型的关键字)可以帮助明确区分返回类型。这就是使C ++难以解析的原因。

  • Orthogonality. {} while (condition) does fit to the other language constructs where the statement is followed by the block. I think VB's

    正交性。 {} while(condition)适合其他语言结构,其中语句后面跟着该语句。我认为是VB的

    do [while/until condition]
  Statements
loop [while/until condition]

    a nice solution because you have 4 possible combinations with different semantics: until/while after the do/loop keyword.

    一个很好的解决方案,因为你有4种不同语义的可能组合:在do / loop关键字之后/之后。

  • Strange order of variable type modifiers.

    变量类型修饰符的奇怪顺序。

    int * const & i [];

  • Type and variable name just appear after each other, no marker that it is a local variable declaration. Scala uses val and var do indicate a declaration of a final/mutable variable and the type is separated by a colon. On most other things, Scala uses Java syntax.

    类型和变量名称只是在彼此之后出现,没有标记它是局部变量声明。 Scala使用val和var do表示final / mutable变量的声明,类型用冒号分隔。在大多数其他事情上,Scala使用Java语法。

  • Assignment operator returning a value; No distinction between statements (with effects) and expressions (which just return a value)

    赋值运算符返回值;语句(带效果)和表达式(只返回一个值)之间没有区别

EDIT: Some more examples here: https://*.com/questions/163026/what-is-your-least-favorite-syntax-gotcha

编辑:这里有更多的例子:https://*.com/questions/163026/what-is-your-least-favorite-syntax-gotcha

You certainly won't agree on many of these points, and not all of them are necessarily negative (semicolons, for instance), or that I knew a solution that is better for all cases. Even if I would, the resulting language would not be the perfect language. Programming languages will always evolve and newly invented languages hopefully learn from its predecessors. So, why not staying at a known syntax instead of designing a new one from every ten years?

你当然不会就这些问题达成一致意见,并且并非所有这些都必然是否定的(例如,分号),或者我知道一种解决方案对所有情况都更好。即使我愿意,结果语言也不会是完美的语言。编程语言将不断发展,新发明的语言有望从其前身中学习。那么,为什么不保持一种已知的语法而不是每十年设计一个新语法呢?

However, when a language designer has the possibility to avoid programming errors which are just typing errors, why not changing it? For instance this was done in C#'s switch statement, which makes break (or goto) mandatory. And once the worst drawbacks have been removed, the benefit that most programmers know the rest of the syntax syntax far outweighs the advantages of redesigning a language from scratch. But I am still astonished why so many programmers still defend C-syntax so eager, although these are used to that progress in computer science requires revision of nearly everything regularly.

但是,当语言设计人员有可能避免编程错误时,只是输入错误,为什么不改变呢?例如,这是在C#的switch语句中完成的,它使break(或goto)成为必需的。一旦消除了最严重的缺点,大多数程序员知道其余语法语法的好处远远超过了从头开始重新设计语言的优势。但我仍然感到惊讶的是,为什么这么多程序员仍然如此急切地捍卫C语法,尽管这些已经习惯于计算机科学的进步需要定期修改几乎所有内容。

To conclude, I think the only reason that C syntax is dominant is because it known to nearly all professional programmers, these a just used to it. The actual syntax is less important, although other languages might have advantages. This is the same reason why electrical engineers use the convention of electric charge as it is.

总而言之,我认为C语法占主导地位的唯一原因是几乎所有专业程序员都知道,这些只是习惯了它。虽然其他语言可能具有优势,但实际语法不太重要。这与电气工程师原样使用电荷惯例的原因相同。

C风格语法的客观优势

(Maybe there will be a comic about a programmer visiting Dennis Ritchie, too: "Please, don't make breaks in switch statements optional!")

(也许会有一个关于程序员访问Dennis Ritchie的漫画:“请不要在switch语句中选择休息!”)

#2

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.

正如我所看到的,实际上只有三个主要的语法元素从C out传递到世界其他地方:用大括号表示的块,用冒号表示行的末尾的块,以及一般的“简洁性”样式。

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

在单个字符中包装块具有相当好的意义;首先,键入速度快,不会占用大量的屏幕空间(与BEGIN-END关键字对不同)。其次,语法相当灵活,所以你可以根据需要/想要在特殊情况下格式化你的块(你不能用像Python这样的东西。)最后,你的代码可以通过某种东西来提升像一个电子邮件客户端,仍然可以被人类和编译器读取(这是我用python风格的缩进块的唯一真正的问题)。

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.

为什么大括号呢?我不知道在C中使用它们的历史先例(或者更有可能是BCPL),但我可以冒险猜测。 “标准”美式键盘上没有那么多配对符号:{} []()和<>是关于它的。如果我们想在编译器上轻松生活,我们需要BEGIN和END的唯一符号,所以使用类似|的东西或#块结束了。在我们的对中,{}实际上是唯一一个没有意义的东西 - ()和[]都有很多数学包袱(它们或多或少直接用函数和数组翻译)并且 <和> 都意味着各种各样的事情。我也会选择{}作为块。

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?)

(你可以说大多数C型语言也借用了大部分的关键词词汇,但实际上,大多数C的关键词来自ALGOL,FORTRAN和BCPL这样的老语言,而且实际上 - 它们都是(大多数)常识。再一次,一旦你训练了编程社区什么是“while循环”,为什么要更改名称?)

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?

我认为今天任何语言都没有使用类似C语法的语言,这是因为一些基本的范式转换(比如Python的缩进方法)。如果你的语言工作方式基本相同,为什么要改变呢?你的目标观众已经可以用他们的小指来敲击大括号的键,为什么这个特殊的技能毫无价值?

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.

或者,如果您试图以新的,改变游戏规则的语言(Java,C#等)销售编程社区,那么最后一句话就更进一步了,如果你想要跳过编程社区,那么你的客户都已经知道了语法。

#3

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

我认为这仅仅是一种风格而非优势问题。

#4

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.

块结构化语言必须以某种方式指定块。 Pascal语系的相对不受欢迎程度似乎表明关键字不是一个很好的方法。另一方面,Python的流行可能意味着将来更多的语言将单独使用缩进来表示结构 - thougi我只希望不是。

#5

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.

真实的是,当c简洁易懂时,为什么要发明一种全新的语法。它也有助于大多数程序熟悉c和语言本身在c中实现。这是为什么要尝试改进已经运作良好的东西的情况。

#6

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

人们已经习惯了。当它被发明时,每种语言都是丑陋的。那时候,C因吸吮而受欢迎。 (也许是为了比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).

我认为除此之外还有更多。我更喜欢大括号而不是开头/结尾(虽然大括号在许多非英语键盘上很痛苦),但仍有很多C语法的怪癖可以做得更好。 C ++发现返回类型可能在参数之后更适合(C ++ 0x允许该语法,因为它与其他新功能如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.

大多数函数式语言已经意识到参数周围的括号通常是不必要的。就此而言,通常也不需要显式打字。但大多数语言都是从C继承的,因为“这就是语法”。键入first,然后键入变量/函数名称。

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.

让我们甚至不进入功能指针的可憎之处。当然,我们可以为他们的类型找到更优雅的语法。或者尝试typedef'ing数组类型。

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

C的语法不太好。它完成了这项工作,我们已经习惯了它可能会留下来。但它并不“好”。

#7

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.

C风格的语法非常紧凑。根据情况,这是一个缺点或优点。无论如何,这对于高级C编码员来说是一种生产力提升。

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

许多新语言正式声称来自C的遗产,例如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.

而且,我猜许多语言创作者都有很大的C背景。无论是否有意,他们可以用他们的新语言复制他们最了解的内容以及他们认为最有效的内容。

#8

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:

不太客观,但C有三个主要的历史优势:

  • it was a bit terser than other languages at the time ( use of {} rather than Algol's begin/end )

    • 它当时比其他语言略胜一筹(使用{}而不是Algol的开头/结尾)

  • it had no obvious disadvantages ( eg Fortran had ambiguities and didn't support multiple statements on one line )

    • 它没有明显的缺点(例如Fortran有歧义并且不支持一行上的多个语句)

  • after it got popular, almost every other language designer knew C, and probably worked in C to build their language's toolset

    • 在它受欢迎之后,几乎所有其他语言设计师都知道C,并且可能在C中工​​作以构建他们的语言工具集

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

好吧,有明确的块和语句分隔符允许多语句表达式;例如,你不能在Python中做多语句lambda表达式(不是你在C中有lambdas,尽管你在最新的C ++中做过)。只需要为块输入一个字符是一个小优势,但不是一个大的(设置编辑器以匹配“开始”到“结束”比匹配C的更容易(“{”OR“?? <“)到(”}“或”??“),如果打字速度是你编程的限制因素,你可能不会自动完成你应该做的任务)。

#9

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.

    风洞效应。对于任何给定的问题,只有这么多好的解决方案,分析的问题越多,这些问题的解决方案就越可能变得相似。因此,2009款雪佛兰与2008款福特车更为相似,而57款雪佛兰则拥有57款福特......新雪佛兰和新款福特在同一个风洞中设计。大括号和分号具有简单的工程意义,使得C(对于计算机和人类而言)比“块”式的可比语言更容易解析...因此C#非常类似于Java,我有时会忘记哪个语言我正在使用。

  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.

PS:我预测,在50年内,我们将使用“自然语言”编纂者......并且深情地回忆起那些男人和羊在害怕的男人们的好日子。

#10

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.

Afaik C的受欢迎程度与Unix的受欢迎程度直接相关,而不是其语法。这一点有多个方面;它的低级语言(*)和瘦的强制库适用于内核开发,编译器的可用性,相对早期的跨系统兼容性尝试。

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.

通常会说代码密度,但那是后来的修正主义。至于采用语法的后来的语言,更希望它能使升级路径比语法的优越性更容易。除了blockyntax和名称之外,这在C#中显而易见,它与C相距甚远。

(*) 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.

(*)我更多地暗示了许多编译器助手的缺席。如果你将它降低到K&R级别,或多或少地了解libgcc的内容。

标签：

相关文章