Ich finde diese Debatten immer unterhaltsam zu lesen. Nicht so sehr für die intellektuelle Diskussion über die Vor- und Nachteile der verschiedenen verfügbaren Sprachen, sondern weil Sie normalerweise die Einstellung eines Menschen zum Thema auf der Grundlage seines Jobs / seiner Erfahrung / seines Interessengebiets festlegen können. Es stimmt mit den Argumenten der "vorzeitigen Optimierung" überein, dass die CS-Majors und Wartungsprogrammierer Knuth links und rechts zitieren, und diejenigen, die in der realen Welt arbeiten, in der es auf die Leistung ankommt, denken, sie seien alle verrückt (ich bin ein Mitglied der letzteren Gruppe) um fair zu sein).
Letztendlich können Sie hier exzellente Software in C oder C ++ entwickeln oder Sprache einfügen . Es kommt auf die Fähigkeiten des Entwicklers an, nicht auf die Sprache. Ein Experte in einer Sprache zu sein, ist normalerweise nur dann erforderlich, wenn Sie die falsche Sprache ausgewählt haben und diese nun zur Lösung Ihres Problems verwenden müssen. In den meisten Fällen sind dies die einzigen Situationen, in denen Sie sich mit undurchsichtigen Funktionen oder Compilern auseinandersetzen müssen Tricks, um das Ziel zu erreichen.
Ich höre oft Leute, die diese Argumente als "Ich bin ein Experte in Sprache X und bla bla" anfangen. Ich diskreditiere diese Leute ehrlich gesagt sofort, weil sie meiner Meinung nach das Problem bereits aus dem falschen Blickwinkel angegangen sind und alles danach verdorben ist durch ihren Wunsch, mit ihrem Werkzeug das Problem zu lösen und zu zeigen, wie 'cool' es ist.
Ich beobachte so oft, wie Entwickler zuerst ein Tool-Set auswählen und dann versuchen, es an ihr Problem anzupassen, was völlig falsch ist und zu Mistlösungen führt.
Wie ich in einem Kommentar zu einer anderen Antwort erwähnt habe, wird in diesen Sprachkriegen oft argumentiert, dass die Sprache X dem Programmierer erlaubt, mehr dumme Dinge zu tun. Während das Lesen unterhaltsam ist, bedeuten all diese Aussagen, dass Sie ein Problem damit haben, gute Entwickler einzustellen und dieses Problem direkt angehen müssen, anstatt zu versuchen, die Situation zu verbessern, indem Sie weiterhin schlechte Entwickler einstellen und Tools auswählen, die so wenig wie möglich leisten Schaden wie möglich.
Meiner Meinung nach sind gute Entwickler, sei es Software- oder Hardware-Entwicklung, recherchieren das Problem, entwickeln eine Lösung und finden die Werkzeuge, mit denen sie die Lösung auf die "beste Art und Weise" ausdrücken können. Es sollte keine Rolle spielen, ob das benötigte Tool etwas ist, das Sie noch nie zuvor verwendet haben. Nachdem Sie 3-4 Sprachen / Entwicklungstools für Projekte verwendet haben, die ein neues Tool aufnehmen, sollte dies nur minimale Auswirkungen auf Ihre Entwicklungszeit haben.
Natürlich ist 'bester Weg' ein subjektiver Begriff und muss auch in der Forschungsphase definiert werden. Man muss eine Vielzahl von Aspekten berücksichtigen: Leistung, einfache Ausdrucksweise, Codedichte usw., basierend auf dem vorliegenden Problem. Ich habe die Wartbarkeit aus einem bestimmten Grund nicht in diese Liste aufgenommen. Es ist mir egal, welche Sprache Sie auswählen, wenn Sie das richtige Tool ausgewählt und sich die Zeit genommen haben, um das Problem zu verstehen, das "kostenlos" auftreten sollte. Schwierig zu pflegender Code ist oft das Ergebnis der Wahl des falschen Tools oder einer schlechten Systemstruktur. Dies führt zu einem hässlichen Durcheinander, damit es funktioniert.
Die Behauptung, dass eine Sprache besser ist als jede andere, ist dumm, ohne ein bestimmtes Problem von Interesse zu definieren. Ein objektorientierter Ansatz ist nicht immer besser als ein funktionaler Ansatz. Es gibt einige Probleme, die sich sehr gut für ein objektorientiertes Designparadigma eignen. Es gibt viele, die dies nicht tun. Dieselbe Aussage kann über viele Sprachmerkmale gemacht werden, auf denen die Leute gerne zu harpen scheinen.
Wenn Sie mehr als 20% Ihrer Zeit mit dem eigentlichen Eingeben von Code verbringen, produzieren Sie wahrscheinlich ein sehr schlechtes System oder haben sehr schlechte Entwickler (oder Sie lernen noch). Sie sollten die meiste Zeit im Voraus damit verbringen, das Problem zu beschreiben und zu bestimmen, wie die verschiedenen Teile der Anwendung interagieren. Wenn Sie eine Gruppe talentierter Entwickler in einen Raum mit einem Markierungsfeld und einem zu lösenden Problem stecken und ihnen mitteilen, dass sie keinen Code schreiben oder Werkzeuge auswählen dürfen, bis sie sich mit dem gesamten System vertraut fühlen, wird dies die Qualität des verbessern Leistung und Geschwindigkeit der Entwicklung als bei der Auswahl eines neuen Tools, das die Entwicklungszeit garantiert verkürzt. (Scrum Development als Referenz für das Gegenteil meiner Argumentation nachschlagen)
Leider können viele Unternehmen den Wert eines Entwicklers nur anhand der Anzahl der geschriebenen Zeilen oder anhand der "greifbaren Ausgabe" messen. Sie betrachten die 3 Wochen in einem Raum mit einer Markierungstafel als Produktivitätsverlust. Entwickler sind oft gezwungen, die "Gedanken" -Entwicklungsphase zu durchlaufen, oder sind gezwungen, ein Tool zu verwenden, das durch ein politisches Problem innerhalb des Unternehmens festgelegt wurde: "Der Bruder meines Chefs arbeitet für IBM, damit wir nur ihre Tools verwenden können." . Oder schlimmer noch, Sie bekommen ständig wechselnde Anforderungen vom Unternehmen, weil sie keine ordnungsgemäße Marktforschung durchführen können oder die Auswirkungen von Änderungen auf den Entwicklungszyklus nicht verstehen.
Es tut mir leid, dass ich mit diesem Geschwätz ein wenig vom Thema abkam. Ich habe ziemlich starke Meinungen zu diesem Thema.