Ich enpfinde llvm in vielen Dingen angenehmer. Weniger Murks im Code, Online Prüfungen, schneller an Ergebnisse. Gott sei Dank hat sich Apple frühzeitig dem angenommen, sonst würden wir uns immer noch mit kryp. Fehlermeldungen herumquälen.
LLVM ist ein sehr guter Ansatz und es wird mit dieser Plattform noch jede Menge Forschung betrieben, dass LLVM noch besser wird. Ich finde auch das Projekt PyPy sehr interessant: Ein Python-Compiler, der in Python geschrieben. Vor acht Jahren war das Ding richtig langsam, aber mittlerweile schneller als CPython. Warum? Weil sich dort Theoretiker austoben können und zeigen, dass systematische Ansätze besser sind.
Aus meiner Entwicklertätigkeit weiß ich zu berichten, dass die Titulierung als "overenginieered" häufig dazu dient, die besseren Ansätze im Keime zu ersticken, weil man intellektuelle Defizite hat. LLVM macht natürlich erstmal ein bisschen Aufwand, aber das Resultat ist doch, dass man dann auf einer anderen Ebene seine Gedanken schärfen kann, was zu einem besseren Gesamtergebnis führt. Die Assembler-Programmierer haben sicherlich auch gesagt, die Hochsprachen seien overengineered. Was da alles reingesteckt würde: Sprachen mit komplizierter Lexik, Syntax und Semantik, Compiler etc. Glücklicherweise konnten sich die Assembler-Programmierer nicht durchsetzen. Die ersten Hochsprachen waren prozedural und unter den Freunden dieser Sprachen haben sich auch viele getummelt, die meinten, sie bräuchten keine Objektorientierung... Wie die Geschichte ausging, wissen wir auch. Objektorientierung liefert auch nicht zwangsläufig den schlechteren Code, selbst wenn viel Infrastruktur drumherum bereitgestellt wird, die der Fortran-Entwickler erstmal als völlig unnötig abtut. Aber die Gedanken des Entwicklers werden geschärft, sodass eine objektorientierte Programmiersprache in besseren Code und häufig auch in schnelleren Code resultiert.
Oder nehmen wir die RISC-Maschinen. Die Entwickler von RISC-Prozessoren haben die vielen hyperperformanten Spezialbefehle einfach rausgeschmissen. Die CISC-Praktiker waren der Ansicht, das müsse zwangsläufig langsamer werden. Mit den RISC-Maschinen erhielt aber Pipelining Einzug. Das wäre nicht möglich gewesen, wenn der Befehlssatz nicht enorm reduziert worden wäre. Pipelining erhielt dann auch in CISC-Maschinen Einzug.
LLVM wird noch für mehr Furore sorgen. GCC wird entweder Konzepte aus LLVM übernehmen oder sterben.
Ich enpfinde llvm in vielen Dingen angenehmer.
Weniger Murks im Code, Online Prüfungen, schneller an Ergebnisse.
Gott sei Dank hat sich Apple frühzeitig dem angenommen, sonst würden wir uns immer noch mit kryp. Fehlermeldungen herumquälen.
llvm=overengineered silver bullet die viel will aber wenig kann
gcc=praktikabel, tut was es soll
LLVM ist ein sehr guter Ansatz und es wird mit dieser Plattform noch jede Menge Forschung betrieben, dass LLVM noch besser wird. Ich finde auch das Projekt PyPy sehr interessant: Ein Python-Compiler, der in Python geschrieben. Vor acht Jahren war das Ding richtig langsam, aber mittlerweile schneller als CPython. Warum? Weil sich dort Theoretiker austoben können und zeigen, dass systematische Ansätze besser sind.
Aus meiner Entwicklertätigkeit weiß ich zu berichten, dass die Titulierung als "overenginieered" häufig dazu dient, die besseren Ansätze im Keime zu ersticken, weil man intellektuelle Defizite hat. LLVM macht natürlich erstmal ein bisschen Aufwand, aber das Resultat ist doch, dass man dann auf einer anderen Ebene seine Gedanken schärfen kann, was zu einem besseren Gesamtergebnis führt. Die Assembler-Programmierer haben sicherlich auch gesagt, die Hochsprachen seien overengineered. Was da alles reingesteckt würde: Sprachen mit komplizierter Lexik, Syntax und Semantik, Compiler etc. Glücklicherweise konnten sich die Assembler-Programmierer nicht durchsetzen. Die ersten Hochsprachen waren prozedural und unter den Freunden dieser Sprachen haben sich auch viele getummelt, die meinten, sie bräuchten keine Objektorientierung... Wie die Geschichte ausging, wissen wir auch. Objektorientierung liefert auch nicht zwangsläufig den schlechteren Code, selbst wenn viel Infrastruktur drumherum bereitgestellt wird, die der Fortran-Entwickler erstmal als völlig unnötig abtut. Aber die Gedanken des Entwicklers werden geschärft, sodass eine objektorientierte Programmiersprache in besseren Code und häufig auch in schnelleren Code resultiert.
Oder nehmen wir die RISC-Maschinen. Die Entwickler von RISC-Prozessoren haben die vielen hyperperformanten Spezialbefehle einfach rausgeschmissen. Die CISC-Praktiker waren der Ansicht, das müsse zwangsläufig langsamer werden. Mit den RISC-Maschinen erhielt aber Pipelining Einzug. Das wäre nicht möglich gewesen, wenn der Befehlssatz nicht enorm reduziert worden wäre. Pipelining erhielt dann auch in CISC-Maschinen Einzug.
LLVM wird noch für mehr Furore sorgen. GCC wird entweder Konzepte aus LLVM übernehmen oder sterben.