Na ja, wir reden hier über richtig fette Hausnummern. Wenn die NSA-Spionage 50 Mrd. gekostet hat und die eigene Chipindustrie 100 Mrd. kosten würde (ohne außerplanmäßige Kostensteigerung), dann lohnt es sich schlicht nicht.
Das sind natürlich alles Milchmädchenrechnungen. Kein Mensch weiß, welche Option auf Dauer teurer wäre. Aber eines wissen die Entscheider: Die Kosten für die eigene Chipindustrie wird jeder sehen und verstehen und entsprechend Flak werden sie dafür kriegen, die Schäden aus der Wirtschaftsspionage sind nicht bezifferbar und werden dann unterschlagen werden. Also werden die Entscheider sowas sehr, sehr zögerlich angehen.
Mir scheint eher, die sehen sich als Statthalter des Hegemons oder versprechen sich von einem derartigen Verhalten die größten persönlichen Vorteile.
Zudem kann sich im Moment niemand vorstellen, dass die Amis tatsächlich europäische Infrastrukturen würden lahmlegen wollen. Ich hätte jetzt auch Schwierigkeiten, mir ein derartiges Szenario vorzustellen, dafür müsste eine ganze Menge passieren.
Europa ist freiwillig auf den Stuhl gestiegen, hat sich selbst die Schlinge um den Hals gelegt und ist dabei, sich freiwillig die Hände zu fesseln. Welchen Grund könnten also die USA haben, Europa in seinem Tun zu stören? Die Entwicklung eigener Hardware, eigener Betriebssysteme und Anwendungen dagegen würde die Spionagekosten signifikant in die Höhe treiben ... und das ist sogar schlimmer als der Handel von Erdöl auf Eurobasis.
Man muß auch nicht Intel nachdackeln, wenn man eigene Chips entwickeln
möchte. Vielmehr böte sich an, neue Wege zu beschreiten, z.B. Prozessoren, die funktionale Sprachen weit besser unterstützen als aktuelle Hardware, zusammen
mit entsprechenden Betriebssystemen zu entwickeln. Das ist ein Weg, den der
"Markt" nicht gehen kann, wohl aber ein steuerfinanziertes europäisches Projekt.Hm, nein, Prozessoren an Softwarebedürfnissen auszurichten ist meist voreilig.
Vor allem, wenn das (noch) Nischenbedürfnisse sind.Aber so furchtbar ungeeignet für FPLs sind heutige CPUs eh nicht. Wenn ich mir die spineless tagless machine ansehe, ist das ein ganz normales imperatives Programm, das da läuft, und besondere Unterstützung braucht das Ding nicht.
Was was bringen würde, wäre etwas bessere Unterstützung für die GC - write barriers und so Zeug. Aber das wird auch schon für Dotnet und JVM gebraucht, also muss man da nicht extra was für die FPLs machen.
Wenn man nicht die Frage stellt, wie man existierende CPUs besser geeignet
machen könnte, sondern stattdessen fragt, was eine CPU können sollte, dann
könnten sich weitere Optimierungen z.B. im Bereich Numerikunterstützung und
Speicherverwaltung finden. Sie Dir einfach mal an, wieviel Zeit der Number Dispatch bei einem Lisp/Scheme frißt, auch wenn alle Resultate ganzzahlig sind und in ein Maschinenwort passen. Damit hätte eine spezialisierte Maschine, die Type Tags im Speicher mitführt und fundamentale Datentypen kennt, wohl weit weniger Probleme.
Natürlich bieten die Implementationen meist Möglichkeiten, mit Fixnums zu arbeiten. Das setzt aber eine a-priori-Analyse des Gesamtalgorithmus voraus, während eine Hardwarelösung einfach a posteriori genau dann schnell wäre, wenn alle Resultate Fixnums sind.
OO braucht ironischerweise mehr CPU-Support als FPL - die indirekten Sprünge durch die Dispatch Tables stellen ganz grauenvolle Dinge mit der Sprungvorhersage an, dagegen kann man eigentlich nur mit Inlining angehen, und das ist wiederum grad bei Java mit dem dynamischen Nachladen von Code fast schon unmöglich oder zumindest hochkompliziert.
Eine FPL-Implementierung als Graph Rewriter hat dieses Problem gar nicht, eine, die tatsächlich Funktionen ausführt, kann wenigstens mehr Inlining betreiben.
Das mit OO ist natürlich nur ein Randaspekt, ich erwähn das nur als Beleg, dass es sich wenig lohnt, Hardware auf die Anforderungen einer sehr speziellen Softwaregattung auszurichten - man riskiert damit, Geld in Investitionen zu binden, die am Ende nicht mal für diese spezielle Gattung benötigt werden, jetzt mal davon abgesehen, dass das Geld womöglich besser in grundsätzliche Verbesserungen für alle Softwaregattungen geflossen wäre.
Das Problem liegt meines Erachtens tiefer: Wir dürften uns einig sein, daß eine zunehmende Abstraktion, ob jetzt OO oder FPL oder etwas, an das wir noch gar nicht denken, bei der Programmierung fehlerarmer Software förderlich ist. Entscheidend ist aber heute nicht die Eleganz, mit der man Problemlösungen formulieren kann, sondern wie einfach sich z.B. existierende Bibliotheken bei der Problemlösung nutzen lassen und wie sich anschließend das Kompilat im Vergleich zu konventionelleren Entwicklungen schlägt. Hinzukommt das Problem "Gewohnheit" bei Entwicklern und Entscheidern sowie Kunden. Ich sehe im Aufbau einer staatlich subventionierten nicht kompromittierten Hardwareinfrastruktur die Chance für einen kompletten Neubeginn auf der Basis heutigen Wissens. Die Amerikaner fliegen zum Mars, warum sollten die Europäer nicht eine Expedition in eine theoretisch bessere IT-Zukunft unternehmen?
MfG