Dirk schriebLycanthropist schriebSeit ich im ersten Semester eine Vorlesung (+Übung) über Scheme gehört habe, beschäftige ich mich mit der Sprache. Man merkt ihr wirklich ihren akademischen Charakter an
Ja, als „Lehrsprache“ ist Scheme wirklich gut. Aber ich bin ehrlich gesagt ganz froh, dass es außerhalb von Hörsälen keine all zu große Verbreitung hat 🙂
Es ist vor allem für den Compilerbauer ein Spass. Man braucht für Lisp (Scheme und sowas) nicht einmal einen richtigen Parser, ein einfacher Scanner mit einem Stack langt meist schon. Einen vollständigen Lisp-Interpreter zu bauen, schafft man mit boost::spirit auf einer Bildschirmseite. Es ist erstaunlich, dass sich Lisp-ähnliche Notationen nicht viel häufiger, beispielsweise in Konfigurationsdateien o.ä. finden.
Lycanthropist schriebSowas ist in C(++) nun mal sehr schnell im Vergleich zu Skriptsprachen.
Ja, kompilierte Sprachen sind alleine vom Prinzip her schon schneller als interpretierte Sprachen.
Ich verstehe diese ganze Diskussion nicht so richtig. Mir kommt das immer bisschen so vor wie welcher Floh jetzt den besseren Hund hat. Und wenn einer auf einen anderen überspringt, dann ist der halt besser und der frühere schlecht, bis er auf den nächsten springt.
Man kann in den allermeisten Sprachen ordentlichen Code schreiben, und auch sehr schlechten, fehlerträchtigen, ineffizienten. Es hängt nicht zuletzt auch von den Laufzeitbibliotheken und dem Betriebssystem ab. Je höher Hochsprachen werden, umso mehr macht sich der Einfluss von Overhead bemerkbar, der getrieben werden muss, um an tieferliegende Schichten bis hin zum Betriebssystem zu kommen. Das muss aber nicht heissen, dass solche Sprachen grundsätzlich langsam sind. Rechengeschwindigkeit ist ja ohenhin etwas, das im Zeitalter der GHz-Mehrkern-Prozessoren etwas in den Hintergrund rückt, Zeit geht heute nicht unwesentlich bei I/O-Operationen (Festplatte, Flashspeicher, Netze) verloren, das sind moderne Flaschenhälse.
Selbst das Interpreterprinzip muss nicht unbedingt langsam sein - letztendlich macht ja ein Prozessor auch nichts anderes, als Maschinenbefehl für Maschinenbefehl zu interpretieren. Zugegeben, Negativbeispiele gibt's immer. Unter Visual Basic 3 spielte es eine Rolle, ob man Leerzeilen oder Kommentare in seinen Code gemacht hat oder nicht. Eine Schleife, bei der zwischen for und next zehn Leerzeilen standen, benötigte messbar länger als eine, die wirklich leer war. Ich hatte mal einen Kollegen, der hat das durch Messungen nachgewiesen.
Was Sprachen angeht, so halte ich es für vernünftiger, andere Eigenschaften zu diskutieren: Einsatzspektrum, Flexibilität (vs. Spezialisiertheit), Lernkurve, Eleganz, Les- und Wartbarkeit, Möglichkeiten zur Qualitätssicherung, Parallelität. Dort finden sich weit mehr und stärkere Unterschiede als nun ausgerechnet in der Geschwindigkeit.