Was sind fünf Dinge, die Sie an Ihrer Lieblingssprache hassen?

Question

Es gab in letzter Zeit eine Häufung von Perl-Hass auf Stack Overflow, also dachte ich, ich bringe meine " Fünf Dinge, die Sie an Ihrer Lieblingssprache hassen " Frage an Stack Overflow. Nimm deine Lieblingssprache und nenne mir fünf Dinge, die du an ihr hasst. Das können Dinge sein, die Sie einfach nur ärgern, zugegebene Designfehler, erkannte Leistungsprobleme oder jede andere Kategorie. Sie müssen sie nur hassen, und es muss Ihre Lieblingssprache sein.

Vergleichen Sie sie nicht mit einer anderen Sprache, und sprechen Sie nicht über Sprachen, die Sie bereits hassen. Sprechen Sie nicht über die Dinge, die Sie an Ihrer Lieblingssprache mögen. Ich möchte nur die Dinge hören, die du hasst, aber tolerierst, damit du all die anderen Dinge benutzen kannst, und ich möchte etwas über die Sprache hören, von der du dir wünschst, dass andere Leute sie benutzen würden.

Diese Frage stelle ich immer dann, wenn mir jemand seine Lieblingssprache aufdrängen will, und manchmal auch als Interviewfrage. Wenn jemand keine fünf Dinge findet, die er an seinem Lieblingstool hassen kann, kennt er es nicht gut genug, um es entweder zu befürworten oder das große Geld damit zu machen. Er hat es nicht in genügend verschiedenen Situationen eingesetzt, um es vollständig zu erforschen. Er befürwortet sie als Kultur oder Religion, was bedeutet, dass ich falsch liege, wenn ich nicht seine Lieblingstechnologie wähle.

Es ist mir nicht so wichtig, welche Sprache Sie verwenden. Sie wollen eine bestimmte Sprache nicht verwenden? Dann tun Sie es nicht. Sie haben sich nach bestem Wissen und Gewissen für eine Sprache entschieden und verwenden sie trotzdem nicht? Kein Problem. Manchmal lautet die richtige Antwort: "Sie haben ein starkes Programmierteam mit guten Praktiken und viel Erfahrung mit Bar. Zu Foo zu wechseln wäre dumm."

---

Dies ist auch eine gute Frage für Code Reviews. Leute, die eine Codebasis wirklich kennen, haben alle möglichen Vorschläge für sie, und diejenigen, die sie nicht so gut kennen, haben unspezifische Beschwerden. Ich frage Dinge wie "Wenn Sie bei diesem Projekt noch einmal von vorne anfangen könnten, was würden Sie anders machen?" In dieser Fantasiewelt können sich Benutzer und Programmierer über alles und jeden beschweren, der ihnen nicht gefällt. "Ich möchte eine bessere Schnittstelle", "Ich möchte das Modell von der Ansicht trennen", "Ich würde dieses Modul anstelle dieses anderen verwenden", "Ich würde diese Methoden umbenennen", oder was auch immer ihnen an der aktuellen Situation nicht gefällt. Auf diese Weise bekomme ich einen Eindruck davon, wie viel ein bestimmter Entwickler über die Codebasis weiß. Es ist auch ein Anhaltspunkt dafür, wie viel vom Ego des Programmierers in dem steckt, was er mir erzählt.

Hass ist nicht die einzige Dimension, um herauszufinden, wie viel Menschen wissen, aber ich habe festgestellt, dass sie eine ziemlich gute ist. Die Dinge, die sie hassen, geben mir auch einen Hinweis darauf, wie gut sie über ein Thema nachdenken.

Answer 1

C# / .NET:

• Klassen sollten standardmäßig versiegelt werden
• Es sollte keine lock Anweisung - stattdessen sollten Sie spezielle Sperrobjekte haben, und es sollten Methoden wie Acquire die Einweg-Sperrmarken zurückgeben. Daraus folgt, dass es nicht für jedes Objekt einen Monitor geben sollte.
• GetHashCode() y Equals() sollte nicht in System.Object - nicht alles ist für Hashing geeignet. Stattdessen sollten Sie eine IdentityComparer die dasselbe tut, und behalten Sie die IComparer<T> , IComparable<T> , IEqualityComparer<T> y IEquatable<T> Schnittstellen für benutzerdefinierte Vergleiche.
• Unzureichende Unterstützung für Unveränderlichkeit
• Schlechte Art und Weise der Entdeckung von Erweiterungsmethoden - es sollte eine viel bewusstere Entscheidung sein als nur die Tatsache, dass ich einen Namespace verwende.

Das waren nur ein paar Beispiele - wenn Sie mich morgen fragen, fallen mir bestimmt 5 weitere ein :)

Answer 2

C

• String-Manipulation.

Der manuelle Umgang mit den Zeichenkettenpuffern ist eine fehleranfällige Angelegenheit. Da ein großer Teil der Datenverarbeitung aus dem Verschieben und Ändern von Strings besteht (Computer werden nicht so sehr für große Zahlenberechnungen verwendet, wie man damals dachte), ist es wirklich schön, verwaltete Sprachen oder die String-Objekte von C++ verwenden zu können, um diese zu bearbeiten. Wenn ich das in reinem C machen muss, fühlt es sich an, als würde ich im Treibsand schwimmen.

Answer 3

Wie wäre es mit einer Liste mit fünf Dingen, die ich an einer Sprache hasse? :D

5- Wenn man eine Orange rot anmalt, ist sie noch lange kein Apfel.

Wenn eine Sprache entworfen wird, haben die Designer in der Regel im Kopf, wozu sie nützlich ist. Sie für etwas ganz anderes zu verwenden puede funktionieren, aber sich zu beschweren, wenn es nicht funktioniert, ist einfach dumm. Nehmen Sie Python. Ich bin sicher, dass entweder jemand ein Dienstprogramm entwickelt hat oder eines Tages entwickeln wird, um Exe-Dateien aus Python-Code zu erstellen. Warum um Himmels willen sollten Sie wollen um das zu tun? Es wäre nett - verstehen Sie mich nicht falsch -, aber es hat keinen Nutzen. Also hören Sie auf, sich darüber zu beschweren!

Ein gut durchdachtes Projekt würde wahrscheinlich Code aus mehreren Sprachen enthalten. Das heißt aber nicht, dass man ein Projekt nicht mit nur einer Sprache abschließen kann. Einige Projekte können durchaus mit den Fähigkeiten der von Ihnen verwendeten Sprache durchgeführt werden.

4- Stehen Sie auf Holzbeinen?

Die Plattform kann einen großen Einfluss darauf haben, was die Sprache leisten kann. Heutzutage können Garbage-Collectors oder sogar der frühe Versuch von Pascal, eine "Garbage-Collection" einzuführen, beim Verblassen des Speichers helfen (vielleicht malloc mehr Ram??). Computer sind schneller geworden, und so erwarten wir natürlich auch mehr von unseren Sprachen. Und offen gesagt, sollten wir das auch. Es gibt jedoch einen hohen Preis für die Bequemlichkeit des Compilers, Hash-Tabellen oder Strings oder eine Vielzahl anderer Konzepte zu erstellen. Diese Dinge sind möglicherweise nicht mit der Plattform, auf der sie verwendet werden, verbunden. Die Behauptung, sie seien leicht in eine Sprache einzubinden, sagt mir, dass Sie sich nicht auf ein Bein stellen können.

3- Wer ist wirklich schuld?

Fehler. Ihr wisst schon. Ich liebe Käfer. Warum ich Käfer liebe. Weil das bedeutet, dass ich meinen Job behalten kann. Ohne Wanzen gäbe es viele geschlossene Pizzerien. Aber die Benutzer hassen Wanzen. Aber hier ist ein kleiner Spritzer kaltes Wasser. Jeder Fehler est der Fehler des Programmierers. Nicht die der Sprache. Eine Sprache mit einer so strengen Syntax, die die Anzahl der möglichen Fehler erheblich reduzieren würde, wäre eine völlig nutzlose Sprache. Ihre Fähigkeiten ließen sich wahrscheinlich an einer Hand abzählen. Sie wollen Flexibilität oder Leistung? Sie haben Bugs. Und warum? Weil man nicht perfekt ist, und weil man Fehler macht. Nehmen Sie ein gut erkennbares Beispiel in C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

Wir alle wissen, was das bewirken wird. Aber was einige von uns vielleicht nicht wissen, ist, dass Funktionalität sehr nützlich sein kann. Je nachdem, was Sie tun. Pufferüberläufe sind der Preis für diese Funktionalität. Dieser Code oben. Wenn ich den tatsächlich veröffentlichen würde. Das ist wieder sag es mit mir "Mein Fehler". Nicht C's Schuld, dass ich das tun konnte.

2- Sollten wir das nicht in den Papierkorb werfen?

Es ist sehr einfach, auf eine Funktion in einer Sprache hinzuweisen, die wir nicht verstehen, weil wir sie nicht oft benutzen, und sie als dumm zu bezeichnen. Sich beschweren, dass es da ist usw. Goto ist für mich immer unterhaltsam. Die Leute beschweren sich immer darüber, dass es goto's in einer Sprache gibt. Doch ich wette, Ihr letztes Programm enthielt eine Art von goto. Wenn Sie jemals ein Break oder ein Continue benutzt haben, haben Sie ein Goto benutzt. Das ist es, was es ist. Zugegeben, es ist ein "sicheres" goto, aber es ist, was es ist. Goto's haben ihren Nutzen. Unabhängig davon, ob "implizite" Goto's wie continue oder break oder explizite Goto's (unter Verwendung des eigentlichen Schlüsselworts "goto" für die jeweilige Sprache) verwendet werden. Nicht, dass die Entwickler von Sprachen fehlerfrei wären, aber typischerweise... wenn die Funktionalität seit Anbeginn der Zeit (für diese Sprache) existiert. Wahrscheinlich ist dieser Aspekt eine entscheidende Eigenschaft dieser Sprache. Das heißt, sie wird verwendet und ist wahrscheinlich nicht nur wegen der Abwärtskompatibilität in Gebrauch. Sie wird heute verwendet. Das heißt, vor 5 Minuten. Und richtig eingesetzt. Nun... es gibt wohl auch jemanden, der sie unsachgemäß verwendet, aber das bezieht sich auf Nr. 3 auf meiner Liste.

1. - Alles ist ein Objekt.

Okay, das ist eigentlich eine Untermenge von Nr. 2. Aber dies ist bei weitem die ärgerlichste Beschwerde, die ich in Hasslisten sehe. Nicht alles ist ein Objekt. Es gibt sehr viele Konzepte, die nicht zu den Objekten gehören oder gehören müssen. Dinge dort zu platzieren, wo sie nicht hingehören, ist einfach hässlich und kann die Effizienz eines Programms verringern. Sicher, je nach Sprache vielleicht nicht viel. Dies bezieht sich auch auf #5. Das bedeutet ... ja. Globale sind in Ordnung. Funktionen im Gegensatz zu statischen Methoden sind in Ordnung. Die Kombination von OO-Programmierung mit globalen Funktionen ist in Ordnung. Das bedeutet aber nicht, dass wir alle losziehen und unseren Code von seinen Objektmodellen "befreien" sollten. Wenn wir einen Codeabschnitt oder ein ganzes Projekt entwerfen, sollten wir uns überlegen, was hinter den Kulissen passiert debe bei der Zusammenstellung berücksichtigt werden. Nicht nur, wo das Konzept lebt und viele andere Faktoren. Warum sollte man globale Funktionen in Klassen oder Namensraumkonzepte verpacken, wenn es keinen Zweck erfüllt? Nehmen Sie statische Mitgliedsvariablen. Das amüsiert mich sehr, denn nun ja es hängt natürlich von der Sprache und der Implementierung ab, aber im Allgemeinen haben Sie gerade eine globale Variable deklariert. Ja, es gibt einige Gründe, diese Nicht-OO-Konzepte in OO-Wrapper zu verpacken. Einer davon ist natürlich die Selbstdokumentation von Code. Das kann Sinn machen. Also, wie ich schon sagte. Gehen Sie nicht raus und "befreien" Sie Ihren Code. Aber jede gute moderne Sprache wird ein globales Konzept außerhalb ihrer OO-Modellierung haben. Ja, ich wollte speziell darauf hinweisen, dass eine OO-Programmiersprache ohne ein globales Konzept höchstwahrscheinlich einen schwerwiegenden Designfehler hat. Aber auch hier kommt es auf die Intention und das Design der Sprache an, so dass ich nicht versuche, eine bestimmte Sprache herauszupicken und es gibt viel zu viele, um sie hier zu analysieren. Wie dem auch sei, überlegen Sie sich, wo der Code am effektivsten sein sollte. Wenn man etwas mit viel Schnickschnack versieht, der keine zusätzliche Funktionalität oder Unterstützung bietet, wird die Tastatur nur schneller abgenutzt. Damit ist niemandem gedient. Es sei denn, Sie möchten von der Person, die Ihnen wahrscheinlich fälschlicherweise beigebracht hat, dass alles ein Objekt ist, Pluspunkte sammeln.

Kurz gesagt, Programmieren ist nicht nur das gedankenlose Tippen auf der Tastatur. Bei jedem Projekt gibt es eine Menge Designüberlegungen. Ich weiß, es ist ein Klischee, aber man muss es aus jedem Blickwinkel betrachten. Selbst bei den heutigen typsicheren Sprachen. Man wirft nicht einfach einen Code in den Raum und erwartet, dass er gut funktioniert. Sicher es kann funktionieren, aber es ist vielleicht nicht der richtige Weg, es anzugehen. Insgesamt sollten Sie die Sprache und das Format wählen, die für die jeweilige Aufgabe UND die Umgebung am besten geeignet sind. Aber keine Die Sprache nimmt den Gedanken dahinter weg. Wenn du nicht denkst, tippst du nur.

Answer 4

Fünf Dinge, die ich hasse Java (die derzeit meine Lieblingssprache ist) in keiner bestimmten Reihenfolge.

1. So sehr ich auch ein Fan von Java Generics bin, so gibt es doch eine Reihe von Merkwürdigkeiten, die sich aus der Art und Weise ergeben, wie sie entwickelt wurden. Als solche gibt es eine Vielzahl von lästigen Einschränkungen mit Generics (von denen einige das Ergebnis der Typ-Löschung sind).
2. Die Art und Weise, wie Object.clone() und die Cloneable-Schnittstellen funktionieren, ist völlig kaputt.
3. Anstatt den Königsweg zu gehen und alles zu einem Objekt zu machen (a.a.O. SmallTalk), hat Sun zwei verschiedene Kategorien von Datentypen geschaffen: Objekte und Primitive. Infolgedessen gibt es jetzt zwei Darstellungen für grundlegende Datentypen und merkwürdige Kuriositäten wie Boxing/Unboxing und die Unmöglichkeit, Primitive in eine Sammlung aufzunehmen.
4. Swing ist zu komplex. Verstehen Sie mich nicht falsch: Es gibt eine Menge cooler Sachen, die man mit Swing machen kann, aber es ist ein großartiges Beispiel für Over-Engineering.
5. Diese letzte Beschwerde ist gleichermaßen die Schuld von Sun und denjenigen, die XML-Bibliotheken für Java geschrieben haben. Java XML-Bibliotheken sind viel zu kompliziert. Wenn ich eine XML-Datei einfach nur einlesen will, muss ich mir oft Gedanken darüber machen, welchen Parser ich verwende: DOM oder SAX? Die APIs für beide sind gleichermaßen verwirrend. Native Unterstützung in der Sprache für einfach Das Parsen/Schreiben von XML wäre sehr schön.
6. java.util.Date nervt. Es ist nicht nur unnötig kompliziert, sondern alle nützlich Methoden wurden veraltet (und durch andere ersetzt, die die Komplexität erhöhen).

Answer 5

Rubinrot hat viele Schwächen, die mit der Geschwindigkeit zusammenhängen, aber die hasse ich nicht. Es hat auch Mängel, die mit der überzogenen Community-Evangelisation zu tun haben, aber das stört mich nicht wirklich. Das sind die Dinge, die ich hasse:

• Für Closures (Blöcke) gibt es 4 verschiedene Erstellungssyntaxen, von denen keine optimal ist. Die elegante Syntax ist unvollständig und zweideutig mit Hashes, und die vollständige Syntax ist hässlich.
• Die Gemeinschaft neigt dazu, gegen eine echte Dokumentation zu sein und bevorzugt das "Lesen des Codes". Ich finde das kindisch und faul.
• Der Missbrauch von Metaprogrammierung, insbesondere in Bibliotheken, macht das Aufspüren von Fehlern zu einem Albtraum.
• In diesem Zusammenhang ist anzumerken, dass die weit verbreitete Metaprogrammierung die Entwicklung einer umfassenden IDE schwierig, wenn nicht gar unmöglich macht.

• Die Art und Weise, wie die Übergabe von Blöcken an Funktionen erfolgt, ist albern. Es gibt keinen Grund, warum Blöcke außerhalb der Parameterliste übergeben werden sollten oder eine seltsame spezielle Syntax für den Zugriff (yield) haben sollten. Ich bin der Meinung, dass Blöcke eine weniger zweideutige Syntax hätten erhalten sollen (oder Hashes hätten andere Trennzeichen verwenden können; vielleicht <> statt {}), und die Übergabe als Parameter an Methoden hätte wie alle anderen Parameter erfolgen sollen.

  object.method(1, {|a| a.bar}, "blah")

  Diese Merkwürdigkeiten, wie z. B. dass der Block der letzte übergebene Parameter sein muss und dass die Übergabe von mehr als einem Block bei längerer Syntax anders ist, ärgern mich wirklich.