Sorry, this entry is only available in Deutsch.
|
You are using an insecure version of your web browser. Please update your browser!
Using an outdated browser makes your computer unsafe. For a safer, faster, more enjoyable user experience, please update your browser today or try a newer browser.
|
Einer der ersten Treffer, wenn ich nach deutsch-sprachigen OCaml-Seiten suche. Der Eintrag scheint etwas älter zu sein … 2006 konnte ich noch fast überhaupt nicht programmieren. OCaml ist gut, und wenn einem OCaml zu wenige Bibliotheken hat, kann man auf F# umsteigen, ohne viel Neues lernen zu müssen.
F# hat gegen OCaml einen Nachteil: es ist nur auf eine Plattform beschränkt…
Stimmt, und Funktoren gibt es auch keine.
)
Dafür hat es Computation-Expressions, d.h. sowas wie Monaden,
und die Mono bzw. .NET -Bibliotheken. (Mono auch auf Linux
Wenn man Mehrkerner nutzen will, hilft einem OCaml nicht viel weiter, F# schon.
Keine Sprache ist perfekt, und es ist gut, wenn man viele kennt.
In der Tat, das ist es. Deswegen schlägt “Der pragmatische Programmierer” auch vor, jedes Jahr eine Neue zu erlernen.
Hehe, das hab ich mal im heise-Podcast gehört, das Buch habe ich nicht gelesen. Die Frage ist, wann eine Sprache gelernt ist. Für Japanisch gibts den JPLT. Aber was gibts für OCaml?
Ja, wann ist etwas wirklich gelernt… Es geht dabei weniger darum Perfektionismus zu erreichen, als mal den Horizont für andere Paradigmen und Lösungen zu öffnen. Ich kannte vor OCaml sowohl OO als auch imperativen Stil. Funktional hatte ich im Zusammenhang mit Haskell schon mal gehört, aber nie angewendet. Wenn man dann mal selbst ein paar Zeilen schreibt und anders denken muss als gewohnt, dann schlägt das durchaus auch auf den Programmierstil in den anderen Sprachen durch. Beispielsweise ist OO keine Spracheigenschaft an sich, sondern man kann auch in C OO programmieren. Das GNOME Projekt setzt das genau so um.
Vielleicht heißt gelernt, dass man das mit einer Programmiersprache machen kann, was man damit machen will. Dann kann aber jeder, der nichts mit dem Computer machen will, alle Programmiersprachen, das stimmt so wohl nicht, weil es zu subjektiv ist.
Ich habe erst dann das Gefühl, dass ich ein Programmier-Paradigma beherrsche, wenn ich für einen (turing-vollst.) Teil einer Sprache dieses Paradigmas selbst einen Interpreter schreiben kann. So gesehen habe ich noch nie Objekt-orientierte Programmierung beherrscht. Das ist zwar ein eher objektives Kriterium, sagt aber noch nichts über die Fähigkeit zur Problemlösung mit dem Paradigma aus.
Einen ML-Interpreter in OCaml zu schreiben, kann aber nicht schaden.
Noch zu OO in C: Meiner Auffassung nach ist eine Programmiersprache das, was sie nahe legt, nicht das, was man damit machen kann. Alle gängigen Programmiersprachen sind schließlich Turing-vollständig. Deshalb würde ich C eher nicht als OO bezeichnen. Aus dem Gnome-Projekt geht auch Vala hervor, vermutlich um OOP in der Sprache zu ermöglichen, anstatt dass man immer von Hand die Klassen nach C kompilieren muss.
Oh Haskell ist auch toll! Tip: FRP, ein Paradigma innerhalb der funktionalen Welt. Ähnliches gibt es auch für OCaml und F#.
Einen ML-Interpreter in OCaml? Steh ich gerade auf dem Schlauch, aber bei OCaml ist ein Interpreter dabei und OCaml ist doch am Ende nur erweitertes ML?
Ich meinte nicht, dass C objektorientiert ist, ich meinte nur, dass man es auch so programmieren kann. Es gibt natürlich keine Klassen, somit keine echte Kapselung oder auch Sichtbarkeitseinschränkungen. Auf diese Dinge muss man dann selbst achten. Man kann sich aber selbst zum OO Denken zwingen und dadurch die gleiche Flexibilität erreichen. So dass ich eben Teile des Codes “untendrunter” tauschen kann, ohne dass ich am ganzen Programm rumändern muss.
Um schnell Spezialitäten bestimmter Sprachen auf einen Blick zu sehen, gibt es unter anderem die 99 bottles of beer Seite.
Wenn es dir um Turing-Vollständigkeit geht, kannst du ja mal Brainfuck programmieren…
Frank veröffentlichte kürzlich..Der höhenverstellbare Fressnapf
OCaml ist eine ML-Sprache, ja. Ich meinte nur, dass zum Verständnis von ML-Sprachen gehört, dass man einmal selber einen Interpreter dafür geschrieben hat. Mit Parser, Kontext-Analyse, Typ-Inferenz, Ausführung und Printer. Dadurch bekommt man eine bessere Intuition für das, was “hinter dem Code” von ML-Sprachen steht.
Brainfuck hat man auch erst dann wirklich verstanden, wenn man einen Brainfuck-Compiler damit geschrieben hat. xD
oder zumindest einen BF-Interpreter in C.