Objektive Vorteile der C-Stil-Syntax

IMHO, das einzige, was C-Stil-Syntax populär macht, ist, dass die meisten Leute es wissen. Und so ermöglicht es die Verwendung von C-style für eine neue Sprache, alte Gewohnheiten anzuwenden (wie Namenskonventionen). Das ist eine gute Sache! Obwohl ich denke, die Syntax ist die geringste Sorge für das Erlernen einer neuen Sprache. Aber eine gute Syntax kann helfen, Fehler zu vermeiden.

Microsoft hat sich sehr bemüht, VB.NET so wichtig wie C # zu machen (erinnern Sie sich an alle " null ( Nichts in Visual Basic)" in der MSDN, die ziemlich nervt mich), aber immer noch C # ist die dominierende Sprache für die .NET-Plattform. Es scheint, dass VB.NET ein Problem mit dem schlechten Ruf seiner Vorgänger hat. Und trotzdem scheint C-Style professioneller zu wirken.

Eines der C-Entwurfsziele bestand schließlich darin, den Compiler einfach zu implementieren. Es war einfacher, einen Präprozessor zu verwenden, als ein neues Sprachkonstrukt für Konstanten zu definieren. Oder die Semantik von a [5]. Dies gilt nicht für C ++, das sehr schwierig zu implementieren ist, teilweise weil es versucht, mit C kompatibel zu bleiben.

Beispiele:

• Groß- / Kleinschreibung beachten, obwohl die Groß- / Kleinschreibung für Menschen (nicht für Computer) natürlicher ist. Dies bedeutet nicht, dass Sie die Bezeichner anders buchstabieren sollten als sie deklariert wurden (Achtung!), Aber das kann zu Verwirrung führen. Praxisbeispiel (Java): getWhiteSpace () oder getWhitespace ()?

EDIT: Noch ein schönes Beispiel: Was ist das schlimmste Problem in C # oder .NET? . Aber natürlich, sobald man sich daran gewöhnt hat und mit Hilfe einer IDE, ist das kein großes Problem mehr, manchmal sogar natürlicher, weil es besser aussieht, wie Computer tatsächlich funktionieren.

• Operatorpriorität

• = für die Zuordnung und == für den Vergleich. if (a = b) jemand? Ähnlich sind die && und & , || und | , ( ! und ~ ) syntaktisch zu eng, obwohl sie unterschiedliche Dinge bedeuten. Persönlich würde ich and und or bevorzugen, weil Symbole nur die Syntax unterstützen sollten, anstatt der Hauptteil zu sein.

• ++ und -- Operatoren; Macht einige Aussagen etwas kürzer, führt aber zu Ausdrücken Nebenwirkungen ( a = b+++b++ ). Ursprünglich konnten Compiler dies effizienter kompilieren als i = i + 1 .

• for(init;condition;step) Schleife; Obwohl die beste Methode darin besteht, eine Variable nur zu inkrementieren, existiert dafür keine explizite Syntax. Stattdessen ist dies für Konstrukt überflüssig, da es (fast) dasselbe ist wie

  %Vor%

• switch Aussage; jemals eine Pause vergessen? Warum erlauben Sie nicht, Bereiche als Case-Labels zuzulassen, wie es die meisten anderen Sprachen tun?

• if(condition) Aussage. Die Verwendung von Klammern war keine so gute Wahl, da sie im Bedingungsausdruck selbst verwendet werden kann:

  %Vor%

• Präprozessor

• Hosenträger. Das ist umstritten. Ich stimme den Argumenten nicht zu, die besagen, dass diese "nicht viel Screen-estate" nutzen, tester sind oder schneller zu schreiben sind. Erstens sollte eine Sprache so gestaltet sein, dass sie leicht zu lesen und nicht einfach zu schreiben ist. Zweitens, abhängig von Ihrem Stil, verwendet geschweifte Klammern genau den gleichen Platz auf dem Bildschirm wie Schlüsselwörter: Sie schreiben sie in einer einzigen Zeile. Ist das nicht viel verschwendeter Raum?

  Darüber hinaus kritisieren die Leute LISP wegen seiner vielen Klammern. Ist dir nie passiert, dass du deine Zahnspange zählen musst, um herauszufinden, wo du eine verpasst hast? Manchmal füge ich nach der schließenden Klammer einen Kommentar hinzu, um anzuzeigen, was hier enden soll. BASIC-Syntax hat dies bereits enthalten. Und braucht nicht einmal ein Äquivalent zu einer öffnenden Klammer. Teilweise stimme ich zu, dass Zahnspangen gut sind: Sie sind fast unsichtbar und Eindringung ist die dominierende visuelle Eigenschaft. So gesehen, ist Python der nächste Schritt.

• Semikolons als Anweisungsabschlusszeichen oder Trennzeichen. Warum ist ein einzelnes Semikolon eine gültige Aussage?

  %Vor%

• Ununterscheidbare Folgen von Schlüsselwörtern

  %Vor%

  Ist es eine Methodendeklaration? Oder eine Variablendeklaration? Oder ein Funktionsprototyp? Oder etwas anderes? Einige Interpunktionszeichen (und Schlüsselwörter für jeden Deklarationstyp) könnten hier zum Beispiel dazu beigetragen haben, den Rückgabetyp klar zu trennen. Dies macht C ++ schwer zu parsen.

• Orthogonalität. {} while (condition) passt zu den anderen Sprachkonstrukten, auf die der Block folgt. Ich denke VB's

  %Vor%

  eine nette Lösung, weil Sie 4 mögliche Kombinationen mit unterschiedlicher Semantik haben: bis / nach dem Schlüsselwort do / loop.

• Seltsame Reihenfolge der Modifikatoren vom Variablentyp.

  %Vor%

• Typ und Variablenname erscheinen nur nacheinander, keine Markierung, dass es sich um eine lokale Variablendeklaration handelt. Scala verwendet val und var gibt eine Deklaration einer finalen / veränderbaren Variable an und der Typ wird durch einen Doppelpunkt getrennt. In den meisten anderen Fällen verwendet Scala Java-Syntax.

• Zuweisungsoperator, der einen Wert zurückgibt; Keine Unterscheidung zwischen Anweisungen (mit Auswirkungen) und Ausdrücken (die nur einen Wert zurückgeben)

EDIT: Einige weitere Beispiele hier: Ссылка

Sie werden sicherlich nicht mit vielen dieser Punkte einverstanden sein, und nicht alle von ihnen sind notwendigerweise negativ (zum Beispiel Semikola), oder ich kannte eine Lösung, die für alle Fälle besser ist. Selbst wenn ich würde, wäre die resultierende Sprache nicht die perfekte Sprache. Programmiersprachen werden sich immer weiterentwickeln und neu erfundene Sprachen lernen hoffentlich von ihren Vorgängern. Warum also nicht bei einer bekannten Syntax bleiben, statt alle zehn Jahre eine neue zu entwerfen?

Wenn ein Sprachentwickler jedoch die Möglichkeit hat, Programmierfehler zu vermeiden, die nur Tippfehler sind, warum nicht ändern? Zum Beispiel wurde dies in C # 's switch statement gemacht, was break (oder goto) obligatorisch macht. Und sobald die schlimmsten Nachteile beseitigt sind, überwiegt der Vorteil, dass die meisten Programmierer den Rest der Syntax-Syntax kennen, bei weitem die Vorteile der Neugestaltung einer Sprache von Grund auf. Aber ich bin immer noch erstaunt, warum so viele Programmierer immer noch C-Syntax so eifrig verteidigen, obwohl diese an den Fortschritt in der Informatik gewöhnt sind, erfordert die Überarbeitung von fast allem regelmäßig.

Zum Schluss denke ich, der einzige Grund, warum die C-Syntax dominant ist, ist, dass sie fast allen professionellen Programmierern bekannt ist, diese sind einfach daran gewöhnt. Die tatsächliche Syntax ist weniger wichtig, obwohl andere Sprachen Vorteile haben könnten. Dies ist der gleiche Grund, warum Elektroingenieure die Konvention der elektrischen Ladung so verwenden, wie sie ist.

(Vielleicht gibt es auch einen Comic über einen Programmierer, der Dennis Ritchie besucht: "Bitte machen Sie break s nicht in switch Anweisungen optional!")

Wie ich sehe, gibt es wirklich nur drei wichtige Syntaxelemente, die von C out an den Rest der Welt übertragen wurden: Blöcke, die mit geschweiften Klammern bezeichnet sind, Semikolons, um Zeilenenden zu bezeichnen, und ein allgemeiner " Knappheit "des Stils.

Das Umbrechen von Blöcken in einem einzelnen Zeichen macht vernünftigen Sinn; Erstens ist es schnell zu tippen, nimmt nicht viel Platz auf dem Bildschirm ein (im Gegensatz zu einem BEGIN-END Keyword-Paar). Zweitens ist die Syntax ziemlich flexibel, so dass Sie Ihre Blöcke so formatieren können, wie Sie es in besonderen Fällen brauchen / können (was Sie in Python nicht wirklich tun können). Schließlich kann Ihr Code durch etwas etwas aufgemotzt werden wie ein E-Mail-Client und immer noch sowohl von Menschen als auch von einem Compiler lesbar (was das einzige wirkliche Problem ist, das ich bei Python-ähnlichen Einrückungen für Blöcke habe).

Warum geschweifte Klammern? Ich weiß nicht, was der historische Präzedenzfall dafür war, sie in C (oder, wahrscheinlicher, BCPL) zu verwenden, aber ich kann eine Vermutung riskieren. Es gibt nicht so viele gepaarte Symbole auf einer amerikanischen "Standard" -Tastatur: {} [] () und & lt; & gt; sind darüber. Wenn wir dem Compiler das Leben erleichtern wollen, wollen wir einzigartige Symbole für BEGIN und END, also etwas wie | verwenden oder # für die Blockenden ist out. Von unseren Paaren ist {} wirklich der einzige, der nicht schon etwas bedeutet - () und [] haben beide viel Mathegepäck (was mehr oder weniger direkt mit Funktionen und Arrays übersetzt wird) und beide & lt; und & gt; meine alle möglichen Dinge. Ich würde {} auch für Blöcke wählen.

Warum sollten Sie eine neue Sprache verwenden, wenn Sie nicht mit Keywords oder Einrückungen arbeiten? Legionen von Programmierern sind daran gewöhnt, sie zu benutzen, um Blöcke zu bezeichnen, warum das gesamte Muskelgedächtnis ungültig wird?

Ähnliches gilt für die Verwendung von Semikolons. Etwas zu verwenden, um das Ende einer Zeile zu bezeichnen, macht das Leben für den Compiler viel einfacher. Die Verwendung nur eines einzigen Zeichens erleichtert dem Programmierer das Leben erheblich. Beim Scannen der einzelnen Zeichen auf der Tastatur gehört das Semikolon zu den wenigen, die mathematisch nicht viel bedeuten. Aus Sicht der englischen Grammatik ist der Punkt (oder vielleicht das Komma) am sinnvollsten, aber sie werden bereits als Dezimalpunkte verwendet. Und, wenn Sie ein wenig schielen, hat ein Semikolon als Zeilenabschluss eine einigermaßen ähnliche Bedeutung wie auf Englisch. Und wieder, wenn Sie eine neue Sprache beginnen, warum ändern Sie es?

(Man könnte argumentieren, dass die meisten C-Typ-Sprachen auch den Großteil des Keyword-Vokabulars aufnehmen, aber die meisten C-Keywords stammen aus älteren Sprachen wie ALGOL, FORTRAN und BCPL, und wirklich - sie sind alle (meistens) gesunder Menschenverstand. Und wieder einmal, wenn Sie die Programmiergemeinschaft geübt haben, was eine "while-Schleife" ist, warum ändern Sie den Namen?)

Ich würde argumentieren, dass heutzutage jede Sprache, die keine Syntax ähnlich wie C verwendet, dies aufgrund eines fundamentalen Paradigmenwechsels tut (wie Pythons Ansatz mit Einrückungen). Wenn du eine Sprache entwickelst, die im Prinzip genauso funktioniert, warum solltest du irgendetwas ändern? Ihre Zielgruppe kann bereits mit ihren kleinen Fingern auf die geschweifte Klammer drücken, warum diese bestimmte Fähigkeit wertlos macht?

Oder, um diesen letzten Satz noch einen Schritt weiter zu gehen, wenn Sie versuchen, die Programmiergemeinschaft auf Ihrer neuen, bahnbrechenden Sprache (Java, C #, etc.) zu verkaufen, werden Sie viel weniger Hürden haben um zu springen, wenn Ihre Kunden die Syntax bereits kennen.

Block-strukturierte Sprachen müssen irgendwie Blöcke angeben. Die relative Unpopularität der Pascal-Sprachfamilie scheint darauf hinzudeuten, dass Keywords keine gute Möglichkeit darstellen, dies zu tun. Auf der anderen Seite kann die Popularität von Python bedeuten, dass in Zukunft mehr Sprachen die Einrückung verwenden werden, um die Struktur anzugeben - ich hoffe, ich hoffe nicht.

Man muss sagen, warum erfinden Sie eine völlig neue Syntax, wenn c eine prägnante und leicht zu verstehen ist. Es half auch, dass die meisten Programme mit c vertraut waren und die Sprachen selbst in c implementiert wurden. Es ist ein Fall von warum versuchen, etwas zu verbessern, das bereits sehr gut funktioniert.

C-Stil-Syntax ist sehr kompakt. Je nach Situation ist dies ein Nachteil oder ein Vorteil. Jedenfalls ist dies eine Produktivitätssteigerung für ältere C-Programmierer.

Viele neue Sprachen beanspruchen offiziell Erbe von C, z.B. C ++, C #, Ziel-C.

Außerdem denke ich, dass viele Sprachentwickler einen großen C-Hintergrund haben. Bewusst oder nicht, können sie in ihrer neuen Sprache reproduzieren, was sie am besten wissen und was sie am effizientesten beurteilen.

  

Gibt es objektive Gründe, die die große Verbreitung und den Erfolg dieser Syntax erklären könnten?

Nicht ganz objektiv, aber C hatte drei wesentliche historische Vorteile:

• es war ein bisschen tiefer als andere Sprachen zu dieser Zeit (Verwendung von {} anstelle von Algols Beginn / Ende)
• es hatte keine offensichtlichen Nachteile (zB Fortran hatte Unklarheiten und unterstützte nicht mehrere Anweisungen in einer Zeile)
• nachdem es populär wurde, kannte fast jeder andere Sprachdesigner C und arbeitete wahrscheinlich in C, um das Toolset seiner Sprache zu erstellen

  

Gibt es bestimmte Vorteile gegenüber der Syntax anderer Sprachen?

Nun, explizite Block- und Anweisungstrennzeichen ermöglichen Ausdrücke mit mehreren Anweisungen. Zum Beispiel können Sie keine Multi-Statement-Lambda-Ausdrücke in Python verwenden (nicht, dass Sie Lambdas in C haben, obwohl Sie das in dem neuesten C ++ tun). Ein einzelnes Zeichen nur für Blöcke einzugeben ist ein kleiner Vorteil, aber kein großer Vorteil (es ist wahrscheinlich einfacher, einen Editor einzurichten, der "beginnen" mit "Ende" übereinstimmt, als C ("{" ODER "??) & lt; ") to ("} "ODER" ?? & gt; "), und wenn die Eingabegeschwindigkeit der limitierende Faktor in Ihrer Programmierung ist, automatisieren Sie wahrscheinlich keine Aufgabe, die Sie sein sollten).

Afaik die Popularität von C ist direkt mit der Popularität von Unix verbunden, und nicht mit seiner Syntax. Es gibt mehrere Facetten zu diesem Punkt; Die LowLevel-Sprache (*) und die Thin obligatorische -Bibliothek eignen sich für die Kernel-Entwicklung, die Verfügbarkeit von Compilern, die relativ frühen Versuche der systemübergreifenden Kompatibilität.

Wenn ich einen zweiten Grund nennen müsste, wäre es das relative lose Build-Modell (Kompilierungseinheiten treffen nur auf den Linker, nur der Linker sieht das (meist verdaute Programm) zum ersten Mal), was für Low sehr gut ist Speichersysteme.

Codedichte wird oft gesagt, aber das ist später Revisionismus. Für spätere Sprachen, die die Syntax übernehmen, ist dies eher in der Hoffnung, dass dies einen Upgrade-Pfad einfacher macht als die Überlegenheit der Syntax. Dies ist in etwas deutlich sichtbar als C #, das ziemlich weit von C entfernt ist, außer für die Blocksyntax und den Namen.

(*) Ich deute mehr auf das Fehlen vieler Compiler-Helfer hin. IOW mehr oder weniger den Inhalt von libgcc, wenn Sie es auf K & amp; R-Ebene abschneiden.