Was ist der größte Designfehler, den Sie in einer Programmiersprache gesehen haben? [geschlossen]

Alle Programmiersprachen haben ihre Designmängel, einfach weil keine einzige Sprache perfekt sein kann, genau wie bei den meisten (allen?) Anderen Dingen. Abgesehen davon, welcher Designfehler in einer Programmiersprache hat Sie in Ihrer Geschichte als Programmierer am meisten geärgert?

Beachten Sie, dass, wenn eine Sprache "schlecht" ist, nur weil sie nicht für eine bestimmte Sache entwickelt wurde, dies kein Designfehler ist, sondern ein Merkmal des Designs. Listen Sie daher nicht solche Belästigungen von Sprachen auf. Wenn eine Sprache nicht für das geeignet ist, wofür sie entwickelt wurde, ist das natürlich ein Fehler im Design. Implementierungsspezifische Dinge und unter der Haube Dinge zählen auch nicht.

Eines meiner größten Ärgernisse ist die Art und Weise, wie switchFälle in C-abgeleiteten Sprachen standardmäßig auf den nächsten Fall übergehen, wenn Sie die Verwendung vergessen break. Ich verstehe, dass dies bei Code auf sehr niedriger Ebene (z. B. Duff's Device ) nützlich ist , aber normalerweise für Code auf Anwendungsebene ungeeignet ist und eine häufige Quelle für Codierungsfehler darstellt.

Ich erinnere mich, dass ich ungefähr 1995, als ich zum ersten Mal über die Details von Java las, switchsehr enttäuscht war, dass sie das Standard-Durchfallverhalten beibehalten hatten , als ich zum Teil über die Aussage kam. Dies macht nur switcheine gotomit einem anderen Namen verherrlichte .

Ich habe die Verwendung =für Aufgaben und ==für Gleichheitstests in C-abgeleiteten Sprachen nie wirklich gemocht . Die Gefahr von Verwechslungen und Fehlern ist zu groß. Und fang mich nicht mal mit ===Javascript an.

Besser wäre es gewesen, sie :=zu beauftragen und =auf Gleichheit zu prüfen. Die Semantik hätte genauso aussehen können wie heute, wo Zuweisung ein Ausdruck ist, der auch einen Wert hervorbringt.

Die Wahl von +in Javascript sowohl für das Hinzufügen als auch für das Verketten von Zeichenfolgen war ein schrecklicher Fehler. Da Werte nicht typisiert sind, führt dies zu byzantinischen Regeln, die +abhängig vom genauen Inhalt jedes Operanden bestimmen, ob sie hinzugefügt oder verkettet werden.

Am Anfang wäre es einfach gewesen, einen völlig neuen Operator einzuführen, beispielsweise $für die Verkettung von Zeichenfolgen.

Ich finde Javascript standardmäßig global zu einem Hauptproblem und häufig zu einer Fehlerquelle, wenn Sie kein JSLint oder ähnliches verwenden

Der Präprozessor in C und C ++ ist ein gewaltiger Kludge, der Abstraktionen erzeugt, die wie Siebe auslaufen, Spaghetti-Code über Rattennester von #ifdefAnweisungen fördert und fürchterlich unlesbare ALL_CAPSNamen benötigt, um seine Einschränkungen zu umgehen. Die Wurzel dieser Probleme liegt darin, dass sie eher auf der Textebene als auf der syntaktischen oder semantischen Ebene ablaufen. Es sollte für seine verschiedenen Anwendungsfälle durch echte Sprachfunktionen ersetzt worden sein. Hier einige Beispiele, obwohl einige davon zugegebenermaßen in C ++, C99 oder inoffiziellen, aber de facto Standarderweiterungen gelöst sind :

• #include sollte durch ein echtes Modulsystem ersetzt worden sein.

• Inline-Funktionen und Vorlagen / Generika könnten die meisten Anwendungsfälle für Funktionsaufrufe ersetzen.

• Zum Deklarieren solcher Konstanten könnte eine Art Manifest- / Kompilierzeitkonstantenfunktion verwendet werden. Ds Erweiterungen von enum funktionieren hier hervorragend.

• Echte Makros auf Syntaxbaumebene könnten viele verschiedene Anwendungsfälle lösen.

• String-Mixins könnten für den Anwendungsfall der Code-Injection verwendet werden.

• static ifoder versionAnweisungen können zur bedingten Kompilierung verwendet werden.

Man könnte Hunderte von Fehlern in Hunderten von Sprachen auflisten, aber IMO ist dies aus Sicht der Sprachgestaltung keine nützliche Übung.

Warum?

Denn etwas, das in einer Sprache ein Fehler wäre, wäre in einer anderen Sprache kein Fehler. Zum Beispiel:

• Wenn Sie C zu einer verwalteten Sprache (dh zu einer Sprache mit Speicherbereinigung) machen oder die primitiven Typen einschränken, würde dies seine Nützlichkeit als semi-portable Low-Level-Sprache einschränken.
• Das Hinzufügen einer Speicherverwaltung im C-Stil zu Java (um beispielsweise Leistungsprobleme zu beheben) würde das Problem beheben.

Es gibt Lektionen zu lernen, aber die Lektionen sind selten eindeutig, und um sie zu verstehen, muss man die technischen Kompromisse und den historischen Kontext verstehen. (Zum Beispiel ist die umständliche Java-Implementierung von Generika die Folge einer übergeordneten Geschäftsanforderung zur Aufrechterhaltung der Abwärtskompatibilität.)

IMO, wenn Sie eine neue Sprache über die Gestaltung ernst meinen, müssen Sie tatsächlich nutzen ein breites Spektrum an vorhandenen Sprachen (und historische Sprachen zu studieren) ... und Ihre eigene Meinung zu bilden , was die Fehler sind. Und Sie müssen bedenken, dass jede dieser Sprachen in einem bestimmten historischen Kontext entworfen wurde, um ein bestimmtes Bedürfnis zu befriedigen.

Wenn allgemeine Lektionen zu lernen sind, befinden sie sich auf der "Meta" -Ebene:

• Sie können keine Programmiersprache entwerfen, die für alle Zwecke geeignet ist.
• Sie können es nicht vermeiden, Fehler zu machen, besonders wenn Sie von hinten betrachtet werden.
• Viele Fehler sind schmerzhaft zu korrigieren ... für Benutzer Ihrer Sprache.
• Sie müssen den Hintergrund und die Fähigkeiten Ihrer Zielgruppe berücksichtigen. dh vorhandene Programmierer.
• Sie können nicht allen gefallen.

C und C ++ : Alle Integer-Typen, die nichts bedeuten .

Besonders char. Ist es Text oder ist es eine winzige Ganzzahl? Handelt es sich bei dem Text um ein "ANSI" -Zeichen oder eine UTF-8-Code-Einheit? Wenn es sich um eine Ganzzahl handelt, ist sie signiert oder nicht signiert?

int sollte die "native" -große Ganzzahl sein, auf 64-Bit-Systemen ist dies jedoch nicht der Fall.

longkann oder kann nicht größer sein als int. Es kann oder kann nicht die Größe eines Zeigers sein. Es ist so ziemlich eine willkürliche Entscheidung der Compiler-Autoren, ob es sich um 32-Bit oder 64-Bit handelt.

Auf jeden Fall eine Sprache der 1970er Jahre. Vor Unicode. Vor 64-Bit-Computern.

null.

Sein Erfinder Tony Hoare nennt es den "Milliarden-Dollar-Fehler" .

Es wurde in den 60er Jahren in ALGOL eingeführt und ist in den meisten heute gebräuchlichen Programmiersprachen verfügbar.

Die bessere Alternative, die in Sprachen wie OCaml und Haskell verwendet wird, ist das Vielleicht . Die allgemeine Idee ist, dass Objektreferenzen nicht null / leer / nicht vorhanden sein können, es sei denn, es gibt einen expliziten Hinweis darauf, dass dies der Fall ist.

(Obwohl Tony in seiner Bescheidenheit großartig ist, denke ich, dass fast jeder den gleichen Fehler gemacht hätte, und er war einfach der Erste.)

Ich habe das Gefühl, dass die Leute, die PHP entwickelt haben, keine normale Tastatur und nicht einmal eine Colemak-Tastatur verwenden, weil sie hätten erkennen müssen, was sie tun.

Ich bin ein PHP-Entwickler. PHP zu schreiben macht keinen Spaß.

Who::in::their::right::mind::would::do::this()? Der ::Bediener muss die Umschalttaste gedrückt halten und dann zwei Tasten drücken. Was für eine Energieverschwendung.

Obwohl-> das-> ist-> nicht-> viel-> besser. Dies erfordert auch drei Tastendrücke, wobei die Umschaltung zwischen den beiden Symbolen erfolgt.

$last = $we.$have.$the.$dumb.'$'.$character. Das Dollarzeichen wird enorm oft verwendet und erfordert, dass die Auszeichnung bis ganz oben auf der Tastatur reicht und die Umschalttaste gedrückt wird.

Warum konnten sie PHP nicht für die Verwendung von Schlüsseln entwickeln, die viel schneller zu tippen sind? Warum konnte we.do.this()oder musste vars nicht mit einer Taste beginnen, die nur einen einzigen Tastendruck erfordert - oder überhaupt nicht (JavaScript) und nur alle vars vordefinieren (wie ich es ohnehin für E_STRICT tun muss)!

Ich bin keine langsame Schreibkraft - aber dies ist nur eine lahme Wahl für das Design.

Die Verwendung von Desktop-inspirierten Formularen innerhalb von asp.net .

Es fühlte sich immer unangenehm an und störte die Art und Weise, wie das Web tatsächlich funktioniert. Zum Glück leidet asp.net-mvc nicht in der gleichen Weise, obwohl Ruby usw. für diese Inspiration zu verdanken ist.

Für mich ist es das absolute Fehlen von Namens- und Argumentierungskonventionen in der Standardbibliothek von PHP .

Obwohl JASS ‚s Notwendigkeit zunichte machen Referenzen nach dem referenzierte Objekt wurde freigegeben / entfernt (oder die Referenz würde und mehrere Bytes Speicher Leck würde verloren) ist ernster, aber da JASS einzige Zweck Sprache ist, ist es nicht so kritisch.

Der größte Designfehler, dem ich gegenüberstehe, ist, dass Python nicht wie Python 3.x entworfen wurde.

Arrayzerfall in C und folglich C ++.

Primitive Typen in Java.

Sie brechen das Prinzip, dass alles ein Nachkomme von ist java.lang.Object, was aus theoretischer Sicht zu einer zusätzlichen Komplexität der Sprachspezifikation führt, und machen den Gebrauch von Sammlungen aus praktischer Sicht äußerst mühsam.

Autoboxing hat dazu beigetragen, die praktischen Nachteile zu beseitigen, jedoch auf Kosten der noch komplizierteren Spezifikation und der Einführung einer großen Fettbananenschale: Jetzt können Sie eine Nullzeigerausnahme von einer einfachen Rechenoperation erhalten.

Ich kenne Perl am besten, also werde ich mich darum kümmern.

Perl hat viele Ideen ausprobiert. Einige waren gut. Einige waren schlecht. Einige waren original und aus gutem Grund nicht weit verbreitet.

Eine davon ist die Idee des Kontexts - jeder Funktionsaufruf findet in einem Listen- oder Skalarkontext statt und kann in jedem Kontext ganz andere Dinge tun. Wie ich unter http://use.perl.org/~btilly/journal/36756 ausgeführt habe, erschwert dies jede API und führt häufig zu subtilen Designproblemen in Perl-Code.

Das nächste ist die Idee, Syntax und Datentypen so vollständig zu verknüpfen. Dies führte zur Erfindung der Bindung, damit sich Objekte als andere Datentypen tarnen können. (Sie können den gleichen Effekt auch mit Überladung erzielen, in Perl ist jedoch das Binden der üblichere Ansatz.)

Ein weiterer häufiger Fehler, den viele Sprachen begehen, besteht darin, zunächst dynamisches Scoping und nicht lexikalisches anzubieten. Es ist schwer, diese Designentscheidung später wieder rückgängig zu machen, und dies führt zu lang anhaltenden Warzen. Die klassische Beschreibung dieser Warzen in Perl lautet http://perl.plover.com/FAQs/Namespaces.html . Beachten Sie, dass dies geschrieben wurde, bevor Perl ourVariablen und staticVariablen hinzufügte .

Die Leute sind sich zu Recht nicht einig über statisches oder dynamisches Tippen. Ich persönlich mag dynamisches Tippen. Es ist jedoch wichtig, eine ausreichende Struktur zu haben, damit Tippfehler abgefangen werden können. Perl 5 leistet gute Arbeit mit strict. Aber Perl 1-4 hat das falsch verstanden. Einige andere Sprachen haben Flusenprüfer, die genau das Gleiche tun wie strenge. Solange Sie sich mit der Durchsetzung von Flusenprüfungen auskennen, ist dies akzeptabel.

Wenn Sie mehr schlechte Ideen suchen (viele von ihnen), lernen Sie PHP und studieren Sie seine Geschichte. Mein Lieblingsfehler in der Vergangenheit (der vor langer Zeit behoben wurde, weil er zu so vielen Sicherheitslücken führte) bestand darin, dass jeder durch Übergabe von Formularparametern eine Variable festlegen konnte. Das ist aber alles andere als der einzige Fehler.

Mehrdeutigkeit von JavaScripts für Codeblöcke und Objektliterale.

  {a:b}

könnte ein Codeblock sein, bei dem aes sich um eine Bezeichnung und beinen Ausdruck handelt; oder es könnte ein Objekt mit einem Attribut definieren, adas den Wert hatb

Ich gehe zurück zu FORTRAN und der Unempfindlichkeit gegenüber Leerzeichen.

Es durchdrang die Spezifikation. Die ENDKarte musste als eine Karte mit einem 'E', einem 'N' und einem 'D' in dieser Reihenfolge in den Spalten 7 bis 72 definiert werden und keine anderen Nicht-Leerzeichen anstelle einer Karte mit "ENDE" in der richtigen Reihenfolge Spalten und sonst nichts.

Dies führte zu einer leichten syntaktischen Verwirrung. DO 100 I = 1, 10war eine Schleifensteuerungsanweisung, während DO 100 I = 1. 10es sich um eine Anweisung handelte, die einer aufgerufenen Variablen den Wert 1.1 zuweist DO10I. (Die Tatsache, dass Variablen ohne Deklaration erstellt werden konnten, deren Typ von ihrem Anfangsbuchstaben abhängt, trug dazu bei.) Im Gegensatz zu anderen Sprachen gab es keine Möglichkeit, Leerzeichen zum Trennen von Token zu verwenden, um eine Disambiguierung zu ermöglichen.

Es erlaubte auch anderen Leuten, wirklich verwirrenden Code zu schreiben. Es gibt Gründe, warum dieses Feature von FORTRAN nie wieder kopiert wurde.

Eines der größten Probleme bei BASIC war das Fehlen einer genau definierten Methode, um die Sprache über die frühen Umgebungen hinaus zu erweitern. Dies führte zu einer Reihe völlig inkompatibler Implementierungen (und einem nahezu irrelevanten post-facto-Versuch einer Standardisierung).

Fast jede Sprache wird von verrückten Programmierern für allgemeine Zwecke verwendet. Es ist besser, zu Beginn für den allgemeinen Gebrauch zu planen, falls die verrückte Idee auftaucht.

Ich glaube an DSLs (domänenspezifische Sprachen) und eine Sache, die ich in einer Sprache schätze, ist, wenn es mir erlaubt, eine DSL darüber zu definieren.

In Lisp gibt es Makros - die meisten Leute halten das für eine gute Sache, genau wie ich.

In C und C ++ gibt es Makros - die Leute beschweren sich darüber, aber ich konnte damit DSLs definieren.

In Java wurden sie ausgelassen (und daher in C #), und das Fehlen von ihnen wurde als Tugend deklariert. Klar, Sie haben damit Intelligenz, aber für mich ist das nur ein Oeuvre . Um mein DSL zu machen, muss ich von Hand expandieren. Es ist ein Schmerz, und es lässt mich wie einen schlechten Programmierer aussehen, obwohl ich dadurch viel mehr mit Tonnen weniger Code machen kann.

Aussagen , in jeder Sprache, die sie hat. Sie tun nichts, was Sie mit Ausdrücken nicht tun können, und hindern Sie daran, viele Dinge zu tun. Die Existenz eines ?:ternären Operators ist nur ein Beispiel dafür, dass man versuchen muss, sie zu umgehen. In JavaScript sind sie besonders ärgerlich:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

Für mich ist es das Designproblem, das alle Sprachen plagt, die von C abgeleitet wurden; nämlich das " sonst baumeln ". Dieses grammatikalische Problem hätte in C ++ gelöst werden müssen, wurde jedoch in Java und C # ausgeführt.

Ich denke, alle bisherigen Antworten deuten auf ein einziges Versagen vieler gängiger Sprachen hin:

Es gibt keine Möglichkeit, die Hauptsprache zu ändern, ohne die Abwärtskompatibilität zu beeinträchtigen.

Wenn dies gelöst ist, können so ziemlich alle anderen Griffe gelöst werden.

BEARBEITEN.

Dies kann in Bibliotheken durch unterschiedliche Namespaces gelöst werden, und Sie könnten sich vorstellen, für den größten Teil des Kerns einer Sprache etwas Ähnliches zu tun, obwohl dies dann bedeuten könnte, dass Sie mehrere Compiler / Interpreter unterstützen müssen.

Letztendlich glaube ich nicht, dass ich weiß, wie ich es auf eine völlig zufriedenstellende Weise lösen kann, aber das bedeutet nicht, dass es keine Lösung gibt oder dass nicht mehr getan werden kann

Javas stiller ganzzahliger arithmetischer Überlauf

Sowohl Java als auch C # haben ärgerliche Probleme mit ihren Typsystemen, da beim Hinzufügen von Generika die Abwärtskompatibilität beibehalten werden soll. Java mag es nicht, Generika und Arrays zu mischen. In C # sind einige nützliche Signaturen nicht zulässig, da Sie keine Werttypen als Grenzen verwenden können.

Betrachten Sie das als Beispiel für Letzteres

public static T Parse <T> (Typ <T>, Zeichenfolge str) wobei T: Enum

öffentliches statisches Objekt Parse (Typ type, string str)

MyEnum e = Enum.Parse (typeof (MyEnum), str);

MyEnum e = (MyEnum) Enum.Parse (typeof (MyEnum), str);

tl; dr: Denken Sie über den parametrischen Polymorphismus nach, wenn Sie mit dem Entwerfen Ihres Typsystems beginnen, nicht nachdem Sie Version 1 veröffentlicht haben.

Ich habe das Gefühl, ich öffne mich für Flammen, aber ich hasse die Möglichkeit, alte Datentypen als Referenz in C ++ zu übergeben. Ich hasse es nur wenig, komplexe Typen als Referenz übergeben zu können. Wenn ich mir eine Funktion anschaue:

void foo()
{
    int a = 8;
    bar(a);
}

Vom aufrufenden Punkt aus kann man nicht sagen, dass bar:

void bar(int& a)
{
    a++;
}

Einige mögen argumentieren, dass so etwas einfach ein schlechtes Software-Design ist und nicht die Schuld an der Sprache hat, aber ich mag es nicht, dass die Sprache es Ihnen überhaupt erlaubt, dies zu tun. Zeiger benutzen und anrufen

bar(&a);

ist viel lesbarer.

ÄNDERN

Als ich COBOL lernte, war die ALTER-Anweisung immer noch Teil des Standards. Kurz gesagt, mit dieser Anweisung können Sie Prozeduraufrufe zur Laufzeit ändern.

Die Gefahr bestand darin, dass Sie diese Anweisung in einen undurchsichtigen Codeabschnitt schreiben konnten, auf den nur selten zugegriffen wurde, und das Potenzial bestand, den Ablauf des restlichen Programms vollständig zu ändern. Mit mehreren ALTER-Anweisungen könnten Sie es fast unmöglich machen, zu jedem Zeitpunkt zu wissen, was Ihr Programm tat.

Mein Universitätslehrer erklärte sehr nachdrücklich, dass er uns automatisch durchfallen würde, wenn er diese Aussage jemals in einem unserer Programme sehen würde.

Die schlimmste Sünde einer Programmiersprache ist nicht gut definiert. Ein Fall, an den ich mich erinnere, ist C ++, das in seinen Ursprüngen:

1. War so schlecht definiert, dass Sie kein Programm zum Kompilieren und Ausführen anhand der folgenden Bücher oder Beispiele bekommen konnten.
2. Sobald Sie das Programm so optimiert haben, dass es unter einem Compiler und Betriebssystem kompiliert und ausgeführt wird, müssen Sie von vorne beginnen, wenn Sie zwischen Compilern oder Plattformen gewechselt haben.

Wie ich mich erinnere, dauerte es ungefähr ein Jahrzehnt, bis C ++ so gut definiert war, dass es so professionell zuverlässig war wie C. Es sollte nie wieder vorkommen.

Etwas anderes, was ich als Sünde betrachte (sollte es eine andere Antwort sein?), Ist, mehr als einen "besten" Weg zu haben, um eine gemeinsame Aufgabe zu erledigen. Es ist der Fall von (wieder) C ++, Perl und Ruby.

Klassen in C ++ sind eine Art erzwungenes Entwurfsmuster in der Sprache.

Es gibt praktisch keinen Unterschied zur Laufzeit zwischen einer Struktur und einer Klasse, und es ist so verwirrend zu verstehen, was der wahre Programmiervorteil des "Versteckens von Informationen" ist, dass ich es hier platzieren möchte.

Ich werde dafür abgelehnt, aber auf jeden Fall sind C ++ - Compiler so schwer zu schreiben, dass sich diese Sprache wie ein Monster anfühlt.

Obwohl jede Sprache ihre Fehler hat, ist keine eine Belästigung, wenn man sie erst einmal kennt. Mit Ausnahme dieses Paares:

Komplexe Syntax gepaart mit einer wortreichen API

Dies gilt insbesondere für eine Sprache wie Objective-C. Die Syntax ist nicht nur überwältigend komplex, sondern die API verwendet Funktionsnamen wie:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Ich bin alles dafür, explizit und eindeutig zu sein, aber das ist lächerlich. Jedes Mal, wenn ich mich mit xcode hinsetze, fühle ich mich wie ein n00b und das ist wirklich frustrierend.

1. signierte Zeichen in C - ein Gräuel, der erfunden wurde, um Mathematikern große Sammlungen kleiner Gegenstände zu ermöglichen
2. Verwenden von case, um semantischen Inhalt zu transportieren - wieder für Mathematiker, die nicht sprechen müssen und nie genug Platz für ihre Formeln haben
3. Let / Plain-Zuweisung vs. Set-Zuweisung in Basic-Dialekten - hier sind meiner Meinung nach keine Mathematiker involviert