000
24.04.2009, 12:41 Uhr
Bruder Leif
dances with systems
(Operator)
|
Moin!
In den Firmen, in denen ich bisher gearbeitet habe, haben wir immer mal kleine Meinungsautausche durchgefuehrt, in denen wir den anderen unsere Gedanken zu unseren "Lieblingssprachen" mitgeteilt haben, und jeder hat dabei das eine oder andere gelernt, und Vorurteile (negative UND positive) aus dem Weg geraeumt, oder von Sprachen gehoert, die kennenzulernen sich lohnen wuerde...
Daher mal die allgemeine Frage: Wie steht Ihr zu den von Euch _primaer_ eingesetzten Sprachen? Was gefaellt Euch, was stoert Euch? Im einen oder anderen Thread schreibt jeder mal ein paar Zeilen zu seiner Meinung, aber eine kompakte Zusammenstellung aller Rants und Werbung auf einer Seite, das waere doch mal was...
Das soll dabei KEIN Flamewar werden, keine grosse Diskussion ueber die Objektivitaet der einzelnen Aussagen, sondern ausdruecklich eine _subjektive_ Aufstellung _persoenlicher_ Meinungen. Wer sich dann die Meinung der anderen mal in Ruhe durchliest, ohne gleich mit dem Messer aus dem Busch zu springen, hat ordentlich Gelegenheit, was dazuzulernen.
Dann giess ich mal die ersten Liter Benzin aus:
C:
Eigentlich hat C das Zeug, zu meiner Lieblingssprache zu werden. Einfach, kompakt, schnell, keine Ueberraschungen, ueberall verfuegbar. Dummerweise ist der Aufwand beim Programmieren eine grosse Produktivitaetsbremse. Es gibt zwar haufenweise Libs, die die etwas magere Standardbibliothek erweitern, aber keinen wirklich sauberen roten Faden, der sich durch das Ganze zieht. Daher nehme ich C primaer zum Optimieren performance-kritischer Teile von Programmen, die in anderen Sprachen geschrieben sind. Speicherprobleme habe ich keine; wer keine Lust hat, auf seine Allokationen aufzupassen, kann ja die gc-lib dazulinken, und saubere OOP mit Information Hiding ist tatsaechlich moeglich! Wer sich an das Prinzip haelt, statt Implementierungen nur Interfaces zu vererben (was in "echten" OOP-Sprachen ebenso/erst recht gilt!), hat keine Probleme.
C++:
Eine Sprache, deren Kern nicht in hoechstens 100 Seiten A4 vollstaendig beschrieben werden kann, ist in meinen Augen keine gute Sprache, und sei sie noch so maechtig. Wer Meyers und Sutter gelesen und verstanden hat, weiss, was gemeint ist. Dafuer hat C++ einige Features, die ich in anderen Sprachen schmerzlich vermisse: In erster Linie Const Correctness und das deterministische Ausloesen von Destruktoren. Die Templates sind von der Funktionalitaet her ein Traum, aber was die Lesbarkeit der Compilermeldungen bei Fehlern in Template-Code angeht... wei owei... Was mich am meisten an C++ stoert: Die Fallstricke. Da glaubt man, sich mit der Sprache auszukennen, kauft das naechste Buch von Herb Sutter, und faellt _schon wieder_ so richtig ordentlich auf die Nase. Wer hier kann z.B. mit "Koenig Lookup" was anfangen, ohne zu googlen? Komplexe Sprache == komplexer Compiler. Mir persoenlich geht Einfachheit ueber Leistungsfaehigkeit, daher ist C++ einfach nicht meine Lieblingssprache.
C#:
Auf den ersten Blick verlockend. Auf den zweiten auch. Schnelle Resultate, kein grosser Aufwand, gute Tools. Was mich in erster Linie daran stoert: Kaum hat man sich an WinForms gewoehnt, kommt WPF. ASP.net? Silverlight! Achja, wir bauen jetzt ein paar dynamische Features in die Sprache ein. Hm, wie waere es mit Lambda-Ausdruecken? Achja, ein paar deklarative Features (LINQ!) waeren auch toll. Was flanschen wir als naechstes dran? Was mir an C# fehlt, ist eine klare Linie. Staendig kommt was neues dazu, bevor man die Gelegenheit hatte, den bisherigen Wust durchzuackern. Und die Bibliothek ist ganz klar fuer das schnelle Entwickeln von Software designt, und nicht fuer die spaetere Wartung. Sorry, mir ist die Wartung wichtiger als das Neuentwickeln. Und rein proprietaere Systeme und Specs (der ECMA-Standard geht nur auf die untersten Grundlagen ein!) haben vom reinen Idealismus her sowieso gleich verloren. Dummerweise muss irgendwo das Geld herkommen, mit dem ich das Essen fuer meine Kinder kaufe... *ahem*
Java:
Mein Verhaeltnis zu Java war nicht immer das beste, siehe "gewisse Threads" aus der Vergangenheit  Inzwischen sehe ich Java als eine der Sprachen an, mit denen ich neue Projekte noch am ehesten angehen wuerde. Auch wenn die "Sauberkeit" der Sprache in den neueren Versionen gelitten hat und immer mehr syntaktischer Zucker dazukommt, ist es im Kern (!) immer noch eine recht schlanke Sprache ohne allzu viele Ueberraschungen. Design Patterns werden in der Standardbibliothek konstruktiv eingesetzt, und zwar da, wo sie Sinn machen. Was mich am meisten daran stoert: Die immer groesser und speicherhungriger werdenden Implementierungen der VMs, und die Inkonsequenzen in der Bibliothek. Man merkt der Lib an, dass sie mal wesentlich kleiner war, und immer wieder neue Teile dazugekommen sind. Trotzdem fuehlt sie sich -- subjektiv -- wesentlich sauberer an, als die von .NET. Was mich noch nervt: Out of memory. Wie oft habe ich die Exception in letzter Zeit bekommen?! Da versucht man, eine 45-MB-Textdatei zu parsen, und die VM steigt aus. Hallo? 4GB RAM, 4GB Swap, und mein Programm kann keine 45-MB-Datei einlesen?!? OK, mit den Non-Standard-Optionen mehr Heap erlauben. Aber was, wenn mal noch mehr Speicher benoetigt wird? Oder die VM die entsprechende Option nicht anbietet? Was noch nervt, wenn auch nicht so sehr: Ist es jetzt die Methode length() oder getLength() oder size() oder getSize() oder die Eigenschaft .length oder... ?! Bei der STL unter C++ ist es IMMER size(), und gut.
Perl:
Was fuer C++ gilt, wird hier auf die Spitze getrieben. Wie gross ist nochmal die Sprachbeschreibung von Perl? Ach, es gibt gar keine? Der Interpreter selbst ist die Spec? Und an welchen Stellen kann nochmal die Perl Magic einspringen und mir einen Strich durch die Rechnung machen? Danke, nein. Perl ist schoen pragmatisch, recht schnell, und CPAN sucht bei anderen Sprachen seinesgleichen. Fuer kleine einmal-und-dann-wegwerfen-Skripte wunderbar, aber groessere Programme in Perl -- agh.
Python:
Ganz so schlecht finde ich Python gar nicht. Zumindest stilistisch sauberer als Perl. Dass Bloecke per Indentation definiert werden statt per Klammern -- na und. Der Code ist lesbar, und man kommt als Einsteiger extrem schnell zu Resultaten. Was nervt, sind die Bugs in der Lib, die Sturkoepfigkeit, mit der der "pythonic way" ueber alles gesetzt und Verbesserungsvorschlaege kommentarlos als "unpythonic" abgewiesen werden, und die Inkonsequenz Strukturiert/OOP. War es jetzt x.length() oder length(x)? Achja, es hiess len(x). Autsch. Dann haben wir zwar funktionale Elemente, aber keine Tail Recursion Elimination. Weil "unpythonic". Und reduce() wird entfernt, weil das fuer die Programmierer zu kompliziert ist. Bitte?!? Wer _damit_ nicht klar kommt, hat als Programmierer eindeutig den falschen Job!
Tcl:
Eine -- leider -- zu oft und leicht uebersehene Sprache. Tcl besitzt die konzeptionelle Reinheit, die ich in anderen Sprachen vermisse, ohne gleich zu Brainfuck oder Lisp zu verkommen. Ein Tcl-Interpreter, mit dem sich Real-World-Programme schreiben lassen, kann in unter 1000 Zeilen C runtergeschraubt werden. Die Sprache ist extrem dynamisch, und erlaubt die komplette Umstellung der Sprachdefinition selbst vom Quellcode aus. Schon mal die Semantik des if-Befehls um Logging-Funktionen erweitert? Funktionsdefinitionen erweitert, so dass eine Funktion ab einer bestimmten Laenge nicht mehr lokal, sondern automatisch auf einem anderen Rechner definiert und dort ausgefuehrt wird, vollkommen transparent? Die Moeglichkeiten sind endlos. Was stoert mich dann daran? Tcl ist laaaaaaaaangsam. Gut, der Geschwindigkeitsnachteil ist O(1), und die Bibliothek selbst ist schnell, aber trotzdem... Und dass assoziative Arrays zwar Teil der Sprache sind, aber keine First-Class-Typen, ist eklig. OK, dazu braeuchte man eine zusaetzliche Regel im Standard, die Sprache waere nicht mehr _ganz_ so rein, und eine Datenuebergabe per Zugriff-auf-die-Variable-im-uebergeordneten-Stack-Frame-ueber-ihren-dort-lokalen-Namen (!!!!!), was in Tcl-Semantik nicht ganz 100%ig by Name entspricht, ist bei groesseren Datenmengen schneller als by Value, aber es waere einfach schoen. In den neueren Versionen gibt es immerhin die OOP-Version "Dict", aber der inherente Typ waere eigentlich gut genug, wenn...
Mein Fazit:
Unix-Prinzip for teh win! Alle diese Sprachen sind unter BSD, Linux, OS X, sonstigen Posix-Systemen und Windows verfuegbar, wobei ich um Mono eher einen Bogen mache. Teilen wir unser Grossprojekt also in mehrere kleine Einzelprogramme auf, die ueber sauber definierte Schnittstellen kommunizieren. Wenn mir dann ein Tcl-Prototyp nicht mehr zusagt, wird er in C umgesetzt. Oder in Java. Oder was auch immer am besten zum jeweiligen Problem passt -- womit wir wieder bei "The right tool for the job" waeren. DIE Lieblingssprache gibt es fuer mich nicht. Und auf eine einzelne Sprache fuer ein monolithisches Grossprojekt lass ich mich nur noch ein, wenn der Chef das alleinige Sagen hat... *hust*
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook. |
Viele Bugs erhalten so niemals die Chance, ausgeliefert zu werden.
