Ist Haskell für produktiven Einsatz geeignet oder eher nur eine Herausforderung für den Programmierer?
-
Wenn du versuchst, mit einem Hammer eine Schraube zu ziehen oder mit einem Schraubenzieher einen Nagel in die Wand zu kriegen, wirst du scheitern oder du schaffst es sehr umständig. Haskell ist auch nur ein Tool, mit dem man Programme schreibst. Wenn du 0180-Anwendungen schreieben willst, dann gänzlig ungeignet (meiner Meinung nach).
Siehe http://www.haskell.org/haskellwiki/Introduction#Why_use_Haskell.3F
http://de.wikipedia.org/wiki/Haskell_(Programmiersprache)
-
supertux schrieb:
Wenn du 0180-Anwendungen schreieben willst
WTF
-
unter "Why use Haskell" steht (sinngemäß), daß man in Experimenten eine 9-25 fach höhere Programmierer-Produktivität gemessen hat, und zwar mit Erlang
-
Die Sprache ist alles andere als einfach, die syntax ist unübersichtlich(er) im Vergleich zu anderen Sprachen .. gerade dabei Haskell zu erlernen, daher kann ich momentan nicht viel über Haskell aussagen
Wenn du noch keine Ahnung hast, dann halte dich mit solchen Aussagen zurueck.
Bitte keine beispiele von kommerzieller software in haskell aufzeigen, so gut wie in jeder saprache wurde schon mal was gecoded, das ist kein kriterium.
Hmm, und wie soll ich dann argumentieren? Was ist denn ein Kriterium?
Wozu diese Komplexität?
Tja, vielleicht kommt ja irgendwann der Aha-Effekt und die Komplexitaet wird einfach verschwinden. Haskell ist programmierte Mathematik.
1000000 mal einfacher zu verstehen sind als tail recursions & folds
Aber die Leute werden sich dabei wohl etwas gedacht haben. Es gibt aber noch wesentlich mehr: http://www.alpheccar.org/www/en/posts/show/67 . Wenn dir das missfaellt, dann bleibe doch bei Python und Co.
(In bezug auf einfachheit, lesbarkeit)
Haskell ist sehr einfach und vor allem lesbar. Wenn ich Spanisch nicht kann, dann ist fuer mich auch alles unverstaendlich, obwohl es vielleicht die lesbarste und einfachste Sprache der Welt ist.
Wenn ich fragen darf, welches Buch oder Tutorial nutzt du denn, um Haskell zu lernen? Noch ein Hinweis: solch oder aehnliche Threads gibt es hier schon, wo Haskell diskutiert wurde.
Z.B. setzt http://www.galois.com/ sehr stark auf Haskell, hat auch einige Preise gewonnen, etc. Unter http://cufp.org/ sind auch einige Vortraege zu finden, z.B. setzt Facebook auf Haskell. Das Spiel Defcon ist auch in Haskell geschrieben (hat auch einige Preise gewonnen). Abseits davon, was mich sehr beeindrukt hat ist http://blog.willdonnelly.net/2009/10/14/brians-purely-functional-brain/ . 49 Zeilen Haskell fuer das gesamte Programm. Soweit zu den 0180-Anwendungen. Auch gibt es alle Lazy Foo's SDL-Tutorials fuer Haskell.
9-25 fach höhere Programmierer-Produktivität gemessen hat, und zwar mit Erlang
Da ging es um funktionale Programmierung im Allgemeinen.
-
Was zur Hölle sin 0180-Anwendungen. Irgendwas im Bereich telefonische Mehrwertdienste?
-
knivil schrieb:
Das Spiel Defcon ist auch in Haskell geschrieben (hat auch einige Preise gewonnen).
Dieses hier?
http://de.wikipedia.org/wiki/DefCon_(Spiel)Grüssli
-
knivil schrieb:
Haskell ist sehr einfach und vor allem lesbar.
na gut, das ist Geschmackssache und hängt von der Vorbildung ab.
Tatsache ist hingegen, daß es in Haskell kompliziert ist, I/O auszuführen und zeitsequentielle Vorgänge nachzubilden. Dieser Aspekt ist in prozeduraler oder objektorientierter Programmierung einfacher.
Viele typische Anwenderprogramme simulieren Teilaspekte der realen Welt, und in der spielen zeitabhängige Zustände nunmal wesentliche Rollen. Prozedurale und objektorientierte Programmiersprachen besitzen einfach verständliche handhabbare Abstraktionen dafür.
und was Einfachheit betrifft:
ich kenne Programmiersprachen mit theoretisch mindestens ebenso wie bei Haskell fundierten, mächtigen und alltagstauglichen Abstraktionen, deren Syntax auf ein halbes Faltblatt paßt.
9-25 fach höhere Programmierer-Produktivität gemessen hat, und zwar mit Erlang
Da ging es um funktionale Programmierung im Allgemeinen.
das ist schon klar. Ich amüsierte mich nur über die Empfehlung, Birnen zu essen, weil Äpfel 3-mal so gut schmecken wie Stachelbeeren.
-
Dravere schrieb:
Dieses hier?
http://de.wikipedia.org/wiki/DefCon_(Spiel)Hier wird glaube drueber gesprochen, kann mich aber an den Inhalt kaum noch erinnern: http://video.google.com/videoplay?docid=9139666903029663537#
ich kenne Programmiersprachen mit theoretisch mindestens ebenso wie bei Haskell fundierten, mächtigen und alltagstauglichen Abstraktionen, deren Syntax auf ein halbes Faltblatt paßt.
Als ob das ein Mass ist, z.B. Brainfuck.
Tatsache ist hingegen, daß es in Haskell kompliziert ist, I/O auszuführen und zeitsequentielle Vorgänge nachzubilden. Dieser Aspekt ist in prozeduraler oder objektorientierter Programmierung einfacher.
Nein, es ist keine Tatsache, nur deine Meinung. Bitte nutze die Forumsuche, es gibt genug Beitraege, in denen das diskutiert wurde (
main = putStrLn "Hello, World!").das ist schon klar. Ich amüsierte mich nur über die Empfehlung, Birnen zu essen, weil Äpfel 3-mal so gut schmecken wie Stachelbeeren.
Weil es ein allgemeines Phaenomen ist und nicht spezifisch fuer Haskell.
-
knivil schrieb:
ich kenne Programmiersprachen mit theoretisch mindestens ebenso wie bei Haskell fundierten, mächtigen und alltagstauglichen Abstraktionen, deren Syntax auf ein halbes Faltblatt paßt.
Als ob das ein Mass ist, z.B. Brainfuck.
Bf hat zwar knappe Syntax, ich rede aber von knapper Syntax mit alltagstauglichen (!) Abstraktionen.
knivil schrieb:
Nein, es ist keine Tatsache, nur deine Meinung.
Nein, es ist nicht nur subjektive Meinung.
wenn ich eine Anwendung programmieren soll, die einen Teilaspekt der realen Welt nachbildet (Bsp Textverarbeitung - Nachbildung von Schreibmaschine, Zettel, Stift usw):
ich schaue mich in der realen Welt um und was sehe ich? Objekte. Lauter Objekte. Alle mit inneren Zuständen - viele davon zeitabhängig - und äußeren Eigenschaften.
wo sehe ich zustandslose Funktionen in der realen Welt? Und wieso sind Funktionen dann eine passendere Abstraktion als Objekte, um reale Welt zu modellieren?
Für viele praktische Anwendungen ist die Modellierung durch Objekte, die mittels Nachrichten untereinander kommunizieren, natürlicher als durch Funktionen. Wir leben nun mal in einer Objektwelt.
Ich bin der letzte, der die theoretischen Vorzüge und das mathematische Fundament der Funk.Prog. in Frage stellen will, und ich bezweifle nicht, daß Seiteneffektfreiheit a la Haskell im Zeitalter der Parallelisierung an Bedeutung zunimmt.
Ich stelle allerdings in Frage, daß die Funktion im mathematischen Sinn grundsätzlich die richtige Abstraktion für die Modellierung von Real-World-Problemen ist.
knivil schrieb:
Weil es ein allgemeines Phaenomen ist und nicht spezifisch fuer Haskell.
wenn dieser riesige Produktivitätsgewinn ein allgemeines Phänomen bei Verwendung funktionaler Sprachen ist, wieso gibt es dann keine solchen Zahlen für Haskell ?
-
Für viele praktische Anwendungen ist die Modellierung durch Objekte, die mittels Nachrichten untereinander kommunizieren, natürlicher als durch Funktionen. Wir leben nun mal in einer Objektwelt.
Function application im Sinne des Lambda-Kalkuels ist aequivalent zu message passing in Carl Hewitt's actor model. In SICP wird gezeigt, wie man Objekte mittels Closures nachbildet.
(Bsp Textverarbeitung - Nachbildung von Schreibmaschine, Zettel, Stift usw)
Emacs ist ein Gegenbeispiel.
Objekte. Lauter Objekte. Alle mit inneren Zuständen - viele davon zeitabhängig - und äußeren Eigenschaften. wo sehe ich zustandslose Funktionen in der realen Welt? Und wieso sind Funktionen dann eine passendere Abstraktion als Objekte, um reale Welt zu modellieren?
Eine Modeerscheinung. Damit hat man sich selbst arg ins Bein geschossen. Wenn es Richtung Parallelisierung geht, hat funprog viele Vorteile. Moeglichst viele Kerne voll auszunutzen, ist die grosse Herausvorderung der nahen Zukunft. Z.B. Datenparallelitaet, siehe google's mapReduce-Framework. Transactional Memory ist fuer Taskparallelitaet gut, in Software schon heute in Haskell verfuegbar. Die imperative Programmierung hat kaum mehr als Locks und condition variables zu bieten.
Ich stelle allerdings in Frage, daß die Funktion im mathematischen Sinn grundsätzlich die richtige Abstraktion für die Modellierung von Real-World-Problemen ist.
Warum nicht? Sicherheit und Korrektheit bei immer groesser werden Sofwareprojekten stehen mehr und mehr im Vordergrund. Qualitaetssicherung und Testen ist schwierig. Da hilft es, wenn man verlaessliche (beweisbare) Aussagen ueber das Programm treffen kann. Das kann ich aber bei
for-Schleifen aber nicht, fuerfoldetc. kann ich das. Weiterhin sind die verfuegbaren Bibliotheken entscheidend. Da gibt es auch massig fuer Haskell. Was ist mit Toolsupport? Quickcheck, HUnit und Threadscope fallen mir spontan ein. Quickcheck wurde auch schon fuer andere Sprachen portiert. Kann aber bestimmt noch nicht mit dem Umfang in OCaml mithalten. Verstehe mich nicht falsch, Haskell ist nicht perfekt, aber ein gutes Stueck besser als (Vorsicht: Subjektivitaet pur) Java.wenn dieser riesige Produktivitätsgewinn ein allgemeines Phänomen bei Verwendung funktionaler Sprachen ist, wieso gibt es dann keine solchen Zahlen für Haskell?
Weil Erlang aelter ist als Haskell. Ich kann dich auch gern auf Beispiele fuer Lisp verweisen. Desweiteren habe ich bereits das Spielzeugbeispiel Brian's Brain verlinkt.
-
1. daß Formalismus A äquivalent oder gleichmächtig mit Formalismus B ist, sagt nicht, daß A und B gleichermaßen geeignet für alle Aufgaben sind. Theoretisch kann ich alles als Turingprogramm formulieren; aber praktische Relevanz -> 0.
2. woher weißt du, daß elisp der optimale Formalismus zur Programmierung eines Editors ist? vielleicht wäre die Programmierung der ~/.emacs in OOP viel natürlicher ?
3. OO ist keine Modeerscheinung, ebensowenig wie die Maxwellschen Gleichungen oder die spezielle Relativität welche sind. Die Entdeckung der OO-Prinzipien ist zweifellos eine der großen geistigen Errungenschaften der Menschheit. Die Entdeckung von LISP und der Funktionalen Programmierung übrigens auch.
PS. Im jetzt anbrechenden Zeitalter der Parallelisierung wird die Bedeutung der OOP zur Modellierung eher zu- als abnehmen - und letztendlich weg von der namespace-orientierten OOP a la Java/C++ und hin zur echten OOP führen:
Objekte als "Computer im Computer", im Idealfall jedes Objekt von einem eigenständigen CPU(-Kern) repräsentiert - der OOP im ursprünglichen Sinne mit late binding und Multiprozessor-Architektur steht eine blühende Zukunft bevor.
-
das "PS" ist meine subjektive Meinung. Der Rest ist aber vergleichsweise objektiv.
-
viel natürlicher
Sprache ist natuerlich. Leider ist literate programming irgendwie untergegeangen. Ich glaube nicht, dass Programme moeglichst "natuerlich" zu beschreiben, der beste Weg ist.
OO ist keine Modeerscheinung, ebensowenig wie die Maxwellschen Gleichungen oder die spezielle Relativität welche sind
Schlechte Vergleiche.
Im jetzt anbrechenden Zeitalter der Parallelisierung .. die Bedeutung zur Modellierung eher zu- als abnehmen
Sorry, es ist schon seit zehn Jahren Mainstream (mindestens). Wir sind schon mitten drin. Viel Spass bei der Modellierung paralleler Programmablaeufe in UML. Kannst du danach ein Tool drauf anwenden, dass dir Deadlocks und Co. anzeigt? Naja, zum Glueck gibt es Petrinetze.
-
Irgendwie erinnert mich "zum beispiel" an Jemanden der früher genaso argumentiert hat.
-
Ich lese gerade zum zweiten Mal "Real World Haskell", habe aber noch keine ernsthafte Programmierung mit Haskell betrieben, nur kleine Spielereien.
Mein Eindruck: Das ist verdammt cool! Es hat in Haskell viele Abstraktionen, die in C++ undenkbar wären. Ich versuche ja auch in C++ möglichst abstrakt zu programmieren, aber Haskell bietet da nochmal deutlich mächtigere Tools. Und die Art, wie in Haskell I/O durchgeführt wird, ist intellektuell durchaus ansprechend (elegant), nachdem ich sie endlich kapiert habe.
Ich kann aber noch nicht sagen, wie gut ich damit echte Programme schreiben kann, da ich es noch (!) nicht versucht habe. Ich habe da aber schon eine Idee, was ich machen könnte.
-
Tyrdal schrieb:
Was zur Hölle sin 0180-Anwendungen. Irgendwas im Bereich telefonische Mehrwertdienste?
Vermutlich meinte der Autor 0815, bzw. korrekter 08/15.
Es handelt sich um eine Redewendung:
http://de.wikipedia.org/wiki/08/15_(Redewendung)08/15 (ausgesprochen „Nullachtfünfzehn“ oder „Nullachtfuffzehn“) ist eine gebräuchliche, abschätzige Redewendung für etwas ganz Gewöhnliches oder nichts Besonderes, Durchschnitt, Mittelmaß oder nichts Erwähnenswertes.
-
Mr. N schrieb:
Ich lese gerade zum zweiten Mal "Real World Haskell", habe aber noch keine ernsthafte Programmierung mit Haskell betrieben, nur kleine Spielereien.
Mein Eindruck: Das ist verdammt cool! Es hat in Haskell viele Abstraktionen, die in C++ undenkbar wären. Ich versuche ja auch in C++ möglichst abstrakt zu programmieren, aber Haskell bietet da nochmal deutlich mächtigere Tools. Und die Art, wie in Haskell I/O durchgeführt wird, ist intellektuell durchaus ansprechend (elegant), nachdem ich sie endlich kapiert habe.
Ich kann aber noch nicht sagen, wie gut ich damit echte Programme schreiben kann, da ich es noch (!) nicht versucht habe. Ich habe da aber schon eine Idee, was ich machen könnte.
Ob haskell besser ist als c++ ist eine sache. Die Haupterfahrung die ich mit C++ Programmen gemacht habe ist, dass sie abstürzen.
Man sollte Haskell eher Sprachen mit modernen Konzepten wie Ruby, Smalltalk oder Dylan entgegensetzten. Man muss zwar zugeben das Smalltalk und Dylan weitgehend tod sind, aber das liegt daran, dass sie zu früh wahren, um sinnvoll mit der Hardware zurechtzukommen. Aber Ruby macht grade (schon länger) die Webentwicklung platt. Und falls Sinatra bekanntheit erlangen sollte sehe ich schon den Tod von Perl und PHP als Webscriptsprache vor mir.
-
Vermutlich meinte der Autor 0815, bzw. korrekter 08/15.
Ich finde 0180-Anwendungen viel cooler, oder gleich 0190 ..
-
IPH schrieb:
Ob haskell besser ist als c++ ist eine sache. Die Haupterfahrung die ich mit C++ Programmen gemacht habe ist, dass sie abstürzen.
Is klar.
Man sollte Haskell eher Sprachen mit modernen Konzepten wie Ruby, Smalltalk oder Dylan entgegensetzten. Man muss zwar zugeben das Smalltalk und Dylan weitgehend tod sind, aber das liegt daran, dass sie zu früh wahren, um sinnvoll mit der Hardware zurechtzukommen. Aber Ruby macht grade (schon länger) die Webentwicklung platt. Und falls Sinatra bekanntheit erlangen sollte sehe ich schon den Tod von Perl und PHP als Webscriptsprache vor mir.
Die von dir genannten Sprachen haben die gemeinsame Eigenschaft, dass sie dynamisch typisiert sind. Und das ist meiner Meinung nach ein großes Manko, da man so darauf verzichtet, Fehler zur Compilezeit zu erkennen, die man erkennen könnte. Selbst C++ ist diesbezüglich diesen Sprachen überlegen. Und Haskell erst recht.
-
knivil schrieb:
OO ist keine Modeerscheinung, ebensowenig wie die Maxwellschen Gleichungen oder die spezielle Relativität welche sind
Schlechte Vergleiche.
gar nicht.
Es gibt OO-Sprachen, die durch konsequentes Ableiten aus einer definierten Anzahl von Prinzipien enstanden sind ("alles ist ein Objekt", "jedes Objekt ist Instanz einer Klasse", ...)
Ganz ähnlich, wie die Gleichungen der speziellen Relativität hergeleitet sind aus den Einstein-Axiomen ("Lichtgeschwindigkeit ist konstant" usw.)
- in beiden Fällen handelt es sich um das Ergebnis der konsequenten Anwendung vorher aufgestellter Prinzipien, und so etwas ist keiner Mode unterworfen, ebensowenig wie die Lösung von X^2 = -1 eine Frage der Mode ist.
