Script-Geschwindigkeiten
Wenn ich mir ansehe was wir früher von Scriptsprachen gehalten haben und dies mal mit meiner aktuellen Einstellung vergleiche, so bin ich erheblich mehr als nur Verwundert.
Zu meiner Zeit sagte man noch dass man Interpretersprachen nur für kleine Aufgaben verwenden sollte. Z.B. mal schnell ein paar Verzeichnisse anlegen, ein Auswahlmenü anzeigen oder beim Systemstart ein paar Programme aufrufen.
Genau für solche Dinge haben wir damals Batch-Dateien verwendet. Klar war das keine vollwertige Sprache, aber man wollte ja damit auch keine Programme schreiben... nur Aufrufen.
(Übrigens war Batch mit QBasic das erste was ich auch nur annähernd in Richtung Softwareentwicklung lernte.)
Heutzutage hingegen machen wir alles mit interpretierten Sprachen. Auf dem Webserver erzeugen wir Markup-Code mit PHP oder Python, dieser Code enthällt dann wieder Javascript-Code, der auf Client-Seite ausgeführt wird. Wenn wir ein Programm schreiben das auf unterschiedlichen Systemen laufen soll, programmieren wir in Java. Wenn wir ein kleines Tool brauchen schreiben wir Python.
Ich stelle jetzt nicht die Frage ob nativ compilierte Programme tot sind, ich stelle allerhöchstens eine ähnliche: "Liegen compilierte Sprachen im Sterben?"
Natürlich haben wir weniger Performanceprobleme als zu meinen DOS-Zeiten mit Batch und natürlich sind die Sprachen nichtmal annähernd mit dem Krüppel Batch zu vergleichen. Doch für mich stellt sich immer auch die Frage, ob der Mangel an Performanceproblemen mehr an unseren schnellen Systemen liegt (deren volles Potential wir im Umkehrschluss nicht nutzen) oder ob die Interpreter wirklich um derartige Größenordnungen schneller geworden sein sollen.
just my 2 cents
Importierte/Alte Kommentare:
#719: 07.Oct.2008 10:10 von toranor
Nehmen wir doch mal den 468dx4 wenn der 40megaflops erreicht hat konnte man feiern, und den 10 sek später wohl in die mülltonne werfen. aktuell sitz ich grad an nem laptop, der locker 10 gigaflops bringt. macht fakttor 200. dazu habe ich anstatt 4 mb 4 gb ram, der auch nicht aufm bustakt von 33mhz sondern 666mhz rumdümpelt. so gesehen ist der hauptteil des geschwindigkeitszuwachses wohl der hardware zu verdanken. batch ist afaik nicht schneller geworden. die anderen sprachen evtl. aber das ist nicht das gros.
#720: 07.Oct.2008 11:10 von Dr. Azrael Tod
Mein Problem ist halt dass wir früher Batch nicht verwenden wollten weil es um einen Faktor von >>3 langsamer war als ein nativ ausgeführtes Program
Unsere Rechner sind heutzutage natürlich erheblich schneller geworden, dennoch jammern alle dass die Rechenzeiten immer noch bei vielen Aufgaben viel zu langsam wären.
Können wir es uns wirklich leisten überall zu interpretieren oder Programme immer wieder durch einen Precompiler zu jagen, statt einmalig zu Compilieren?
#721: 07.Oct.2008 03:10 von profmakx
http://shootout.alioth.debian.org/
#722: 07.Oct.2008 08:10 von reaper
Tod? Sterben? Mit nichten, wer auch immer behauptet das Skriptsprachen in Performance kritische Bereiche vordringen könnten ist definitiv auf dem Holzweg. Auf Embedded Hardware z.B. wird niemand auf die Idee kommen PHP zum Einsatz zu bringen. Java hat ja auf vielen Handys schon Einzug gehalten aber auf minimal Hardware geht einfach nix ohne maschinennahe Programmierung.
Für kleines Webgefriemel finde ich Skriptsprachen als akzeptabel, genauso Shellskripte für Convenience Aufgaben. Im Geschäftskritischen Bereich wiederum möchte ich die Syntaxfehler nicht erst sehen wenn der Kunde nicht bestellen kann. Da brauche ich andere Werkzeuge zur Qualitätssicherung und ein Compiler ist da einfach mal der erste Schritt.
Witzig in diesem Kontext ist vielleicht auch die Bude (http://www.numiton.com...) die automatisiert PHP in Java Code wandelt. Mal abgesehen davon der Code echt zum fürchten aussieht, schon ein krasses Projekt.