Sind funktionale Sprachen tot?

andersrum schrieb:

Haben funktionale Sprachen schon mal gelebt?

^this

Funktionale Sprachen waren immer nur eine Randererscheinung. Ein paar sehr schöne Aspekte davon haben ihren Weg in ander Sprachen gefunden und damit wars das. Der Hype ist, zum Glück, am abklingen.

Das Konzept konnte sich in einem halben Jahrhundert nicht flächendeckend durchsetzen und in den letzten Jahren gab es einen letzten Versuch, wegen der zunehmenden Parallelisierung. Der ist gescheitert und das ist gut so.

Mal schauen welche Sau als nächstes durchs Dorf gejagt wird ...

Funktionale Sprachen sind nicht tot, vor allem nicht in den wissenschaftlichen Zeitschriftenartikeln nicht. Wäre nur schön gewesen, wenn die Forscher (z.B.) mal bei Haskell blieben (aus guten Gründen), und nicht schon wieder ausdifferenzieren.
(wie war das damals bei den Lisp-Dialekten?)

Haskell selbst ist, würde ich sagen, sehr linuxlike, und bringt vor allem die schwachen Eigenschaften von Linux mit: Exotenstatus, Spezialistentum, nervige Abhängigkeitsverhältnisse bei Bibliotheken und Schnittstellen, in vielerlei Hinsicht untransparent und unzuverlässig (welche GUI-Bib nehmen wie denn heute? Gui? Was ist das?). Vieles scheint mehr proof of concept-Charakteristisch zu sein als alles andere. Da es aus wissenschaftlichen Häusern kommt, ist Unix/Linux das Basissystem. Aber Linux ist von Haus aus ein C-System, und...
(die Windowsintegration ist so lala, und wenn man weniger als 1 GB frei hat, installiert sich der ghc(i) gar nicht erst - wie wäre es mit einer schlankeren Variante?)
(aber: http://alenribic.com/posts/2012-08-06-running-haskell-on-raspberry-pi.html)
Hinzu kommt, dass die Didaktik von Haskell in der Regel nicht wirklich gut ist.
Das macht den Einstieg und das Umdenken schwer. Und darum erscheinen viele leichte Probleme, dessen Lösung man - imperativ geschult - schnell vor Augen hat, schwierig.
(aber viele hatten die imperative Programmierung in der Muttermilch, so gesehen ist so ein Vergleich auch immer etwas unfair - umgekehrt denke ich, geht hier probieren über studieren und vieles hängt auch von den verfügbaren Bibliotheken ab und der Vertrautheit mit den Möglichkeiten von Haskell (auch die Programmiermöglichkeiten von c++ scheinen mir noch nicht gänzlich erforscht/erschlossen oder eingeübt - erst recht nicht mit neueren funktionalen Errungenschaften/Aussichten)

Undurchsichtig, halbverstanden und fremdartig, fragwürdige Bib, das wirkt nicht wirklich ermunternd. Ist Haskell eigentlich funktional oder eher ideal?

Und: früher gab es richtige Lisp-Maschinen, also Kisten, die hardwareoptimiert für Lisp daherkamen (nix Randerscheinung). Aber Lisp war ja KI, und KI war bald tot (weil zu kurz gegriffen - ich finde auch DATA viel symphatischer als Spock) und so auch die Lisp-Kisten (keine Gelder mehr). WENN jetzt Prozessoren hardwareoptimiert wären für Haskell, was nicht unvernünftig wäre...

Was also/aber tatsächlich passiert, das ist, dass man sich, auf Grund der schlechten Ausgangslage der meisten funktionalen Programmiersprachen, ausgehend von einer vertrauten Basis (z.B. OOP)(was der Bauer nicht kennt...) funktionales Programmieren bzw. Elemente daraus zu eigen macht. Das ist fast schon logisch.

Und was zeigt sich im Haskell-(Unter-Forum?)
Probleme mit den einfachsten Grundlagen (der allerersten Lernminuten) also (div, mod, / \ ) (naja, immerhin)(was sagt uns das?)
Beweise für Praxistauglichkeit von Haskell fragwürdig. (dazu gibt es sogar ein youtubevideo: http://www.youtube.com/watch?v=iSmkqocn0oQ
Vorurteile (das ist ganz ähnlich wie im Assemblerteil).

Der AHA-Effekt, den man hat, wenn man sich mit Haskell mal etwas mehr beschäftigt hat (also einmal Grundlagenkurs gut verstanden und dann noch etwas darüber hinaus, Datentypen und Schnittstellen, ein paar lustige kleine selbstgeschriebene Funktionen und Programme usw.) der ist ganz ähnlich dem, den man hat, wenn man ein Problem hat, das in direkter Hardwareprogrammierung sehr fummelig zu sein scheint. Man freut sich über die nächste (nächstbeste) Hochsprache:

UPPER = UPPER + 1

qweasdycx schrieb:

andersrum schrieb:

Haben funktionale Sprachen schon mal gelebt?

^this

Lisp?

Bashar schrieb:

Das blöde ist halt, dass eigentlich sehr simple Sachen wie die Behandlung von Zustand, insbesondere Array-Operationen, in der funktionalen Programmierung nicht so einfach sind.

Zustand kann man einfach durch Monaden abbilden.

Array-Operationen: Arrays (Maps, STArray) gibt es doch? Es ist aber oft besser umzudenken und Bäume oder Listen zu verwenden. Dadurch wird der Code trivial parallelisierbar.

berniebutt

Was soll diese Diskussion?

Ganze Generationen von Programmierern sind mit funktionalen (prozeduralen) Programmiersprache gross geworden, wie FORTRAN, ALGOL, PL1, PASCAL, K&R-C u.ä. Es wurde das Programm mitsamt allen Daten auf Lochkarten, Magnetbändern, Datein in die Mschine geschoben ohne weitere Interaktivität des Benutzers und Ergebnisse auf Papier oder zur Ansicht am Bildschirm produziert.

Auch wenn die Interaktivität des Benutzers oder paralleler Prozesse heute oft im Vordergrund stehen, bleiben viele Dinge weiterhin funktional und sind damit untot.
Tot sind nur die Compiler, die keine Interaktivität, keine GUI, und keine Einbeziehung anderer Prozesse ermöglichen.

funktionalen (prozeduralen)

fail

Dobi

Eieiei, Bernie.

vossfiel schrieb:

qweasdycx schrieb:

andersrum schrieb:

Haben funktionale Sprachen schon mal gelebt?

^this

Lisp?

Lisp ist genau das Paradebeispiel dafür, dass funtkionale Sprache es in einem halben Jahrhundert nicht geschafft haben, mehr als eine Randerscheinung zu sein.

berniebutt schrieb:

funktionalen (prozeduralen) Programmiersprache

http://fstatic1.mtb-news.de/img/photos/4/1/4/7/7/_/medium/double-facepalm.jpg

gtmikarpebdjkl schrieb:

Zustand kann man einfach durch Monaden abbilden.

einfach? Schön, erklär' doch mal Monaden in eins, zwei Sätzen.