Kommt es in einer Programmiersprache wirklich auf die Syntax an? [geschlossen]


41

Einer meiner Professoren sagt, "die Syntax ist die Benutzeroberfläche einer Programmiersprache", Sprachen wie Ruby sind gut lesbar und werden immer besser, aber wir sehen viele Programmierer, die mit C \ C ++ produktiv sind, da es für Programmierer wirklich wichtig ist, dass die Syntax stimmt sollte akzeptabel sein?

Ich würde gerne Ihre Meinung dazu erfahren.

Haftungsausschluss: Ich versuche nicht, ein Argument zu beginnen. Ich dachte, das ist ein gutes Diskussionsthema.

Update: Dies stellt sich als gutes Thema heraus. Ich bin froh, dass Sie alle daran teilnehmen.


16
Hmm, das scheint davon auszugehen, dass die C / C ++ - Syntax schlecht ist? Gewiss sind einige Elemente von C ++ - Vorlagen hässlich, aber was die Sprachen betrifft (historisch gesehen), ist C / C ++ immer noch sehr, sehr gut lesbar.
Macneil

2
Nun, ich kenne viele Programmierer, die dem nicht zustimmen werden, hauptsächlich aus der Ruby-Community. Soweit ich das beurteilen kann, ist es besser lesbar als lisp :)
Saif al Harthi

9
War es ein theoretischer Kurs? Denken Sie daran: Professoren gehören oft zu den schlechtesten Programmierern. Sie haben keine Ahnung, wie es draußen in der Wildnis ist.
Job

2
Die Lesbarkeit liegt im Auge des Betrachters :).
MAK

8
Gute Syntax kann eine miserable Sprache nicht verbessern. Aber miserable Syntax kann eine gute Sprache schlechter machen;)
Dario

Antworten:


65

Ja tut es. Wenn Sie Zweifel haben, nehmen Sie APL oder J oder Brainfuck oder sogar schlicht und einfach Lisp oder Forth und versuchen Sie, jedes nicht ganz triviale Programm zu verstehen. Dann vergleiche zB mit Python.

Vergleichen Sie dann dasselbe Python (oder Ruby oder sogar C #) mit Dingen wie Cobol oder VB6.

Ich versuche nicht zu sagen, dass haarige Syntax schlecht und natürlichsprachliche Syntax unter allen Umständen gut ist. Aber obvoiusly Syntax macht einen großen Unterschied. Alles in allem können Sie alles in der schönsten Programmiersprache schreiben, die Sie auch als Turing-Maschinenprogramm schreiben können - aber normalerweise wollen Sie das nicht, oder?


26
Lisp ist definitiv verständlich.
Cbrandolino

65
+1 für die Aufnahme von Lisp in die Liste der nicht lesbaren Sprachen.
Asmeurer

65
-1 für die Aufnahme von Lisp in die Liste der nicht lesbaren Sprachen.
Paul Nathan

27
Das Programmieren ist im Allgemeinen für Uneingeweihte nicht lesbar. Ebenso Musiknotation und architektonische Grundrisse. (= XY) ist für jemanden, der lesen kann, genauso lesbar wie X == Y.
Paul Nathan

6
Ich mochte APL und es sei denn, der Code wurde absichtlich zum Verschleiern geschrieben (sehr einfach zu tun), war es ziemlich einfach zu lesen. Die Stärke der Syntax bestand darin, dass Sie Algorithmen in 2 oder 3 Zeilen APL-Code programmieren konnten, für die Dutzende oder Hunderte Zeilen C, Fortran oder COBOL erforderlich waren. Die Prägnanz und Aussagekraft einer Sprache wie APL ist für diese Diskussion wichtig, da der Versuch, Hunderte von Codezeilen einer anderen Sprache zu lesen, genauso frustrierend sein kann wie das Entschlüsseln undurchsichtiger Elemente von APL.
Osterwal

11

In der Praxis denke ich, dass es wichtig ist. Die Lesbarkeit wurde bereits oben erörtert. Ein weiteres Problem könnte sein, wie viele Tastenanschläge erforderlich sind, um eine Idee / einen Algorithmus auszudrücken. Ein weiteres Problem ist, wie einfach es ist, dass einfache Tippfehler für das menschliche Auge schwer zu fassen sind und wie viel Unheil sie anrichten können.

Ich habe es auch in einigen Zusammenhängen als nützlich empfunden, Codefragmente über ein anderes Computerprogramm zu analysieren und / oder zu generieren. Die Schwierigkeit, die Sprache zu analysieren und / oder richtigen Code zu generieren, wirkt sich direkt darauf aus, wie viel Aufwand erforderlich ist, um solche Tools zu erstellen / zu warten.


Hervorragende Beobachtung von Tippfehlern, die leicht zu unterscheiden sind.

7
Theoretisch besteht jedoch kein Unterschied zwischen Theorie und Praxis.
Job

10

Ich glaube, Ihr Professor bezieht sich auf synthetischen Zucker .

Syntaktischer Zucker ist ein Begriff aus der Informatik, der sich auf die Syntax in einer Programmiersprache bezieht, die die Lesbarkeit und Ausdrucksfähigkeit von Dingen verbessern soll, während es alternative Ausdrucksmöglichkeiten gibt .

Was also Ihr Professor andeutet, ist, dass jeder Code / jede Syntax, die in einer Programmiersprache geschrieben ist, in anderen Sprachen genauso oder sogar in derselben Sprache ausgedrückt werden kann.

Robert Martin, der sich am Strukturierten Programmiersatz orientiert , hat in seiner Keynote auf der RailsConf 2010 erläutert , was Programmierer grundsätzlich mit Programmiersprachen tun : Robert Martin (youTube-Video, siehe nach 14 Minuten, obwohl ich das Ganze empfehle):

  • Reihenfolge (Zuordnung)
  • Auswahl (wenn Anweisungen)
  • Iteration (do-Schleifen)

Das ist alles, was Programmierer von einer Programmiersprache zur nächsten tun, nur in einer anderen Syntax oder Benutzeroberfläche. Ich vermute, Ihr Professor hat das verstanden, wenn er / sie abstrakt über Programmiersprachen spricht.

Im Wesentlichen spielt die Syntax also keine Rolle . Wenn Sie jedoch spezifisch sein möchten, sind offensichtlich bestimmte Sprachen und Syntax besser für bestimmte Aufgaben geeignet als andere, wobei Sie argumentieren könnten, dass Syntax von Bedeutung ist.


Würden Sie C nur einen syntaktischen Zucker für Assembler nennen?
Goran Jovic

1
Ich würde. Aber ich behaupte, dass es auf die Syntax ankommt. ;)
Lennart Regebro

2
"... Robert Martin hat abstrahiert, was Programmierer grundsätzlich tun ..." Robert Martin? Robert Martin ?? Vielleicht möchten Sie dieses Papier tatsächlich in Betracht ziehen: C. Böhm, G. Jacopini, "Flussdiagramme, Turingmaschinen und Sprachen mit nur zwei Formationsregeln", Comm. of the ACM, 9 (5): 366-371,1966. Dies wird normalerweise als Quelle des 'Strukturierten Programmsatzes' angerechnet. en.wikipedia.org/wiki/Structured_program_theorem
leed25d

@ lee25d Ich wollte Onkel Bob nicht als Urheber der Abstraktion anerkennen, sondern als Quelle, aus der ich sie kürzlich gehört habe (und mit der ich verlinkt bin). Aber danke für den Link. Ich werde meine Antwort aktualisieren, um Ihren Link wiederzugeben.
Spong

Das oben verlinkte Wikipedia-Stück versteht die Geschichte des "Strukturierten Programmiersatzes" nicht ganz. Die Idee war älter als Bohm & Jacopini. Der Beitrag von Bohm & Jacopini zeigte, dass es sich um ein Theorem handelte, nicht nur um eine Vermutung, dh sie lieferten einen strengen formalen Beweis.
John R. Strohm

7

Ja und nein.

Die Syntax hat verschiedene Aspekte.

  • Lesbarkeit
  • Ausdruckskraft
  • Analysefähigkeit

Die Lesbarkeit wurde bereits erwähnt.

Expressivität ist ein interessanter Fall. Ich werde Funktionsübergabe als Beispiel verwenden, weil es eine Art Wendepunkt von semantischem / syntaktischem Schmerz ist.

Nehmen wir zum Beispiel C ++. Ich kann eine Funktion erster Ordnung folgendermaßen erstellen:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Diese besondere Redewendung wird häufig in Stepanovs Elements of Programming verwendet .

Auf der anderen Seite kann ich es in Common Lisp mit so etwas wie imitieren diese :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Oder in Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Oder in Python -

def myfunc():
    pass

def run_func(f):
    f()

Diese haben im Wesentlichen den gleichen semantischen Inhalt, obwohl das C ++ - Beispiel einige Typmetadaten enthält. Welche Sprache drückt die Idee aus, eine Funktion höherer Ordnung am besten zu übergeben? Common Lisp macht kaum eine syntaktische Variation. In C ++ muss eine Klasse erstellt werden, um die Funktion auszuführen. Perl ist ziemlich unkompliziert, wenn es darum geht, ein gewisses Maß an Differenzierung vorzunehmen. Python auch.

Welcher Ansatz passt am besten zur Problemdomäne? Welcher Ansatz kann die Gedanken in Ihrem Kopf am besten mit der geringsten Impedanzinkongruenz ausdrücken?

Parsability ist - in meinen Augen - eine große Sache. Insbesondere beziehe ich mich auf die Fähigkeit der IDE, die Sprache zu analysieren und zu zerlegen, ohne Fehler zu machen. Neuformatierung ist nützlich. Durch Token getrennte Sprachen lassen sich in der Regel gut analysieren - Ruby / C / Pascal usw.

Bedenken Sie jedoch, dass große Systeme aller Art mit jeder ernsthaften Sprache erstellt wurden, um Probleme der realen Welt zu lösen. Obwohl Syntax ein Hindernis darstellt, um einige Dinge auszudrücken, handelt es sich um ein Umgehungsproblem. Turing Äquivalenz und das alles.


5

Syntax ist auf jeden Fall wichtig, obwohl Sie es eher bemerken, wenn es nicht intuitiv ist und Fehler fördert. Zum Beispiel der berüchtigte Witz "Der letzte Käfer der Welt":

if (AlertCode = RED)
   {LaunchNukes();}

2
+1: Interessant, ich habe diesen berüchtigten Witz über den "letzten Käfer der Welt" noch nie gesehen (oder anerkannt). Aber ich kann sehen, wie abhängig von der Syntax einer Sprache (oder sogar der Semantik) das Ergebnis dieses Pseudocodes alles sein kann. Angesichts des semantischen Blickwinkels kann dies durchaus als klassischer Fall kultureller Fehlkommunikation gewertet werden.
Stephen Swensen

Aus diesem Grund sollten Sie Yoda-Bedingungen verwenden, dh if(RED = AlertCode)niemals kompilieren, da RED konstant ist (oder sein sollte!)
Malfist

4
@Malfist: Und so sehen wir, dass schlechte Syntax zu noch schlechterer Syntax führt, um dies zu kompensieren. Yoda-Bedingungen sind hässlich und schwer zu lesen, weil sie nicht so sind, wie die Leute das zugehörige Konzept sehen. Mein Punkt lautete eher "Dies ist (einer von vielen Gründen), warum Sie die C-Familie nach Möglichkeit meiden sollten."
Mason Wheeler

1
Glücklicherweise hat dieser Code zwei Fehler. Sicher, es wird immer in die Bedingung eingehen, aber dort wird nur ein Verweis auf die LaunchNukesProzedur abgerufen und nie aufgerufen. Krise abgewendet!
Munificent

3
Kommt drauf an was REDist. Wenn es 0 ist, wird LaunchNukes()es niemals aufgerufen.
Dan04

5

Die Syntax spielt eine Rolle, und ich kann Ihnen zwei unterstützende Beispiele nennen: Dylan, ein Lisp mit einer konventionelleren Syntax, und Liskell, ein Haskell mit einer Lisp-ähnlichen Syntax. In jedem Fall wurde eine Variante der Sprache vorgeschlagen, die genau dieselbe Semantik, jedoch eine völlig andere Syntax aufwies.

Im Fall von Dylan glaubte man, dass der Wegfall von s-Ausdrücken zugunsten von etwas Konventionellerem dazu beitragen würde, ein breiteres Spektrum von Programmierern anzulocken. Es stellte sich heraus, dass die Syntax nicht das einzige war, was Programmierer daran hinderte, Lisp zu verwenden.

Im Fall von Liskell wurde angenommen, dass die Verwendung von s-Ausdrücken die Verwendung von Makros erleichtern würde. Es stellte sich heraus, dass Makros in Haskell nicht unbedingt erforderlich sind, sodass auch dieses Experiment nicht funktioniert hat.

Hier ist die Sache: Wenn die Syntax für niemanden von Bedeutung wäre, wäre kein Experiment ausprobiert worden.


1
Dylan war zu wenig und zu spät in Bezug auf andere Sprachen. Was es zu seinen Gunsten hatte, konnte das nicht wettmachen. Wir können nicht mehr davon ausgehen, dass es sich um einen Syntaxfehler handelt als um einen Fehler bei der Benennung.
Macneil

@Macneil: Du hast Recht mit der zu kleinen, zu späten Sache. Das Löschen der Lisp-Syntax war nur der letzte Nagel im Sarg. Ich glaube nicht, dass es der Hauptgrund für Dylans Versagen war, aber ich bin mir nicht sicher, wie ich die Antwort umformulieren soll, um das am besten wiederzugeben.
Larry Coleman

Interessant, ich wusste nicht, dass sie die Lisp-Syntax in einer früheren Version hatten ... War das, als sie Ralph hieß? Das Newton Message Pad sollte ursprünglich Dylan in seinem Kern haben. 15 Jahre später haben wir iOS mit Objective-C als Kern, der kleineren Sprache der beiden, IMHO.
Macneil

Ich erinnere mich nicht genau, wann Dylan S-Ausdrücke verloren hat. Ich habe mich lange mit comp.lang.lisp beschäftigt und erinnere mich an das Thema, das in einem ihrer regelmäßigen Flammenkriege über Klammern auftaucht.
Larry Coleman

Dylan ist älter als Java, und ich vermute nicht, dass es damals viele C ++ gab.
Tom Hawtin - Tackline

3

Die Antwort könnte darin bestehen, das, was "wichtig" ist, in Computerfaktoren und menschliche Faktoren zu trennen . Es gibt viele menschliche Faktoren in der Syntax:

  • Lesbarkeit
  • Prägnanz
  • Wartbarkeit
  • Pädagogik
  • Fehlervermeidung
  • Zweckmäßigkeit - ist es eine REPL-Sprache, eine Skriptsprache oder eine Sprache für große Systeme?

Was den Computer betrifft, ist die einzige Frage der Syntax, ob es Unklarheiten gibt, die gelöst werden müssen, und wie lange es dauert, den Code beim Kompilieren / Interpretieren zu token / parsen - und das nur in diesem Fall von letzterem, wo der Aufwand für das Parsen ein bedeutendes Problem ist.

Das könnte der Grund sein, warum Sie auf diese Frage immer eine "Ja und Nein" -Antwort bekommen - weil es zwei Aspekte gibt.


1

Ohne Syntax hätten wir keine gemeinsame "Vorlage" , mit der wir auf menschlicher Ebene die Absicht eines Codeblocks kommunizieren könnten. Die Syntax bietet ein gemeinsames Framework, mit dem Compiler standardisiert werden können. Methoden können geteilt werden; Wartung kann vereinfacht werden.


Warum wurde meine Antwort herabgestimmt?
IAbstrakter

1

Ich denke, was wirklich wichtig ist, ist der API-Zugriff und die Verfügbarkeit von Low-Level-Funktionen (wie Speichersteuerung und Sperren) bei Bedarf. Die meisten anderen Sprachen sind mit diesen Funktionen ausgestattet. Das Problem ist, wenn Sie zusätzliche Funktionen benötigen, müssen Sie häufig eine Sprache wie C verwenden, um diese zu implementieren. Und es ist umständlich, C mit der von Ihnen verwendeten Sprache zu verbinden.

Für alles außer Webentwicklung (und Mathematik) habe ich festgestellt, dass C / C ++ immer noch DIE Sprache eines Betriebssystems und einer Anwendung ist. Es wird die meiste Zeit für echte plattformübergreifende Anwendungsentwicklung mit mehreren Threads und Preforming unterstützt. Und die Syntax von C ist in Ordnung. Einfach sehr einfach und relativ ausführlich. Amazing Syntax spielt eigentlich keine Rolle. Leistung und API-Verfügbarkeit müssen wir alle mit dem Code anderer Leute (der meistens in C oder seinen Derivaten geschrieben ist) kommunizieren.


Ich habe keine Bedenken gegen C, aber die ML / Haskell-Menge hätte wahrscheinlich etwas zu sagen, was das Threading betrifft.
Rei Miyasaka

+1 für "API-Zugriff": Ich denke, dies kann sogar wichtiger sein als Sprachfunktionen.
Giorgio

1

Syntax ist auf jeden Fall wichtig. Es ist äußerst hilfreich, wenn die Sprachsyntax so flexibel ist, dass Sie eine bequeme und lesbare domänenspezifische Sprache für Ihre Anwendung erstellen können. Wenn Sie dies bezweifeln, stellen Sie sich vor, Algebra-Probleme in prosaischem Latein zu machen, wie es vor dem 18. Jahrhundert gemacht wurde, oder stellen Sie sich vor, Sie machen Kalkül ohne die jetzt bekannte Leibniz-Notation. Sicher, ein Kalkültext ist für einen Anfänger nicht lesbar, aber mit der Übung können wir Kalkül und die Leibniz-Notation verwenden, um schnell eine Klasse von Problemen zu lösen, die Seiten der Mathematik mit klassischen Methoden erforderten. Das Programmieren ist nur ein weiteres Stück Mathematik. Eine praktische Schreibweise in der Nähe der Problemdomäne kann einen enormen Unterschied in der Produktivität bewirken.


Bei DSLs geht es nicht nur um Syntaxzucker. Die Semantik ist ein viel wertvollerer Teil. Es ist in Ordnung, eDSLs zu entwerfen, die keiner vorhandenen Syntax etwas hinzufügen.
SK-logic

@SK: Sicher, aber die Semantik unterliegt der vollständigen Kontrolle des Programmierers. Die Syntax wird durch die Basissprache eingeschränkt. Wir können bequeme DSLs in Groovy und anderen Sprachen erstellen, aber nicht so sehr in Java.
Kevin Cline

1

Hier ist ein Programm, das die Fakultät von 6 berechnet:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

Die Syntax ist minimal:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Es scheint eine verbreitete Überzeugung zu sein, dass die Syntax eine Sprache schwierig macht. Wie so oft bei weit verbreiteten Überzeugungen ist genau das Gegenteil der Fall.

Beachten Sie, dass die LISP-Syntax (wenn überhaupt) nur lesbar ist, da sie viel mehr Syntax als die oben genannten enthält. Also, wenn LISP-Fans Ihnen sagen, dass "Syntax keine Rolle spielt", bitten Sie sie, konsequent zu sein und SKI-Kalkül zu versuchen. Sie müssen zugeben, dass eine Bit-Syntax gar nicht so schlecht ist.


Ich kann die Abwahl nicht nachvollziehen. Dies ist eine wirklich aufschlussreiche Antwort. +1
scravy

0

Ich denke nicht, dass es über persönliche Vorlieben hinaus wichtig ist. Wenn alle Dinge (Leistung, Fähigkeiten usw.) gleich sind, kann ich sehen, warum man einer Sprachsyntax mehr Gewicht beimisst, sich aber dafür entscheidet, die Leistung von Sprachen wie c / c ++ oder einer anderen Sprache, die für den Job besser geeignet ist, zu übertreffen Syntax scheint eine schlechte Idee zu sein.


6
Wie wäre es mit "Time to Market", "Cost to Benefit" usw.?
Job

0

Ja, Syntax ist wichtig, allerdings nur für die Lesbarkeit. Vergleichen Sie:

for i in range(10):
   print(i)

(Ja das ist Python) mit

FOR(i<-RNG-<10){PRN<-i}

(Ja, das ist eine Sprache, die ich gerade erfunden habe.) Beide würden genau dasselbe tun, aber die Syntax ist anders und Python ist leichter zu lesen. Also ja, die Syntax ist definitiv wichtig. Auch "syntaktischer Zucker" zählt.

 @property
 def year(self):
     return self._date.year

Ist leichter zu lesen als

 def year(self):
     return self._date.year
 year = property(year)

0

Ja, sicher.

Wenn Sie eine große Flamme auslösen möchten, fragen Sie die Leute, wo sie die öffnende Klammer in C-ähnlichen Sprachen ablegen. ich meine

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

oder sogar VS

void foo() 
{ // blah
}

Und das ist genau die gleiche Sprache! Fragen Sie sie auch nach Leerzeichen, wo sie sie platzieren (Funktionsname und Klammer, Operatoren usw.).

1000 Antworten sind garantiert!


Ich möchte keine Flamme auslösen und bis jetzt habe ich gute Antworten und ich danke allen für die Teilnahme und die Erweiterung meines Wissens und ich wette, andere Leute fanden dies hilfreich
Saif al Harthi

0

Syntax spielt eine Rolle. In der heutigen Zeit würde ich jedoch sagen, dass es fast ausschließlich auf die Lesbarkeit und nicht wirklich auf die Anzahl der erforderlichen Tastenanschläge ankommt. Warum?

  • Wenn Sie nicht wirklich etwas so Einfaches schreiben, ist die Anzahl der Tasten, die Sie drücken, der einschränkende Faktor beim Schreiben eines Programms. Dann können Sie entweder nur sehr schlecht tippen oder viel, viel zu schnell nachdenken.
  • Alle anständigen IDEs verfügen heutzutage über eine große Anzahl von Verknüpfungen, die bedeuten, dass Sie nicht alle Zeichen eingeben müssen, die Sie die meiste Zeit verwenden.

Das heißt, wenn es zu ausführlich ist, kann es an den Punkt gelangen, an dem es die Lesbarkeit beeinträchtigt. Ich würde lieber etwas sehen wie:

foreach (String in stringList)

Zu:

für jeden String, der in der Liste enthalten ist, auf den die Variable stringlist verweist

... jeden Tag!


0

Die Syntax ist für diejenigen, die sie lernen, von Bedeutung. Je niedriger die Eintrittsbarriere, desto populärer könnte die Sprache anfangs sein. Aber wenn die Sprache schwierig oder unmöglich ist, sich selbst reich und prägnant auszudrücken, wird sie zunehmend an Popularität verlieren.

Sehr knapp und undurchsichtig (Perl) ist genauso schlecht wie zu wortreich und wortreich (AppleScript).

Es muss ein Gleichgewicht, eine niedrigere Eintrittsbarriere, eine hohe Produktivität und eine einfache Wartung geben.


-2

Zu berücksichtigen ist auch, dass Programmiersprachen mit besserer Syntax einfacher zu analysieren sind, wodurch der Compiler einfacher zu schreiben, schneller und weniger fehleranfällig ist.


3
Umm ... 10000 SLOC von parse.yin Ruby sind anderer Meinung. Es gibt einen Grund, warum jede einzelne der 7 produktionsbereiten Ruby-Implementierungen, die aktuell oder in Kürze verfügbar sind, denselben Parser verwendet, und jede einzelne Ruby-Implementierung, die jemals versucht hat, einen eigenen Parser zu entwickeln, ist fehlgeschlagen.
Jörg W Mittag

Und dann war da noch die berüchtigte ADA-Sprache. Zusammen mit der Sprachspezifikation gab es 100 Programme, die korrekt ausgeführt werden mussten, um den Compiler zu zertifizieren. Es gab einige wirklich subtile Dinge an der Syntax. Um es kurz zu machen, JEDER frühe ADA-Compiler hat ein paar dieser Programme durchgefallen. Und es war nicht einfach, einen Fehler zu beheben, aber sie mussten von vorne anfangen. Obwohl es massive staatliche Unterstützung hatte (alle DOD-Verträge erforderten ADA), starb es einen erbärmlichen Tod.
Omega Centauri

-2

Einfach ausgedrückt: Die Syntax als solche spielt keine Rolle. Die Semantik, die Sie damit ausdrücken können, spielt eine Rolle.


5
Schreiben Sie als Übung einen komplexen Parser in C und dann einen Gerätetreiber in Haskell. Hat Ihnen die Syntax geholfen?
9000

1
@ 9000: Ich habe in Haskell einige Gerätetreiber gesehen. Ich konnte mit ihnen nichts besonders Falsches sehen. Möchten Sie näher darauf eingehen?
Jörg W Mittag

2
@ 9000, wenn man bedenkt, wie schwierig es ist, Gerätetreiber in C richtig zu machen. Ich bin nicht sicher, ob Sie ein gutes Beispiel ausgewählt haben.

1
@ 9000: Das war genau mein Punkt. Die konkrete Natur eines syntaktischen Konstrukts spielt keine Rolle, es ist das, was Sie damit ausdrücken. Eine Programmiersprache mit der exakten Syntax von Haskell, die jedoch eine andere Auswertestrategie verwendet, lässt viele Haskell- Programme schlecht abschneiden oder sogar in Endlosschleifen stecken. Wenn es um syntaktische Konstrukte (oder allgemeiner: Sprachmerkmale) geht, ist nicht ihre konkrete Syntax von Bedeutung, sondern ihre Semantik, dh was Sie mit ihnen ausdrücken können.
back2dos

@ 9000, es ist kein Problem, einen Parser in einer Haskell mit C-ähnlicher Syntax zu schreiben (oder einen Treiber, der C mit einer Haskell-ähnlichen Syntax verwendet).
SK-logic
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.