Keine moderne Sprache für Unix in Sicht?

[nakal]

Ich war schon in der Wirtschaft. Ich weiß, dass fälschlicherweise oft "der Billigere" bevorzugt wird. Ich sage es nur so krass, dass es besser ist, bei Programmen (auch schon kleinen Tools) Qualität zu wählen und die kostet halt ein wenig mehr. Ich habe auch gesagt, dass es im schlimmsten Fall doppelt so viel kostet. Bitte das beachten, weil ich von einem mal zur Abwechslung "erfahrenem Java-Programmierer" ausgegangen bin. Diese Spezies ist aber eine Seltenheit und wird deswegen auch etwas mehr kosten, was ich auch nicht beachtet habe.

Ich will Euch nur ein Beispiel aus der Wirtschaft geben, damit meine Frust mal klar wird. Ihr könnt natürlich sagen "Siehst Du!".

Mich hat ein Kunde mal gefragt wie viel ich für sein Projekt brauche. Ich habe ganz ehrlich geantwortet "eine Woche mit Tests und bis es glatt läuft". Der Kunde hat auch meinen Kollegen gefragt und er meinte "2 bis 3 Tage". Ich hab etwas geschmunzelt, weil ich wusste, dass das nicht klappen wird. Natürlich hat ER die Arbeit aufgehalst gekriegt, weil alles ja schneller fertig wird. Tja... nach 3 Monaten habe ich aus Neugier gefragt wie es läuft... er war immer noch dran. Natürlich. Immerhin hat er aber das Projekt geholt. Ich wäre da echt in einer Woche komplett fertig und hätte nicht so viel gekostet wie er, weil er ja nur für 2 bis 3 Tage bezahlt wird. Das geht hier jetzt übrigens nicht um Java vs Nicht-Java.

Ich bin inzwischen allergisch gegen die "Uni-Sprache". Viele sind der Meinung sie hätten die Weisheit mit den Löffeln gefressen, wenn sie Java kennengelernt haben.

Und was mich vor allem aufregt ist, dass C belächelt wird. Insbesondere von den Leuten, die es gar nicht kennen. Man hört dann immer wieder so etwas wie "C ist fehleranfällig" oder "C? Wieso dann nicht gleich Assembler?". Das ist grober Unfug und pure Ignoranz. Entweder man kann es, oder man macht Fehler.

Im nächsten Satz hört man nämlich von den Leuten, dass sie erst Version 1.1 oder 1.2 lieber nehmen, weil sie dann "ausgereifter" sind. Oder womöglich für den Kunden nie eine 1.0-Version ausgeben, sondern direkt als "2.5.4" herausgeben, damit der Kunde nicht meint es wäre eine instabile erste Version.

Das hängt alles zusammen. Ich habe sehr großen Respekt vor Leuten, die mit einer Sprache toll umgehen können, unabhängig von der Sprache. Aber ich sag das mal einfach so platt... solche Leute findet man gehäuft eher bei C. Von denen kann man schöne Sachen lernen. Bei Java sind sie sehr rar. Kein Wunder "Java-Experten" schießen ja überall wie Pilze aus dem Boden. Und sie haben keine Scham zu behaupten, dass sie Java kennen. Sie kommen ja von einer Uni und haben einen Java-Schein oder so.

So viel zu "moderner Sprache Java". Ich sage immer "Überzeugt mich durch Taten!" und das ist auch eine sprachenneutrale Aussage.

 

[Kamikaze]

Also OO ist keine Spracheneigenschaft, sondern ein Paradigma. Das bedeutet, dass man sehr wohl nach OO-Art in C programmieren kann. Dass die Sprache C OO schlecht unterstützt ist hierbei vielleicht nennenswert.

Sehr richtig! Ich würde sogar viele Teile des FreeBSD-Kerns als objektorientiert bezeichnen. Das ist nicht besonders strikt eingehalten und war wohl auch keine bewusste Entscheidung, aber das Muster ist schon immer wieder mal zu erkennen.

 

[danlei]

Ansi Common Lisp ist eine herausragende Sprache. Es gibt mehrere gute, freie Implementierungen. Die Syntax ist extrem einfach, das Objektsystem CLOS mächtig und die Macros einzigartig. Meiner Meinung nach die perfekte Sprache.

Man könnte noch weitere Vorteile nennen, aber kurz: Dem schließe ich mich an.

Es gibt nur wenige gepflegte, externe Bibliotheken. Die Bibliotheken sind oft abhängig von der jeweiligen Implementierung. Die Dokumentation der Bibliothekn ist, vorsichtig ausgedrückt, unterirdisch.

Jaja, das alte Problem mit den Libs

Also, ich muss dir leider erstmal recht geben: im Vergleich zu anderen Sprachen (Stichwort: Batteries included) siehts da eher mager aus, aber ein bisschen differenzieren muss man schon – zum Beispiel ist alles aus Edi Weitz' Feder stabil, gut getestet und vorbildlich dokumentiert.

Vieles, was sich beispielsweise im Cliki findet ist auch eigentlich ganz brauchbar, aber im vergleich zum Cpan beispielsweise ... naja.

Ansonsten kann ich nur sagen, dass es in CL wirklich sehr einfach ist, sich seine Bindings selbst zu schreiben (cffi), was vielleicht unter anderem, neben der relativ kleinen – aber, bis auf die ganzen Rants und Trolle à la Harrop und Xah in c.l.l., feinen – Community, und einer gewissen Einzelkämpfermentalität, zur Situation beiträgt.

Ein, für mich vollkommen ausreichendes, Binding zur xine-lib hatte ich beispielsweisen in ca 20 Minuten zusammengehackt.

Sicher, man kann nicht von jedem – gerade heutzutage – erwarten, dass er sich für jede Kleinigkeit mal eben seine Bindings schreibt, aber es wird einem mMn wirklich sehr leicht gemacht. (Bis auf die Tatsache, dass man sich halt entsprechend in die jeweilige Doku, oder den Code einlesen muss und somit eben doch wieder mit C in Berührung kommt. Vom, trotz aller Einfachheit doch vorhandenen Aufwand abgesehen, ist es natürlich auch ein Unterschied, ob man sich sowas zusammenhackt, eine Lib aus dem Cliki verwendet, die vielleicht von 100 Leuten benutzt (und somit auch getestet) wird, oder, auf der anderen Seite, eine Sprache wie Java benutzt, wo tausende Code-Monkeys Libs zu allem Möglichen produzieren, die dann auch von tausenden und abertausenden Usern genutzt/getestet werden.

Neuere Abkömmlinge haben auch wieder Probleme: Clojure braucht die JVM von Java.

Was ich persönlich als einen Vorteil ansehe. Du sprichst oben fehlende Libs an. Rich hat dieses Problem von Anfang an vermieden, indem er auf die JVM aufsetzt. Mehr Libs kann man sich eigentlich nicht wünschen, mal ganz davon abgesehen, dass Clojure wirklich eine der bemerkenswertesten Entwicklungen in Sachen Lisp der letzten Jahre ist. (Stichworte: STM, Lazyness, etc.)

Ich habe beispielsweise letztens einen kleinen Swing-Mud-Client geschrieben, der mir wirklich sehr gut von der Hand ging und nebenbei plattformübergreifend funktioniert. Die Verbindung zu Java ist sehr gut gelöst und wirkt in keinster Weise aufgesetzt, man hat eher das Gefühl, das beste beider Welten unter den Fingern zu haben. (Und ich gehöre perönlich zu der Fraktion, die ansonsten einen wirklich großen Bogen um Java macht)

Ganz nebenbei, für alle mit Klammernphobie: In nicht wenigen Beispielen kommt man in Clojure mit weniger Klammern aus, als in Java.

Sicher, ich vermisse einige Features von CL (z.B. Das ungeschlagene Condition-System, Multiple-Return-Values, CLOS, MOP, den Debugger, etc., aber es ist nunmal nicht CL, sondern etwas Neues und dafür wurde es auch Zeit.

NewLisp hat wieder per default dynamic scope.

Mit NewLisp habe ich persönlich kaum Erfahrung, aber was ich gesehen habe, hat mir zum Teil den Eindruck vermittelt, dass aus der Vergangenheit nicht unbedingt gelernt wurde. (z.B. die Verwendung von fexprs/eval, die in NewLisp idiomatisch zu sein scheint. Lexikalischer Skopus scheint zwar mit Environments möglich zu sein, aber ich habe mich, wie gesagt, nicht eingehend mit NewLisp beschäftigt)

Ansonsten könnte, wie weiter oben schon erwähnt, PLT etwas für Dich sein, wenn Du denn zur dunklen Seite der Macht wechseln möchtest.


Edith sagt:

So schön Sprachen wie Lisp für spezielle Anforderungen genial sein mag, oder so umfangreich die Std-Java-Lib sein mag... sie sind zu speziell!

Also, ohne Lust auf eine Diskussion zu haben, welche Sprache nun zu was zu speziell sind, oder nicht:

Dir ist schon bekannt, dass es Lisp-Maschinen gab, die zu ihrer Zeit absolut begehrte High-End Maschinen waren und bis zum Metall in Lisp programmiert waren? (Wens interessiert, der kann mal z.B. Medley ergoogeln, läuft bei mir in ner VM auf nem DSL mit altem Kernel)

Common Lisp ist lediglich ein Kompromiss – der Versuch (initiiert von der ARPA) die vielen konkurrierenden Dialekte unter einen Hut zu bekommen. CL != Lisp. Niemand verbietet einem Vendor, seine Implementationen mit Features wie beispielsweise händischer Speicherverwaltung auszustatten. Allein, wenn sich eine Implementierung CL nennen will, muss unter COMMON-LISP eben alles konform sein. Wenn mir irgendetwas an der Sprache nicht passt, dann schreib ich mir ein Package danlei-lisp und kann mir darin die Sprache formen, wie es mir gerade genehm ist und das mit Sprachmitteln. Lisp ist general-purpose, EOD.

Lisp Makros transformieren den Syntaxbaum eines Programms während des Kompiliervorgangs. Sie erweitern sozusagen den Compiler.

Fast: Zur Macro-Expansion-Time, nicht zur Compile-Time; ein kleiner aber nicht unwichtiger Unterschied.

 

[troll]

Was ne schräge Diskussion...
Wer mehr als zwei Sprachen beherrscht sollte wohl verstehen, dass Sprache und Anwendungszweck zusammengehören.
Ich hasse das. Java wurde z.B. so von den Unis gepuscht, dass man in jeder Projektanforderung das Wort Java liest. Vollkommener Schwachfug - eine Sprache ist kein Allheilmittel.

 

[kili]

Haskell ist geil, sofern man nichts großes entwickeln muss.

So gross wie z.B. GHC oder Darcs?

Bei mehr als einer Person im Projekt skaliert diese Sprache nicht ;-)

Zumindest am GHC und den ganzen Libraries arbeiten schon mehr als nur zwei Nasen.

Das Problem mit Haskell ist nur, dass man im Prinzip nicht um den GHC herumkommt, weil viele in Haskell geschriebenen Programme GHC-Extensions verwenden, weil die neue Sprachspezifikation (Haskell') nicht in die Poette kommt, und weil der GHC (IMHO) ein wenig zu fett und zu schwierig zu portieren ist.

 

[MuffiXXL]

Als ich mir das durchlas dachte ich spontan an D, allerdings kamir gerade Perl 6 mit Parrot in den Sinn. Ich denkemal Perl 6 wird sehr spannend werden. Vor allem der Parrot Assembler klingt sehr geil. Ich habe letztens mal angefangen mir das ein wenig anzuschauen und muss sagen es gefällt mir extrem gut.

 

[oenone]

Zuerstmal bin ich mir noch nicht ganz sicher, ob das ein Troll ist oder nicht...

Die Pascal-Reihe fand mit Ada ihr Ende. Nebenläufigkeit im Sprechkern und die beste Unterstützung für eigene Datentypen, die ich je gesehen habe, können über die Mängel nicht hinwegtäuschen. Die Lizenzsituation ist bestenfalls unübersichtlich. Die Standardbibliothek unfasst keine Schnittstellen nach außen: Netzwerk, XML, RPC, Datenbanken, GUI, ... Es gibt kaum freie, gewartete Bibliotheken von Drittherstellern.

Ada ist keinesfalls mit Pascal verwandt, es hat lediglich ein paar Ähnlichkeiten in der Syntax. Auch ist Ada noch nicht zu Ende. Der neueste Standard ist Ada 2005 und es wird noch aktiv weiter daran gearbeitet. Mit Lizenzsituation meinst du wohl die vom GPL lizenzierten, auf GCC basierten GNAT. Da ist aber nichts wirklich unübersichtlich... Für Netzwerk, XML, RPC, DB, GUI usw gibt es viele Libs (einige von AdaCore, andere freie Bindings, die noch aktiv weiterentwickelt werden). Einen großen Mangel sehe ich hier nicht. Klar, es könnte besser sein, aber im Grunde kann man jede C-Lib auch in Ada nutzen.

Gruß,
oenone

 

[Athaba]

Hihi, Sprachen führen genau so gut zu Flames, wie Betriebssysteme, Lizenzen und Co.
Als ich zu programmieren (falls man das so nennen kann) begonnen habe, hatte ich auch die Probleme, dass alle Sprachen in irgendeiner Form veraltet war oder wie Ruby "zu neu".

Dann habe ich mich für das gute alte Perl entschlossen, weil das der Durchschnitt von allem, was ich ausprobiert habe war und weil ich auf cpan für alles ein Modul gefunden habe.

In letzter Zeit ist mein Interesse an OO gestiegen und ich habe wieder begonnen mir andere Sprachen anzugucken - auch nicht-OO-Sprachen bzw. Sprachen, die nicht wirklich dafür geeignet sind. Am Ende hielt ich es für das Beste bei Perl zu bleiben bzw. auf Perl6 zu warten und zu hoffen, dass sich genug andere Sprachen an Parrot beteiligt. Damit komme ich wieder zum Thema zurück. Was wirklich fehlt ist IMO nämlich Parrot. Dabei handelt es sich quasi um ein (viel) "besseres" .NET/mono für dynamische Sprachen. Auch, wenn das Projekt rein technisch, vom Status und von der kontinuierlichen Entwicklung sehr gut dasteht befürchte ich, dass es einfach an Hype oder was auch immer nötig ist fehlt um die Entwickler anderer Sprachen an Board zu holen.

Ich sehe im Vergleich *nix zu Windows nämlich nur .NET, was hehlen könnte. Mir Parrot ließe sich wohl auch jede Menge Manpower sparen, aber wie erwähnt glaube ich, dass dem einige emotionale Hindernisse im Weg stehen. Viele Entwickler neigen nämlich dazu ihren eigenen Code trotz aller Widrigkeiten weiterzuentwickeln und nicht auf neue Basis umzusteigen.