Hi!
Zunächst einmal stecke ich in einer anderen Situation als Du. Für mich ich das hier alles Hobby. Ich verdiene mein Geld nicht mit Datenauswertung oder Statistik. Es ist ein nettes Plus für meinen Arbeitgeber, aber wenn ich R nicht kennen würde und keinen t-Test rechnen könnte, hätte ich am Ende des Monats das gleiche Geld und auch meinen Karriereverlauf wird es nicht beeinflussen. Vielleicht ändert das meinen Blick auf die Dinge.
Das sind doch eher theoretische Programmierkonzepte als praktische Programmiersprachen, oder nicht?
Das kann man sehen, wie man will. Probieren wir es auf einem datenanalytischen Weg zu beantworten: Der folgende Link führt zum aktuellen Redmonk-Ranking der Programmiersprachen:
http://sogrady-media.redmonk.com/sograd ... 17.wm_.png
Auf der x-Achse ist die GitHub-Aktivität je Sprache dargestellt. R ist auf dieser Achse gleichauf mit Clojure und Clojure ist LISP für die JVM. Damit steht LISP deutlich vor Klassikern wie Visual Basic oder Matlab oder Assembler, denen keiner absprechen wird, dass sie praktische Programmiersprachen sind. Außerdem ist LISP in diesem Diagramm auch noch unter den Namen EmacsLisp, Common Lisp, Racket und Scheme versteckt. Wenn man alle diese Dialekte derselben Sprache zusammen gezählt hätte, hätte LISP wohl einen Platz deutlich rechts von R erhalten.
Haskell ist ebenfall auf der x-Achse gleichauf mit R. Ich würde also argumentieren, dass es praktische Programmiersprachen sind, weil Leute sie praktisch (auf GitHub) benutzen. (Auch:
https://clojure.org/community/success_stories )
Die Frage hier war aber ja nicht, ob die Sprachen praktisch genutzt werden, sondern wie man von anderen Sprachen und von welchen anderen Sprachen man für R lernt.
Ich habe mal von folgendem Muster gelesen: Ein Informatiker hat eine interessante Idee für ein neues Konzept in der Programmiersprache und erfindet dann eine Programmiersprache, die das konsequent umsetzt. Diese verlässt nie die akademischen Grenzen. Später greift dann eine andere Sprache dieses Konzept auf, die damit groß und berühmt wird. Objektorientierung ist mit SmallTalk etabliert worden, den ganz großen Durchbruch hatte sie mit Java.
Ich habe erstmals in Python verzückt gesehen, dass man eine Funktion als Argument einer anderen Funktion übergeben kann. Oder in einem Vektor mehrere Funktionen ablegen kann, um dann mit einer Schleife darüber zu laufen. In R kann man das auch. Die Idee dahinter ist aber viel älter: Sie war in LISP schon etabliert. Überhaupt, wenn Du mal in
der R Sprachdefinition die Suchfunktion nach "LISP" suchen lässt, siehst Du, wie das R Core Team sich auf die Abstammung Rs von LISP beruft.
Ich finde es einfach toll, wie Python ohne geschweifte Klammern und BEGIN-/END-Anweisungen, einfach durch Einrückung Codeblöcke markiert. Es spart das Tippen und damit Tippfehler, den visuellen Ablenker und zwingt zu leserlichem Einrücken. Die Idee ist nicht originell, sondern aus
Haskell übernommen. Wäre eine schöne Idee, R besser zu machen.
Will sagen, es gibt viele Konzepte, die man in "akademischen" Sprachen am besten findet, und die dann in Mainstreamsprachen überführt werden. Wie Du oben geschrieben hast: Wenn man von einer Sprache mit einem anderen Ansatz zurück zu R kommt, dann nutzt man R anders.
Stellt sich die Frage, ob man das nicht alles in einer Multiparadigmenssprache lernen kann. Irgendwie ja, irgendwie nein.
kann in einer prozeduralen Programmiersprache (C) heißen: Ersetze den Inhalt von i mit dem Ergebnis von i+1.
kann in einer objektorientieren Sprache heißen: Schicke dem Objekt i eine Nachricht, dass es seinen Wert um 1 erhöhen soll.
kann in einer objektorientierten Sprache heißen: Rufe die get-Methode von i auf, addiere den Wert 1 und übergib das an die set-Methode von i.
kann in einer funktionalen Sprache heißen: Der Wert von i ist der Rückgabewert der Plusfunktion, wenn man sie mit i und 1 aufruft.
In Python wird einem das aber nicht unbedingt bewusst, weil man halt nie
und auch nie
schreibt. Und weil man es nie anders schreibt, macht man sich vielleicht auch keine Gedanken drum.
Wie kompliziert kann es in höheren Sprachen sein, den Unterschied zwischen Call-by-Value und Call-by-Reference zu erklären. Wie einfach ist es hingegen in C zu erklären, dass man halt entweder den Wert auf den Stack schmeißt oder den Pointer auf die Speicherzelle mit dem Wert... In C ist es einfach zu kapieren und wer es in C kapiert hat, hat auch in keiner höheren Sprache mehr Probleme damit.
Wie undurchsichtig sind die Typumwandlungen in R?
Code: Alles auswählen
> dataframe <- data.frame(1:5, 1:5)
str(dataframe[1,])
str(dataframe[,1])
Na, welches davon gibt jetzt einen Dataframe und welches einen Vektor zurück? Wie herrlich dagegen das Typendeklarationssystem in Haskell, in dem man vor dem Deklarieren der Funktion definiert, welche Werte sie nimmt und welche sie zurück gibt. Wer diese Klarheit in Haskell gelernt hat, der schreibt nicht mehr solche dämlichen Funktionen wie '['. Oder er ist selbst Schuld.
Das war jetzt ziemlich viel Text zu Schritt 5, aber Schritt 5 ist wichtig und richtig!
Viele Grüße,
Bernhard