Bei dem Teufelszeug im Zusammenhang mit Funktionen geht es um globale Zuweisungen.
Die Unfähigkeit der apply-Funktionen zur Rekursion ist ein anderes Thema.
Gruß, Jörg
Bei dem Teufelszeug im Zusammenhang mit Funktionen geht es um globale Zuweisungen.
Das ist eine valide Schätzung, aber mit Blick auf die Messungenauigkeit die aus Deiner Reaktionsgeschwindigkeit und der Ansprechungenauigkeit eines Touchscreens folgt, eine mit erheblicher Unsicherheit versehene. Einigen wir uns: Wenn Du das hundert Mal hintereinander machen müsstest, könntest Du in der Zeit einen Kaffee holen gehen, würdest ihn aber nicht mehr austrinken.
Code: Alles auswählen
i <- 1
while(i<10){
print("Hallo")
i <- i + 1
}
Code: Alles auswählen
a <- replicate(10, print("Hallo"))
Code: Alles auswählen
"Hallo".printTimes(10)
Wäre das denn nicht so wenn du prozedural programmieren würdest? Warum ist das parallelisieren billiger (und Zeit sparender) wenn du funktional programmierst?Dadurch, dass ich viel funktional schreibe, kann ich auch fast immer ziemlich billig parallelisieren und so Zeit sparen.
Gibt es auch Nachteile daraus? Also das R eben neben dem ursprünglich prozeduralen und begrenzt funktionalen auch das objektorientierte Paradigma aufgedrückt wurde?Dabei entstehen Mischsprachen, die einen Mischmasch aus allem umfassen. R ist ein gutes Beispiel, wo man einer ursprünglich prozedural und begrenzt auch funktionalen Sprache später drei verschiedene Objektsysteme aufgepresst hat und alles irgendwie durcheinander verwendet.
Das wird aus meinem Beispiel nicht so deutlich, aber einige Grundgedanken der funktionalen Programmierung, z. B. dass Funktionen sich wie mathematische Funktionen verhalten sollten (verwerten die Argumente, geben vorhersagbare Werte vorhersagbaren Typs zurück und haben keine "Nebenwirkungen") passen sehr gut zum Parallelisieren. Weil EDi sie von vorneherein beachtet, muss er seinen Code nicht groß umschreiben, wenn er ihn statt auf einem Kern seiner CPU auf 20 Kernen bei Amazon laufen lassen will. Nicht umschreiben müssen == billiger.Bill hat geschrieben: ↑So Apr 26, 2020 9:36 pmWäre das denn nicht so wenn du prozedural programmieren würdest? Warum ist das parallelisieren billiger (und Zeit sparender) wenn du funktional programmierst?Dadurch, dass ich viel funktional schreibe, kann ich auch fast immer ziemlich billig parallelisieren und so Zeit sparen.
Schwer zu sagen. Wenn Du über die Vorteile echt objektorientierter Programmierung liest, dann geht es eben um die Vorteile beim Erstellen großer Programme. Aber wer macht sowas in R? Die meisten von uns wollen doch nur ihre Daten auswerten und dafür braucht man eigentlich nie viele tausende Zeilen Code. Insofern finde ich es schwierig bis uninteressant, R nach solchen Kriterien zu beurteilen. Encapsulation und Inheritance sind heilige Grale der Objektorientierung. Ich müsste nachlesen um Dir zu sagen, ob es sowas im S3-Objektsystem überhaupt gibt. In echt objektorientierten Sprachen ist es halt echt wichtig, welche Methoden Dein Objekt von welcher Eltern-Großeltern-Urgroßeltern-Klasse geerbt hat.Bernhard du meintest:Gibt es auch Nachteile daraus? Also das R eben neben dem ursprünglich prozeduralen und begrenzt funktionalen auch das objektorientierte Paradigma aufgedrückt wurde?Dabei entstehen Mischsprachen, die einen Mischmasch aus allem umfassen. R ist ein gutes Beispiel, wo man einer ursprünglich prozedural und begrenzt auch funktionalen Sprache später drei verschiedene Objektsysteme aufgepresst hat und alles irgendwie durcheinander verwendet.
Das war wohl unzureichend beschrieben: Nein, in R kann man so nicht programmieren. In R ist das keine gültige Syntax. "Normale" Objektorientierung kann so aussehen. In R sieht ein Methodenaufruf so aus wie ein Funktionsaufruf und ohne nachzulesen weiß ich ehrlich gesagt nicht mal, ob es einen großen Unterschied gibt. In Java könnte man die Zahl 1 ausgeben mitIch finde deine Beispiele sehr interessant. Das Beispiel zur Deutlichmachung der objektorientierten Variante finde ich recht ungewöhnlich.
Programmieren (einige) Leute in R echt so?
Code: Alles auswählen
java.lang.System.out.println(1)