Wie funktional ist C++11?
-
knivil schrieb:
Welche Kriterien erfüllen sie denn nicht?
can be constructed at run-time, was schwierig bei Templates ist.
Ganz Falscher Denkweg. Wenn du Compiletime und Runtime trennst, dann landest du in einer engstirnigen Welt. (Es gibt beim Ausliefern von Code soviele unterschiedliche Stellen wo Sachen passieren koennen. Beim Kompilieren, beim Linken, beim Deployment, vor dem 1. Aufruf, die ganze Zeit im Background,...)
Aber bitte: ich kontere mit einem c++ Interpreter. Templates werden zur Laufzeit erstellt (da wir ja keine Compiletime haben).
-
Irgendwer schrieb:
Man sollte auch nicht vergessen, dass funktionales Programmieren ein Paradigma ist. Ich habe auch schon sehr (schlechten) "objektorientierten" Haskell-Code gesehen.
Dabei ist der Support in Haskell doch al dente. Objektorientiertung ist keine Gegensatz zum funktionalen Paradigma.
-
Shade Of Mine schrieb:
Aber bitte: ich kontere mit einem c++ Interpreter. Templates werden zur Laufzeit erstellt (da wir ja keine Compiletime haben).
Du meinst die Compiletime gehört zu Laufzeit zu. Ohne Compiler will ich sehen wie sich Code zu eine Anwendung transformiert.
-
mächtig und elegant
Darum geht es nicht.
Beim Kompilieren, beim Linken, beim Deployment .. c++ Interpreter
Das sind alles Spracheigenschaften?
es gibt Elemente, die funktional sind
Super Erkenntnis. Gleichzusetzen mit, dass einige natuerliche Zahlen ungerade sind.
-
knivil schrieb:
Irgendwer schrieb:
Natürlich sind C++11 Lambdas funktional
Nein! Sie sind nur anonyme Funktionen. Reine Bequemelichkeit, damit nicht extra eine Funktion oder Klasse deklariert werden muss. Funktionale Sprachen haben meist das Lambda-Kalkuel als Ausgangspunkt. Damit haben lambda-Funktionen in C++ rein gar nichts zu tun.
Wie lahm ist denn das Argument? Der theoretische Hintergrund ist doch völlig egal, es geht um das wie und was im hier und jetzt.
Schon klar, dass du vom ideologischen Standpunkt heraus argumentierst, aber wenigstens etwas Substanz darfst du trotzdem in deine Beiträge packen, sonst machst du dich einfach nur lächerlich.
-
knivil schrieb:
Trotzdem ist ein funktionales Programmieren möglich
Das ist dein einziges Argument, und ein sehr schwaches obendrein, da es auf (fast) jede Sprache zutrifft.
Man kann auch mit fast jeder Sprache funktional programmieren. Genauso wie man mit fast jeder Sprache objektorientiert programmieren kann, auch mit Sprachen wie C oder Haskell, die eigentlich nicht dafür vorgesehen sind.
knivil schrieb:
Und fuer micht spielt es eine Rolle, ob es die Sprache oder eine Bibliothek ist, ob es persoenlicher Programmierstil, Disziplin oder Spracheigenschaft ist.
Dann hast du den Begriff "Paradigma" missverstanden.
knivil schrieb:
Welche Kriterien erfüllen sie denn nicht?
can be constructed at run-time, was schwierig bei Templates ist.
Bei TMP entspricht die Runtime gleich der Compiletime des eigentlichen Programms, und da geht das sehr wohl. Beispiel: Mit folgender Anweisung konstruiere ich zur TMP-Runtime eine Funktion, die ihr Argument um 1 erhöht (mit boost.mpl, weil einfacher):
mpl::plus<mpl::_1, mpl::int_<1>>. Und so rufe ich sie auf:mpl::apply<mpl::plus<mpl::_1, mpl::int_<1>>, mpl::int<2>>.knivil schrieb:
Haskell nicht so elegant objektorientiert wie in C++
Haskell hat nur eine andere Auffassung von "objektorientiert" als C++ oder eben du. Diese Analogie hat nichts mit Funktionaler Programmierung zu tun. Bleib bitte beim Thema.
Du hast den Begriff "Paradigma" missverstanden. Objektorientiert heißt (vereinfacht), es gibt Objekte von Klassen, die untereinander abgeleitet sein können, wobei die Objekte Botschaften austauschen. C++ ist eine Sprache, mit der man dieses Paradigma sehr gut umsetzen kann. Mit Haskell kann man es auch, aber weniger direkt. Es ist Blödsinn, diese Methoden der Umsetzung als "Auffassungen" der jeweiligen Sprachen zur Objektorientiertheit aufzufassen, weil das Paradigma als Konzept unabhängig von irgendwelchen Sprachen ist.
Was hat das ganze mit funktionaler Programmierung zu tun? Funktionale Programmierung ist genauso ein Paradigma, also ein abstraktes Konzept. In diesem Fall etwas vereinfacht: es gibt Funktionen, die einen Rückgabewert haben und beliebig viele Parameter haben können, wobei diese Parameter möglicherweise selbst wieder Funktionen oder Funktionsaufrufe sind. Haskell setzt funktionale Programmierung sehr gut um, C++ weniger gut. Trotzdem kann man in C++ funktional programmieren.
Weil übrigens die Sprachen jeweils verschiedene Paradigmen sehr gut umsetzen, nennt man C++ objektorientiert und Haskell funktional.knivil schrieb:
Das lässt [..] ist aber möglich.
Schwammig! Auf so etwas unkonkretes lasse ich mich nicht ein.
Es ist aber nunmal unkonkret. Man hat funktionale Programmierung nicht an Haskell definiert.
-
Du hast den Begriff "Paradigma" missverstanden.
Und du verstehst nicht, dass du nur Scheinargumente anfuehrst. Jeder muesste diesen inhaltslosen Aussagen zustimmen. Erkenntnisgewinn gleich Null. "Man kann in C++ funktional programmieren" ist deine einziges Argument. Ziemlich inhaltsleer, denn in welcher Sprache kann man das nicht? Funktionale Programmierung ist mehr als "frei von Seiteneffekten".
Objektorientiert heißt (vereinfacht), es gibt Objekte von Klassen
Ich brauche keine Nachhilfe in "objektorientiert". Es gibt sehr viele verschiedene Auffassungen von "objektorientiert". CLOS mit generischen Funktionen, basierend auf Prototypen wie in Javascript, Nachrichten/Methoden wie in C++ oder Smalltalk, Type classes wie in Haskell, ... Vieles kann davon nachgebaut werden, aber darum geht es nicht, genauso wenig wie es um objektorientiert geht.
Objektorientiert .. Was hat das ganze mit funktionaler Programmierung zu tun?
Das erinnert mich immer an sowas wie: Zwiebeln verhalten sich zu Porree wie Krokus zu ... . Als Schlussfolgerung bietest du auch nur wieder "Man kann in C++ funktional programmieren" an.
Es ist aber nunmal unkonkret. Man hat funktionale Programmierung nicht an Haskell definiert.
Ich habe Haskell nur einmal als Beispiel gleichzeitig mit Scheme, Lisp und ML. Was haben diese Sprachen wohl gemeinsam? Das Lambda-Kalkuel. Wo ist es in C++.
Und es ist nicht unkonkret! Also mal Butter bei die Fische:
Grundlage Lambda-Kalkül
Nein.
Funktionen als first class values
Nein.
Funktionen höherer Ordnung
Sehr beschraenkt.
Typsystem
Hindley-Milner Type System? Nein.
Typinferenz
Sehr beschraenkt.
Referentielle Transparenz
Ja, moeglich. Wird aber nicht erzwungen oder kenntlich gemacht.
Diese Liste kann gern erweitert oder kommentiert werden. Da beide Sprachen turingmaechtig sind, kann vieles nachgebaut werden. Aber das ist genauso ein Totschlagargument mit wenig Inhalt.
Oder: Wie wörtlich kann man ein Common Lisp-Programm in C++11 übersetzen?
Hier mein Lieblingsbeispiel inklusive meiner Loesung: http://stackoverflow.com/questions/5058219/generating-list-of-2-lists-in-scheme/5060091#5060091 . Ich bin gespannt.
-
Zeus schrieb:
Du meinst die Compiletime gehört zu Laufzeit zu. Ohne Compiler will ich sehen wie sich Code zu eine Anwendung transformiert.
Indem du zB jittest. Sobald du aktzeptierst dass es Just In Time Compiling gibt, wirst du erkennen dass Code in jedem Stadium transformiert werden kann.
@knivil:
Es sind eben keine Spracheigenschaften. Genau wie Laufzeit/Compiletime keine Spracheigenschaft ist. Jede Sprache kann zu jedem Zeitpunkt Kompiliert werden. Deshalb ist deine Argumentation eben so engstirnig. Weil Laufzeit irrlevant ist. Es wirkt aber nicht so als wuerdest du eine Diskussion fuehren wollen
-
Shade Of Mine schrieb:
Zeus schrieb:
Du meinst die Compiletime gehört zu Laufzeit zu. Ohne Compiler will ich sehen wie sich Code zu eine Anwendung transformiert.
Indem du zB jittest. Sobald du aktzeptierst dass es Just In Time Compiling gibt, wirst du erkennen dass Code in jedem Stadium transformiert werden kann.
Sind wir bisschen blind, noch mal lesen und bitte verstehen!
-
Jede Sprache kann zu jedem Zeitpunkt Kompiliert werden. Deshalb ist deine Argumentation eben so engstirnig.
Da gebe ich dir recht, aber ich wuerde gern Kompilieren,Linken, Deployment, c++ Interpreter, Jit herauslassen. Dann muss man ueber alles reden. Ueber alles kann man aber nicht reden, also muss man schweigen. Deswegen kann ich auch nicht auf diese Punkte eingehen.
-
knivil schrieb:
Objektorientiert heißt (vereinfacht), es gibt Objekte von Klassen
Bullshit! In C++ vielleicht. Es gibt sehr viele verschiedene Auffassungen von "objektorientiert". CLOS mit generischen Funktionen, basierend auf Prototypen wie in Javascript, Nachrichten/Methoden wie in C++ oder Smalltalk, Type classes wie in Haskell, ... aber das ist nicht Thema.
Genau das ist dein Problem! Das sind alles keine Auffassungen, sondern Umsetzungen. Der Begriff "Klasse" hat auch erstmal wenig mit dem Schlüssenwort "class" in C++ zu tun. class in C++ bietet eine einfache Möglichkeit, eine "Klasse" aus der objektorientierten Programmierung abzubilden. In C kann ich auch Klassen abbilden, aber etwas umständlicher über Strukturen und Funktionspointer. In Haskell kann ich Typklassen erstellen und damit etwas umsetzen, was dem Klassen- und Vererbungskonzept aus der OOP sehr nahe kommt.
Entsprechend weiter wird der Begriff "Objekt" in C++, C und Haskell mit Variablen abgedeckt. Das hat aber alles nichts mit Auffassungen zu OOP zu tun, sondern nur mit Umsetzungen.Ebenso gibt es diese Begriffe in der funktionalen Programmierung. Z.B. den Begriff "Funktion". Die C++-Funktionen eignen sich dafür nur bedingt, weil sie keine FCCs sind. Funktoren und Lambdas eignen sich aber. Ich muss also Kompromisse bei der Umsetzung eingehen (genauso wie ich nicht kompromisslos OOP in C umsetzen kann), aber ich kann es umsetzen.
Ich zitiere nochmal aus dem Wikipedia-Artikel zu "Programmierparadigma": "Ein Programmierparadigma ist ein fundamentaler Programmierstil". Also ein Stil. Es geht nicht darum, ob die Sprache auf die Turingmaschiene oder das Lambda-Kalkül zurück ging, oder ob sie das "class"-Schlüsselwort besitzt oder nicht beseitzt, es geht nur darum, wie man einen bestimmten Stil in einer bestimmten Sprache umsetzen kann. Und das geht in vielen Sprachen mehr oder weniger gut. Es tut mir sehr leid, wenn dir das zu weit gefasst ist, aber so ist nunmal die Definition. Wäre die Frage "ist C++ eine funktionale Programmiersprache", wäre die Antwort ganz klar nein.
knivil schrieb:
Also mal Butter bei die Fische:
Grundlage Lambda-Kalkül
Nein.
Egal.
knivil schrieb:
Funktionen als first class values
Nein.
Doch durch Funktoren und Lambdas.
knivil schrieb:
Funktionen höherer Ordnung
Sehr beschraenkt.
Doch mit Funktoren und Lamdas.
knivil schrieb:
Typsystem
Hindley-Milner Type System? Nein.
Ich wüsste ja nicht, dass ein Typsystem Voraussetzung wäre (z.B. LISP oder das Lambda-Kalkül haben beide keins), aber C++ hat ein Typsystem. Das es nicht so strikt wie Haskell ist, spielt keine Rolle.
knivil schrieb:
Typinferenz
Sehr beschraenkt.
Auch hier wüsste ich nicht, das das Voraussetzung ist
knivil schrieb:
Referentielle Transparenz
Ja, moeglich. Wird aber nicht erzwungen oder kenntlich gemacht.
Natürlich wird es nicht erzwungen, C++ ist eine Mehrparadigmensprache. Aber wie schon erwähnt ist funktionale Programmierung ein Stil, dem ich entweder folgen kann oder auch nicht.
-
@ipsec
Es gibt zwei unterschiedliche konzeptuelle Modelle zur Objektorientierung. Klassenbasiert und Protypebasierend.Verstandnisfrage!
Mit Hindley-Milner ist Typinferenz gemeint?
-
Es heißt übrigens der Lambda-Kalkül.
Und noch was: Lisp basiert nicht wirklich auf dem Lambda-Kalkül, der gute John McCarthy hatte das damals nicht so richtig verstanden, als er seine anonymen Funktionen LAMBDA nannte. Im Lambda-Kalkül haben Variablen lexikalische Bindung, das war im Ur-LISP nicht so.
-
a) Scheme und Common Lisp haben lexical scoping. Ich sehe kein Problem. Aber schauen wir uns das Original an: http://www-formal.stanford.edu/jmc/recursive.html .
we need a distinction between functions and forms and a notation for expressing this distinction. This distinction and a notation for describing it, from which we deviate trivially, is given by Church [3]
3. A. CHURCH, The Calculi of Lambda-Conversion (Princeton University Press, Princeton, N. J., 1941).
D.h. auch wenn das Ur-Lisp nicht lexical scoping umgesetzt hat, ist es doch stark im Lambda-Kalkuel verwurzelt.
b) Ich bevorzuge Wikipedia-Artikel auf Englisch, da vieles in den deutschen Seiten "anfechtbar" ist:
functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data
Waehrend ich Programmzustand in C++ durchaus verstecken kann, so ist es in C++ nicht moeglich (oder nur in trivialen Faellen), Berechnungen nicht als Evaluation von mathematischen Funktionen behandeln. Denn genau das macht das Lambda-Kalkuel. Es ist deshalb nicht egal. Selbst in der deutschen Version stosse ich auf:
Die funktionale Programmierung entspringt der akademischen Forschung. In den 1930er Jahren arbeiteten verschiedene Personen am Lambda-Kalkül. Hierbei geht es um Funktionen und deren Auswertung.
c)
Doch durch Funktoren und Lambdas.
Ja, Closures koennen mit Objekten nachgebaut werden, indem der Klammeroperator ueberladen wird. Aber: "Objects are a poor man's closures".
d) Zum Artikel von Kalkuel: Ich bevorzuge das. http://www.duden.de/rechtschreibung/Kalkuel_Taktik_Strategie .
-
knivil schrieb:
b) Ich bevorzuge Wikipedia-Artikel auf Englisch, da vieles in den deutschen Seiten "anfechtbar" ist:
functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data
Waehrend ich Programmzustand in C++ durchaus verstecken kann, so ist es in C++ nicht moeglich (oder nur in trivialen Faellen), Berechnungen nicht als Evaluation von mathematischen Funktionen behandeln. Denn genau das macht das Lambda-Kalkuel. Es ist deshalb nicht egal.
Ich bestreite nicht, dass funktionale Programmierung und allgemein funktionale Programmierpsrachen auf das Lambda-Kalkül zurückgehen. Du musst aber mal den Artikel zu Programmierparadigma lesen, diesmal auf Englisch: "A programming paradigm is a fundamental style of computer programming". Da haben wir wieder den Stil. Und diesen kann ich in C++ nachbauen. Ich muss mehr Arbeit leisten (nötiger Unterbau, der bei funktionalen Sprachen schon im Compiler steckt), ich muss teilweise Kompromisse eingehen ("Objects are a poor man's closures" ist schon richtig), der Compiler optimiert nicht in der Form, wie er es bei einer funktionalen Sprache machen würde, aber ich kann den funktionalen Stil umsetzen.
Die Antwort "gar nicht" auf die Frage "Wie funktional ist C++" ist also so pauschal falsch.
-
knivil schrieb:
D.h. auch wenn das Ur-Lisp nicht lexical scoping umgesetzt hat, ist es doch stark im Lambda-Kalkuel verwurzelt.
Es basiert nur oberflächlich darauf. Er hat sich inspirieren lassen, es aber nicht richtig umgesetzt.
d) Zum Artikel von Kalkuel: Ich bevorzuge das. http://www.duden.de/rechtschreibung/Kalkuel_Taktik_Strategie .
Es gibt da nichts zu bevorzugen, das eine Wort ist sächlich ("ins Kalkül ziehen"), das andere männlich ("der Lambda-Kalkül"). So ähnlich wie bei der/das Modul. Oder sogar der/das Teil, der/das Schild.
-
http://de.wikipedia.org/wiki/Kalkül
Das Wort Kalkül im logischen und mathematischen Sinn ist ein Maskulinum (der Kalkül). Kalkül im umgangssprachlichen Sinn wird auch als Neutrum verwendet (das Kalkül, deshalb auch „ins Kalkül ziehen“) und wird in der Bedeutung von „Berechnung“ oder „Überlegung“ verwandt.[1]
-
ipsec schrieb:
Die Antwort "gar nicht" auf die Frage "Wie funktional ist C++" ist also so pauschal falsch.
Also ist ein Still eine Spracheigenschaft?
-
Zeus schrieb:
ipsec schrieb:
Die Antwort "gar nicht" auf die Frage "Wie funktional ist C++" ist also so pauschal falsch.
Also ist ein Still eine Spracheigenschaft?
Nein, Eigenschaft des Programmierers.
Und die Sprachen helfen dem Programmierer beim Umsetzen seines Stils/Paradigmas mal mehr und mal weniger gut.
Man bedenke den Beruehmten Satz:
Ein echter Programmierer kann in jeder Sprache FORTRAN schreiben.
-
Shade Of Mine schrieb:
Zeus schrieb:
ipsec schrieb:
Die Antwort "gar nicht" auf die Frage "Wie funktional ist C++" ist also so pauschal falsch.
Also ist ein Still eine Spracheigenschaft?
Nein, Eigenschaft des Programmierers.
Um so erstaunlicher ist es, dass er sich selbst wiederspricht.