Lohnt sich Clojure? Eure Meinungen zur Sprache.

[ctwx]

Guten Abend,

ich spiele mit dem Gedanken die Programmiersprache Clojure (http://www.clojure.org) zu lernen, da sie sich, wie ich immer wieder lesen muss, sehr für parallele Programmierung eignet. Außerdem wäre es für mich eine neue Herausforderung, weil ich noch keine funktionale Programmiersprache beherrsche.
Allerdings gibt es einige Nachteile die mich bedenklich werden lassen. Zum Beispiel stört es mich, dass Clojure-Programme keine natives Programme sind, sprich, sie benötigen eine Laufzeitumgebung, hier sogar die JVM, wo wir auch schon beim nächsten Punkt sind. Zwar bin ich grundsätzlich recht aufgeschlossen und programmiere teils auch in Java, habe aber nach dem Erfolg von Oracle gegen Google eher den Standpunkt eine solch, nun ja, proprietäre Sprache (und Umgebung) eher zu meiden.
Beim Umschauen ist mir aber auch noch Googles Programmiersprache "Go" aufgefallen, die soweit ja auch nicht schlecht ist, sie soll auch in Sachen parallele Programmierung sehr gut sein, nur da laufe ich gleich in die Arme des nächsten Firma. Das stimmt bei Clojure ja nur was die Laufzeitumgebung angeht.

Mich würde also interessieren: Was meint ihr? Ich bin auch gerne für andere Sachen offen, solange es kein Python ist.


Danke

[novalix]

Hi,

ich poste mal einfach ein wenig Lesestoff.
Clojure ist sicherlich eine sehr klug konzeptionierte Programmiersprache. Ein großer Teil ihres Erfolgs (im Sinne von quantitativer Verbreitung) liegt mit Sicherheit darin, dass sie auf der JVM aufsetzt und somit die für viele gewohnte Entwicklungsumgebung und Bibliotheken zur Verfügung stellt. Worse is better.

Groetjes, niels

[schorsch_76]

Da bleiben dir wenig Alternativen wenn keine Firma hintendran hängen soll.
- Go (Google)
- Java (Oracle)
- Python (Abneigung???)
- C#: Mono, es hängt wieder eine Firma hinten dran. Microsoft. Ja auch an Mono wegen den Patent Geschichten. Nicht Nativ.

+ Perl: Hab ich auch schcon einiges mit gemacht. Der Code sieht aus wie wenn sich ein Iltis über das Keyboard gewälzt hat. Ist aber schon ein paar Jahre her das ich damit Erfahrungen gemacht habe. Auch nicht nativ.

Alle Sprachen die der gcc kann, insbesondes ...
+ C: Der Klassiker
+ C++: Ebenfalls klassisch
Für die Klassiker gibt es viele Voruteile, viele Fans, viele Gegner. Für jede der beiden Sprachen. Vorteil von beiden: Nativ, freie Compiler (gcc/clang), viele Bibliotheken die zu Verfügung stehen. Ich kann natürlich auch viele Gegner verstehen. Es gibt anfangs bei beiden Sprachen eine realtiv hohe Einstiegshürde. Diese ist aber mit C++11 bei weitem nicht mehr so hoch wie früher. RAII,shared_ptr,handles und auto machen es einem deutlich leichter das ganze zu lernen. Wenn man diese Konzepte versteht, ist meiner Meinung nach, bei C++11 das meiste geschafft. (ja ich weis, ich arbeite schon seit vielen Jahren damit und kann das vielleicht nicht mehr wie ein Anfänger beurteilen).

Ich persönlich bevorzuge von allen Sprachen reines C++11 mit Boost [2] gewürzt. Das ist eine ganz andere Sprache als C++98. Hier kann ich dir das klassische Buch von Bjarne Stroustroup [1] empfehlen.

[1] http://www.amazon.de/C-Programming-Lang ... stroustrup
[2] http://www.amazon.de/Boost-C-Libraries- ... %C3%A4ling

[ctwx]

Danke euch Beiden für eure Antworten. Die Links schaue ich mir später mal genauer an.
Bisher habe ich mir einige Sachen zu Clojure durchgelesen und bisher eigentlich ganz gut zufrieden. Was mich an der Sprache vor allem fasziniert ist ja, dass es auf parallele Programmierung ausgelegt und eine funktionale Sprache ist. Das mich, wie gesagt an Clojure stört ist die JVM, die auf der anderen Seite natürlich große Vorteile birgt. Die JVM wäre ja nicht so schlimm, wenn sie nicht Oracle gehören würde, die ja auch noch erfolgreich gegen Google geklagt haben. Nicht dass es Google wirklich weh tun würde, aber ich denke hier geht es ums Prinzip. Ich habe mir auch den Quellcode von Clojure teilweise angeschaut und es sieht nicht so aus, als ob eine einfache "Ausgliederung" so ohne weiteres möglich wäre. Aber naja, ich gehe da einfach mal etwas positiver ran und werde mir Clojure mal genauer anschauen/lernen. Auch wenn sie keine nativen Anwendungen erzeugt.

Java nutze ich zwischendurch auch noch, nicht zuletzt weil ich es fürs Studium und die Arbeit brauche. Private nutze ich aber eher Ruby und C++. Zurzeit beschäftige ich mich auch noch mit C++11 und bin von den neuen Konzepten her echt begeistert. Ich habe die letzten Tage aber mal ein Programm geschrieben in C++ um Dateinamen in ein bestimmtes Format zu bringen und muss sagen, dass es teils schon echt eine Qual war. C++ bietet da leider keine Möglichkeit Ordner auszulesen, also müssen die schönen C-Funktionen her -- zumindest habe ich diese verwendet, also opendir und readdir. C++11 Features waren fast gar nicht nutzbar. In Ruby wären das höchsten 10 Zeilen gewesen. ^^

[fitheach]

Hast Du unter dem Aspekt "Parallel" und "Funktional" dir auch schon mal Erlang angeschaut.

[ctwx]

Hast Du unter dem Aspekt "Parallel" und "Funktional" dir auch schon mal Erlang angeschaut.

Erlang sieht auch nicht schlecht aus, trifft aber nicht ganz meine Vorstellung. Soweit ich erfahren habe, ist Erlang vor allem für verteilte Systeme geeignet. (Was auch interessant ist und ich mir sicherlich auch noch anschauen sollte.) Clojure hingegen eher auf Concurrency ausgelegt ist. (Stimmt das so?)

Ich packe Erlang aber definitiv auf die Liste, danke!

[fitheach]

Soweit ich erfahren habe, ist Erlang vor allem für verteilte Systeme geeignet. (Was auch interessant ist und ich mir sicherlich auch noch anschauen sollte.) Clojure hingegen eher auf Concurrency ausgelegt ist. (Stimmt das so?)

Ich habe das so nicht verstanden. Schau dir mal yaws, zotonic oder ein sonstiges Web-framework von Erlang an, da geht es auch eher um Concurrency.

Bin aber bei weitem nicht so der Profi.

Bei Erlang gefällt mir, dass hier (subjektiv) deutlich mehr Entwickler und Projekte am laufen sind.

[ctwx]

Ich habe diesbezüglich ein Foreneintrag gefunden, wo Rich Hickey (der Entwickler von Clojure) sich zu Wort meldet. Auch andere Quellen zeigen, dass Erlang eher für verteilte Aufgaben verwendet wird; so zum Beispiel ejabberd, den Jabberserver den Facebook verwendet. Rich Hickey hat auch ähnliches in einem Interview gesagt, in dem er sagt, er habe Respekt vor der Sprache und es fiele ihm schwer darüber zu urteilen (so etwas in der Art, habe die Quelle gerade nicht zur Hand).

Hier der Google Groups Foreneintrag: https://groups.google.com/forum/#!topic ... isk_-9dFjE

[peschmae]

Hast Du unter dem Aspekt "Parallel" und "Funktional" dir auch schon mal Erlang angeschaut.

Erlang sieht auch nicht schlecht aus, trifft aber nicht ganz meine Vorstellung. Soweit ich erfahren habe, ist Erlang vor allem für verteilte Systeme geeignet. (Was auch interessant ist und ich mir sicherlich auch noch anschauen sollte.) Clojure hingegen eher auf Concurrency ausgelegt ist. (Stimmt das so?)

Ich packe Erlang aber definitiv auf die Liste, danke!

Verteilte Systeme ist ja auch nur eine Generalisierung von Concurrency. Und letzteres (und ersteres) kann Erlang schon richtig gut, kommt ja auch aus dem Telefonanlagenbereich. Die Legende sagt ja Whatsapp betreibe damit 2 Millionen offene Connections pro Server, das ist erst mal richtig viel Concurrency. Ist bei mir auch schon eine Weile auf der Todo-Liste, aber man kommt ja zu nix.

Ganz allgemein: neue Programmiersprachen angucken ist sicher immer eine gute Sache, man lernt andere Konzepte kennen und kommt auf Designideen die man auch in der Haupt-Arbeitssprache umsetzen kann (oder zumindest möchte). Allerdings finde ich es schon wichtig, dass man sich erst mal eine Sprache richtig gut aneignet und damit auch richtige funktionierende Projekte baut, nur dann merkt man mit der Zeit welche Sachen wirklich wichtig/nützlich sind und welche eigentlich irrelevant...

Go (und das bisher unerwähnte Rust) gehören meiner Meinung nach etwas in eine andere Kategorie als Clojure (und das bisher auch unerwähnte Scala), das sind schon eher low-level Programmiersprachen, ich sehe die mehr als C-Ersatz. Kann mich aber auch irren, hab nur mal ganz kurz was mit Go rumgespielt...

MfG Peschmä

[Bert]

Kommt halt ganz drauf an was Du machen willst. Ich bin irgendwie bei Java hängen gebliebe, auch wenn ich mir immer mal wieder was anderes kurz anschaue.
Clojure hat mich dabei leider nicht angesprochen. Und zwar nicht, weil es in der JVM läuft, das sehe ich eher positiv) sondern da die Sprache meiner Meinung nach zu viele Aspekte vermischt und dadurch unnötig komplex wird.

Go sieht recht spannend aus, oder eben auch Dart.

[ctwx]

Ich finde an Clojure recht toll, dass es vorrangig auf funktionale Programmierung den Fokus setzt, aber auch andere Paradigmen zum Teil zulässt -- so hat Clojure beispielsweise Schleifen, die für funktionale Sprachen, so wie ich das mitbekommen habe, eher unüblich ist, da dort Rekursionen das Mittel zum Zweck sind.

Go finde ich wie gesagt auch ganz interessant. Hmmm Muss ich mal schauen.

[ctwx]

Ich habe mir ein paar Programme in Clojure und Erlang angeschaut und Erlang hat zumindest im quicksort-Algorithmus eine extrem kurzen Code, während der Clojure-Code ein Stück größer ist. Aber ich glaube, dass der Clojure-Code nicht ganz optimal ist, da im Beispiel die Funktion direkt aufgerufen und nicht mittels 'recur', da sonst TCO von der JVM nicht funktioniert.

Clojure: http://rosettacode.org/wiki/Sorting_alg ... rt#Clojure
Erlang: http://rosettacode.org/wiki/Sorting_alg ... ort#Erlang

Interessant!^^

[schorsch_76]

Auf solche Vergeiche kann man, meiner Meinung nach, nicht so viel geben.

Grund: Es gibt in jeder Sprache Konstrukte und Algorithmen die man sehr gut damit ausdrücken kann. Schau dir eher Fälle an, in denen es an die Grenzen der Sprache geht. Hier liegen nämlich die Herausforderungen.

[wanne]

Ja und vor allem hatten die authoren unterschiedliche Ansprüche. Ich bekomme in C auch einen einzeiler hin. Einfach qsort aufrufen.
Das ist zwar etwas extrem aber im endeffekt kommt es bei sowas nur dauf an wie exzessiv man libs nutzt. Stckt 90% des Codes in der lib ist der im Beispiel klein.
Dazu kommt, wie exzessiv man Whitspace benutzt und wie lange Variablennamen wman nutzt. Y ist z.B. ein super aussagekräftiger Variablenname aber dafür kurz. Deswegen sieht das Erlang beispiel so klein aus.
Es ist aber nur schwer lesbar. Bei dem Clojure Beipiel sieht man sofort was es macht. Und als C-Programmierer sehe ich schon wieder wo die massenweise unnötigen Speicherzugriffe stecken.

[Liffi]

Imho bringt es einen immer weiter, eine Sprache zu lernen, mit deren Paradigma man noch nicht wirklich vertraut ist. Wenn du noch keine funktionale Programmiersprache kennst, lerne Clojure! (oder Haskell, Erlang, Scala,....).
All diese Sprachen sollten sich, aufgrund ihrer funktionalen Programmierweise, brauchbar parallelisieren lassen.

Deine Anforderungen werden vermutlich am besten durch Haskell:
- Entwicklung wird nicht durch eine Firma
- Hohe Parallelisierbarkeit
- Funktional
- GHC (eine Implementierung) kann sowohl interpretieren als auch in native Maschinensprache übersetzen. Falls letzteres nicht direkt geht, kann auch C Code erzeugt werden (keine Ahnung, wie gut der ist )
- kein Python

[ctwx]

Und als C-Programmierer sehe ich schon wieder wo die massenweise unnötigen Speicherzugriffe stecken.

Kannst du das eventuell etwas genauer ausführen? Clojure verwendet ja die JVM und irgendwie hat sich die Meinung verbreitet, dass man heutzutage eh genug Ressourcen hat und lieber verschwenderisch sein soll, damit der Code "besser" aussieht -- mein Professor in Programmierung ist Java-Programmierer und meint, man könne lieber mehr Hardware kaufen anstatt sich mit solchen Sachen aufzuhalten.

Imho bringt es einen immer weiter, eine Sprache zu lernen, mit deren Paradigma man noch nicht wirklich vertraut ist. Wenn du noch keine funktionale Programmiersprache kennst, lerne Clojure! (oder Haskell, Erlang, Scala,....).
All diese Sprachen sollten sich, aufgrund ihrer funktionalen Programmierweise, brauchbar parallelisieren lassen.

Deine Anforderungen werden vermutlich am besten durch Haskell:
- Entwicklung wird nicht durch eine Firma
- Hohe Parallelisierbarkeit
- Funktional
- GHC (eine Implementierung) kann sowohl interpretieren als auch in native Maschinensprache übersetzen. Falls letzteres nicht direkt geht, kann auch C Code erzeugt werden (keine Ahnung, wie gut der ist )
- kein Python

Noch ein weiterer Kandidat? Das Entscheiden wird immer schwieriger. Google Go finde ich zwar so auch sehr interessant, aber ziehe ich mittlerweile nicht mehr in Betracht, da ich lieber etwas rein funktionales will. OK, Clojure ist da auch nicht 100% konsequent, aber das ist in Ordnung.

Haskell klingt interessant, mich würde hier aber interessieren, inwiefern es "parallel" besser beherrscht als Clojure -- denn da habe ich in letzter Zeit sehr häufig gelesen und gehört, dass Clojure hier einfach Spitzenreiter ist, obwohl ich mich natürlich frage, wieso, denn letztlich wird es ja auf Java Bytecode wieder abgebildet.

[ctwx]

Ich habe mich noch mal anderweitig weiter informiert und bin zu dem Entschluss gekommen, erst einmal mir Haskell anzuschauen, vor allem den Teil der parallelen Programmierung und anschließend mal Clojure um zu vergleichen, welche Sprache mir da eher zusagt. Grundsätzlich neige ich nun eher zu Haskell, weil sie nicht von der JVM abhängig, nativ kompiliert werden kann und nicht zuletzt, weil sie stark typisiert ist. Abgesehen davon habe ich einen Kollegen der auch Haskell gemacht hat, und er meint, die Syntax ist so grotten schlecht, dass ich lieber Haskell nehmen soll. Also will ich herausfinden was daran wahr ist.

Aber abgesehen von Haskell/Clojure werde ich mir auch weiterhin C++11 anschauen, was ich wirklich jedem empfehlen kann, der C++ bisher programmiert hat.

Vielen Dank für die bisherigen Antworten. Über weitere Kommentare würde ich mich freuen.

[wanne]

All diese Sprachen sollten sich, aufgrund ihrer funktionalen Programmierweise, brauchbar parallelisieren lassen.

Dem muss ich massiv wiedersprechen. Außer Haskell ist mir keine funktionale Sprache bekannt, für die es effiziente parallele implementierungen gibt. Es gibt vielleicht ganz nette spielereien aber es reicht eben nicht das Programm wild in irgend welche teile zu zerreißen und dann die auf möglichst vielen kernen auszuführen. Das sorgt dir nur dafür, dass deine CPU die ganze Zeit auf den RAM wartet weil man sich damit das Caching kaputt macht.
Parallelisierung auf Compilerebene funktioniert leider eben praktisch nicht. Defakto werden die programme durch die kleineren Chache-hit raten eher langsamer als eine singlethreated wariante. Insbesondere wenn man's dann mit C++ oder ähnlichem vergleicht.

C++11 anschauen

Tolles sprache zum produktiv arbeiten. Aber um neue konzepte kennen zu lernen würde ich das nicht unbedingt empfehlen. C++ kann eben alles. Führt dazu dass man das benutzt, was man eh schon kennt.

Und als C-Programmierer sehe ich schon wieder wo die massenweise unnötigen Speicherzugriffe stecken.

Kannst du das eventuell etwas genauer ausführen?

Nja du läufst das erste mal über die Liste und prüfst auf größer und dann läufst du nochmal drüber und prüfst auf kleiner gelich. Das kannst du auch in einem durchlauf haben.
Das nächste ist nicht mehr ganz so einfach. Dank der lazy-evaluation kann man da einiges optimieren. (Und ich kann mir durchaus vorstellen, dass der compiler das auch macht. Könnte mir aber auch vorstellen das nicht.) Aber so wie's da steht wird machst du dir da für jeden durchlauf eine neue liste mit anfangs unbekannter länge (variable längen sind ganz und gar nicht effizient) du hast am ende also wenn's dumm läuft log(n) listen im speicher statt einer.

irgendwie hat sich die Meinung verbreitet, dass man heutzutage eh genug Ressourcen hat und lieber verschwenderisch sein soll, damit der Code "besser" aussieht -- mein Professor in Programmierung ist Java-Programmierer und meint, man könne lieber mehr Hardware kaufen anstatt sich mit solchen Sachen aufzuhalten.

Jaja das sagen sie am anfang alle. Aber Zeit ist Geld. Und sachen dann auf mehr Hardware zu verteilen ist dann eher komplizierter als am anfang effizenten Code zu schreiben. Guck dir einfach mal an was Facebook da jetzt für nen Ärger hat.
Aber im Prinzip macht's Java schon richtig. da gibt's dann Array.sort und fertig. Sortieralorithmen u.ä. primitiva sind schön performant implementiert – teilweise sogar in C. Das ist wenig Code der oft ausgeführt wird. Für das eigentliche Projekt programmiert man dann in Java und guckt zuerstmal dass der schnell und lesbar geschrieben ist. Die reduzierte ausführzeit, die man da gewinnen kann kommt nie an das ran, was man an programmierzeit verliert.

Haskell klingt interessant, mich würde hier aber interessieren, inwiefern es "parallel" besser beherrscht als Clojure.

Nja: Guck dir einfach mal die benchmarks an. fannkuck-redux lässt sich wunderpar parallelisieren. Beide sprachen haben bei 4 CPUs etwa den Faktor 3.9 (Haskell sogar 3.92) Aber Haskell ist halt einfach mal über doppelt so schnell. Ist natürlich nicht representativ. Aber ich denke das das meiste etwa in die Richtung zeigt.
http://benchmarksgame.alioth.debian.org ... &data=u32q

[Liffi]

All diese Sprachen sollten sich, aufgrund ihrer funktionalen Programmierweise, brauchbar parallelisieren lassen.

Dem muss ich massiv wiedersprechen. Außer Haskell ist mir keine funktionale Sprache bekannt, für die es effiziente parallele implementierungen gibt.

Zumindest schon mal noch Erlang. Bei Scala habe ich mit Akka schon ein paar beeindruckende parallele Geschichten gesehen, aber sonst bin ich mir nicht sicher, wie die JVM die Parallelisierung bremst.

EDIT::
Nachdem ich mir auch ein paar Benchmarks angeschaut habe, muss ich sagen: Erlang scheint langsam zu sein 0_o?! Das widerspricht ein wenig dem, was ich glaubte verstanden zu haben .

EDIT2::
Ich denke das größte Problem ist, dass Parallelprogrammierung hart ist. Einige Sprachen nehmen einem einen großen Teil des Aufwands ab. Lowlevelsprachen eher nicht. Dort ist es dann erheblich einfacher, schöne Deadlocks zu produzieren.

[peschmae]

Nachdem ich mir auch ein paar Benchmarks angeschaut habe, muss ich sagen: Erlang scheint langsam zu sein 0_o?! Das widerspricht ein wenig dem, was ich glaubte verstanden zu haben .

Kommt sicher wie immer nur darauf an was du genau benchmarkst...

MfG Peschmä