von-Neumann-Maschinen und Lambdas

Question

Brians Prämisse in seiner Argumentation auf die Frage "Are side effects a good thing?" ist interessant:

Computer sind von-Neumann-Maschinen, die ausgelegt sind, mit Effekten gut zu funktionieren (und nicht ausgebildet sind, gut mit lambdas)

Ich bin verwirrt durch die Nebeneinanderstellung der Ansätze. Ich kann sie nicht als schwarz und weiß sehen. Was ist der Beweis-Wert:

Computer sind von-Neumann-Maschinen, die mit gut arbeiten Effekten entworfen werden [1]

Der letzte Teil verwirrt mich:

eher als entworfen werden, um gut mit lambdas zu arbeiten [2]

Werden die Lambdas als Symbole für die Funktionale Programmierung verwendet? Oder sind sie Euphänismen für funktionales Programmieren? Was ist die wahre Botschaft?

Inwiefern sind die Teile der Prämisse [1] und [2] richtig? Was sind die versteckten Prämissen in der Antwort? Kann jemand die ursprüngliche Prämisse rechtfertigen? Wie funktionieren die von-Neumann Maschinen und Lambdas wirklich?

Answer 1

Ich bin nicht ganz sicher, was Sie fragen, aber wie ich es lese, fragen Sie, was er mit Lambdas meint?

Er bezieht sich auf lambda calculus, die viel von der theoretischen Basis für die funktionale Programmierung bilden. Es ist eine abstrakte Notation für (unter anderem) Beschreibung und Argumentation über Funktionen höherer Ordnung.

Eine Von Neumann Maschine ist im Grunde, was wir haben. Programme werden durch Anweisungen ausgeführt, die einen Speicher (unser RAM) manipulieren und darauf zugreifen. Das heißt, alles wird implizit durch Nebenwirkungen ausgeführt. Daten werden aus einem Bereich im RAM gelesen, ein Bit verarbeitet und in einen (anderen, vielleicht) Bereich im RAM zurückgeschrieben. Ohne Nebenwirkungen, die CPU würde sich darauf beschränken, zu manipulieren, was auch immer in den Registern war, wenn es eingeschaltet wurde.

Lambda-Kalkül hat keine Ahnung von Nebenwirkungen, also würde eine Maschine, die auf diesem Prinzip basiert, nicht zwischen "was die CPU zugreifen kann" (unsere Register im Wesentlichen) und "was indirekt zugänglich ist" unterscheiden RAM). Alles in einer solchen Maschine würde auf funktionalen Prinzipien basieren, auf Funktionen, die ein oder mehrere Argumente nehmen und einen neuen Wert zurückgeben, niemals bestehende ändern. (Und nein, ich bin nicht sicher, wie das in Hardware funktionieren würde ... :))

Beantwortet das Ihre Frage?

Answer 2

Hier ist mehr Tiefe von was I gemeint ist, obwohl es interessant sein wird zu sehen, ob andere zustimmen oder was sie zu sagen haben.

Überlegen Sie, wie Computer heute arbeiten. Sie verfügen über Hardware mit Integer- und Gleitkommaregistern sowie eine große Auswahl an Arbeitsspeicher und Anweisungen, die meist die Form 'basierend auf dem Lesen des Wertes dieses Registers/Speicherzelle haben, diesen neuen Wert in dieses Register eingeben /Zelle'. (Das Aktualisieren von Speicherzellen hat alle Arten von Auswirkungen, wenn es um Cache-Zeilen, Kohärenz- und Speichermodelle und so weiter geht.) Ganzzahlen sind 32 oder 64 Bits, und fast alle Programmiersprachen tauchen diese Datentypen auf, die genau zur Hardware passen. Nahezu jede Laufzeit arbeitet mit einem kleinen Aufruf-Stack, bei dem Objekte mit Stack-Zuweisung billig sind, und einem teureren "Heap", bei dem andere Objekte erstellt und zerstört werden können, wenn nicht-Stack-basierte Lebensdauern benötigt werden.

Betrachten Sie jetzt die meisten modernen funktionalen Programmiersprachen. Unveränderlichkeit ist die Norm; Sie werden die Erinnerung nur selten mit neuen Werten "durchbohren". (Dies bedeutet, dass Sie mehr neue Objekte erstellen, was bedeutet, dass Sie mehr zuweisen.) Lambdas und Fortsetzungen sind die Norm; Sie haben seltener Objektlebensdauern, die dem Stapel entsprechen. (In der Tat verwenden einige FP-Laufzeiten keinen Stack; in einer CPS-Implementierung sind Stapel- und Programmzähler nicht am richtigen Platz.) Rekursion ist ein Schleifenkonstrukt, so dass Sie mindestens "Tail" -Aufrufe benötigen, um nicht zu konsumieren der Stapel sowieso. Praktisch muss alles "haufen" zuweisen, und natürlich brauchen Sie einen Müllsammler. Algebraische Datentypen liefern markierte Daten; Theoretisch würden diese Tags nur zusätzliche 2 oder 3 Datenbits benötigen, aber um die Laufzeit anzupassen, benötigen sie oft ein zusätzliches Speicherwort oder mehr. ... Ich bin Art von mäandernden, aber die Dinge, die Sie tun am häufigsten in einer FP Sprache neigen dazu, die Dinge genau zu entsprechen, dass Skala schlimmste oder sind teuerste auf der typischen Computer-Hardware-Architektur und grundlegenden Sprechen Laufzeit.

Es muss nicht so sein. Man kann sich eine Welt vorstellen, in der die Laufzeit einen Stack vermeidet und Heap/Allokation schnell macht (und keinen Engpass für Multithread-Anwendungen). Man kann sich eine Welt vorstellen, in der die interoperablen ganzzahligen Typen 29 oder 60 Bits haben und die Laufzeit/Hardware die zusätzlichen übrig gebliebenen Bits des Wortes z. die GC oder algebraische Tags oder was auch immer. (Ich denke, einige FP-Implementierungen/Laufzeiten machen einige dieser Tricks.) Etc. etc ... Der Punkt ist, wenn man eine moderne funktionale Sprache als gegeben ansieht und dann Runtime/Hardware um sie herum entwirft, würde sie ganz anders aussehen von den typischen Hardware/Laufzeiten von heute.

(Ich glaube nicht, mitgeteilt, dass ich terrifically, und ich bin ungenau über viele Details, weiß ich nicht genau, aber hoffentlich grok Sie den Kern meiner Arbeit hier.)