3. Von C++ zu OCaml?

Von C++ zu OCaml?

  • A

    Das F# im VS drin ist, ist mir bekannt. Aber ich wollte eigentlich weiter auf der nativen Schiene fahren. .NET bzw. CLR interessiert mich nicht, da ich gerne auch auf/für exotische Systeme[1] programmiere, wo ich froh bin, das es für diese wenigstens C und C++ gibt. OCaml gibt es auf den exotischen Systemen nicht, aber ein Port von OCaml wäre wahrscheinlicher als F#. 😉

    Wer natürlich auf Sprachebene von F# berichten will, sollte das tun. Da die Plattform beim Sprachteil egal sein sollte. Und zum Üben könnte ich natürlich auch F# unter VS nutzen. Aber den Laufzeitteil, Implementierungsteil und Tools würde mich eher OCaml interessieren.

    Nochmal konkret was mich interessiert: die Sprache an sich und die Entwicklung von nativen Programmen. Und das Ganze auch aus Sicht eines echten/guten C++-Kenners.

    [1] Mit exotisch meine ich wirklich exotisch: RISC OS. 😃

    0
  • R

    Wie bei vielen alternativen Programmiersprachen, ist Emacs sicher sehr beliebt: http://tuareg.forge.ocamlcore.org/

    ansonsten: http://stackoverflow.com/questions/118935/know-of-an-ocaml-ide

    Bashar schrieb:

    __-- schrieb:

    ich würde vorerst von ocaml für den produktiv einsatz abraten da du so gut wie keine entwicker dafür findest

    Jup, die haben alle gutbezahlte Jobs im Wall Street-Umfeld.

    http://video.google.com/videoplay?docid=-2336889538700185341&hl=en#

    0
  • M

    Artchi schrieb:

    Meine Frage an die C++- und OCaml-Kenner: Wäre OCaml sinnvoller für Anwendungsprogrammierung? D.h. wenn man nicht gerade einen GraKa-Treiber oder einen OS-Kernel programmieren will?

    Kommt drauf an, das Problem sind wie immer die Bibliotheken. Mit Bindings, vorallem zu C++ Bibliotheken, zu arbeiten ist nie besonders spassig. Da siehts unter .net mit F# schon besser aus.

    Ansonsten ist OCaml sicher ein tolles Beispiel, wie eine moderne, statisch getypte Multi-Paradigmen Sprache auszusehen hat.

    Aber danach willst du kein C++ mehr programmieren, vorallem nicht mit dem mieserablen Template-System 😃

    0
  • K

    maximAL schrieb:

    Aber danach willst du kein C++ mehr programmieren, vorallem nicht mit dem mieserablen Template-System 😃

    Hey ... wo wir gerade dabei sind ... immer noch besser als Java. 🙂

    0
  • ?

    die syntax von ocaml wird doch wohl keiner als "schön" bezeichnen, oder? aber ihr c++ progger seid ja eh schon schmerz erprobt...

    0
  • T

    __-- schrieb:

    die syntax von ocaml wird doch wohl keiner als "schön" bezeichnen, oder? aber ihr c++ progger seid ja eh schon schmerz erprobt...

    Na, is unser kleiner Cler wieder am stänkern?

    0
  • B

    this->that schrieb:

    __-- schrieb:

    die syntax von ocaml wird doch wohl keiner als "schön" bezeichnen, oder? aber ihr c++ progger seid ja eh schon schmerz erprobt...

    Na, is unser kleiner Cler wieder am stänkern?

    Unwahrscheinlich, die C-Syntax ist doch auch nicht "schön". Aber wer Sprachen nach der oberflächlichen "Schönheit" der Syntax auswählt hat eh einen an der Waffel 🙂
    Was nicht heißt, dass die Schönheit der Syntax völlig unbedeutend ist, aber syntaktische Eigenschaften haben normalerweise Gründe, und diese Gründe haben ihre eigene Schönheit oder auch nicht, und erst danach kommt die Syntax.

    @rüdiger: Danke für den Link. Leider ist das Video ein bisschen lang 😕 -- "tl;dw"?

    0
  • T

    Bashar schrieb:

    "tl;dw"?

    Hehe. Das ist ja ein ganz neues Level an Faulheit. 😃

    0
  • R

    Es geht imho mehr um Ausdrucksstärke als um "Schönheit". "Schönheit" ist ja eher eine individuelle Sache (zB {} vs begin end). Aber kann man dem Code schnell ansehen, was da wirklich passiert? Und wie lange muss ich mich in die Programmiersprache einarbeiten, bis ich das auf Anhieb erkennen kann?

    Bashar schrieb:

    @rüdiger: Danke für den Link. Leider ist das Video ein bisschen lang 😕 -- "tl;dw"?

    Hab's auch nicht ganz gesehen. Im ersten Teil erklärt er, was Proprietary Trading ist und welche Anforderungen daraus für die Software folgen. Danach erklärt er, warum OCaml diese Anforderungen besser erfüllt als andere Sprachen. Interessant fand ich, dass die vorher alle möglichen populären Sprachen eingesetzt haben: VB in Spreadsheets, C++, C#, Java und sich dann für OCaml entschieden haben. Ein wichtiger Faktor für deren Software ist Lesbarkeit. Der Code durchläuft viele Reviews und sogar die Firmeninhaber lesen den Code. Das Risiko beim Proprietary Trading ist nämlich, dass man einen kleinen Fehler macht und bei den Transaktionsmengen dann mal eben das ganze Firmenkapital verzockt. Er nennt ein Beispiel, wo sie versucht haben ein Spreadsheet mit VB in C# neu zu schreiben. Durch die hohe Verbosity von C# und das viele Dispatchen beim OOP sei der Code dann einfach nicht mehr lesbar. Er erzählt auch, dass Boilerplate ein großes Problem sei. Beim Review würde man nämlich den Boilerplatecode einfach überfliegen, obwohl man den natürlich genauso überprüfen müsse. Er spricht auch über Performance. Hardware sei zwar günstig, aber das Verwalten der Hardware sei sehr teuer. Daher wäre es wichtig viel aus der existierenden Hardware zu machen.

    0
  • ?

    Meine größte Sorge ist, dass OCaml langsameren Code als C++ erzeugen könnte.

    0
  • R

    Hab ein bisschen weiter geschaut. Er sagt auch Probleme von OCaml. Unter anderem bemängelt er, dass es keine richtige OCaml GUI-Library gibt. Sondern nur Wrapper für entsprechende C oder C++ Frameworks und das eben kein schönes OCaml wäre. Außerdem gibt es wohl keine direkte Unterstützung von Parallelität.

    hmmmmmmmmmmm schrieb:

    Meine größte Sorge ist, dass OCaml langsameren Code als C++ erzeugen könnte.

    OCaml soll sehr schnellen Code erzeugen. Dazu sagt er auch was.

    0
  • ?

    grad mal ein bischen geblättert...

    CHAPTER 1. INTRODUCTION
/*
* A C function to
* determine the greatest
* common divisor of two
* positive numbers a and b.
* We assume a>b.
*/
int gcd(int a, int b)
{
int r;
while((r = a % b) != 0) {
a = b;
b = r;
}
return b;
}
(*
* An OCaml function to
* determine the greatest
* common divisor of two
* positive numbers a and b.
* We assume a>b.
*)
let rec gcd a b =
let r = a mod b in
if r = 0 then
b
else
gcd b r

    toller vergleich 🙄

    0
  • ?

    soll man dann überhaupt noch weiterlesen wenn einem der erste vergleich schon aufstößt (damit will ich jetzt nicht schon wieder auf die optik eingehen.) eher auf den inhalt des textes den ich gerade mal angelesen hab?

    0
  • A

    Habe mir auch das gesamte Video angeschaut. War sehr informativ.

    Das es keine perfekte Sprache gibt, ist mir bewusst. Deshalb bin ich auch immer mit C++ zufrieden, auch wenn diese Sprache ihre Nachteile hat. Aber mich haben doch ein paar Punkte irritiert:

    1. Parallelisierung wird nicht unterstützt. 😮 Hem, gerade das soll doch eigentlich der große Vorteil von Funktionalen Sprachen sein, oder? Das Concurrency sozusagen build-in ist und ich mich nicht mehr damit herumschlagen muss. Sie lassen zwar ihre Caml-Programme auf mehreren CPUs laufen, aber anscheinend mit zus. Libs?

    2. Programming in Large. Große Projekte sind laut Video nicht wirklich geeignet, unter anderem weil es keine Namespaces gibt. Die Firma macht zwar irgendwie nach Möglichkeit alles mit Caml, aber es gibt in Caml noch viel zu tun.

    3. OOP ist mit OCaml experimentell. "Niemand nutzt OO-Fähigkeit von OCaml!". Kein Wunder das der Video-Titel "Caml Trade" und nicht "OCaml Trade" heißt.

    Die anderen Schwierigkeiten von Caml (wie schlechte UIs, schlechte und wenig externe Libs usw.) konnte ich mir denken, weil die Community sehr klein ist.

    Zum "Optimizing Compiler" meinte der Redner, das der Compiler so heißt, aber nicht optimiert. Der Compiler erzeugt aber sehr guten Code. OK, damit kann man leben. 😉

    Aber der erste Punkt mit der fehlenden Concurrency hat mich schon verwundert.

    So ist es erstmal ernüchternd. Aber mal schauen was die Praxis bringt. Mein OCaml-Buch ist noch nicht da.

    0
  • A

    __-- schrieb:

    grad mal ein bischen geblättert...

    toller vergleich 🙄

    Ich kann zu OCaml absolut nichts sagen. Aber ich weiß nur eines: ohne Formatierung (und Syntax-Coloring) ist jede Sprache schwer zu lesen! Auch das C-Beispiel ist auf den ersten Blick nicht einfach zu lesen.

    Formatiere doch erstmal ordentlich beide Beispiele. Und dann muß man auch die Caml-Syntax kennen. Ich kenne sie nicht, und kann zum aktuellen Zeitpunkt nichts dazu sagen.

    0
  • Z

    __-- schrieb:

    grad mal ein bischen geblättert...

    CHAPTER 1. INTRODUCTION
/*
* A C function to
* determine the greatest
* common divisor of two
* positive numbers a and b.
* We assume a>b.
*/
int gcd(int a, int b)
{
int r;
while((r = a % b) != 0) {
a = b;
b = r;
}
return b;
}
(*
* An OCaml function to
* determine the greatest
* common divisor of two
* positive numbers a and b.
* We assume a>b.
*)
let rec gcd a b =
let r = a mod b in
if r = 0 then
b
else
gcd b r

    toller vergleich 🙄

    Hmm

    let rec gcd a b = 
        if b = 0 then a
        else gcd b (a % b)

    Irgendwie versucht er sein Beispiel 1 zu 1 zu übernehnen ... Buch lieber wegschmeißen 😮

    Btw ist F#, mod gibst dort nicht - also nicht so kompatible wie man sagt.

    0
  • S

    Kann Haskell dort ansetzen wo OCaml versagt? Ich bin auch gerade erst am Aufbau meiner Kenntnisse in funktionaler Programmierung. Gibt es in Haskell Namespaces? Sind das quasi die Modules?

    Wie sieht es mit Parallelisierung im Haskell-Bereich aus? Kennt da jemand gute Seiten?

    MfG SideWinder

    0
  • ?

    Gibt es in Haskell Namespaces?

    Man macht das meines Wissens über qualified imports:

    import qualified Data.Map as Map

    Dann greift man über Map.XYZ auf die entsprechenden Funktionen oder Konstruktoren zu.

    Zur Parallelisierung kann ich dir nichts sagen, da ich selbst noch kompletter Anfänger bin.

    0
  • B

    Artchi schrieb:

    1. Parallelisierung wird nicht unterstützt. 😮 Hem, gerade das soll doch eigentlich der große Vorteil von Funktionalen Sprachen sein, oder? Das Concurrency sozusagen build-in ist und ich mich nicht mehr damit herumschlagen muss. Sie lassen zwar ihre Caml-Programme auf mehreren CPUs laufen, aber anscheinend mit zus. Libs?

    Das stimmt nicht ganz, funktionale Programmierung hat nicht den Hauptzweck, Parallelität zu unterstützen. Es ist eher andersrum: Die Sprachen, bei denen man die besten Erfolge in Sachen Parallelität vorfindet (Standardbeispiel: Erlang), sind funktional und verdanken das auch ihren funktionalen Eigenschaften, also hofft man bei den funktionalen Sprachen den heiligen Gral zu finden. Gerade da in den letzten paar Jahren Multicore-CPUs zur Norm geworden sind. Da wird gerade eine Menge geforscht und Geld für ausgegeben, mal sehen, was daraus wird.
    OCaml hat übrigens auch imperative Elemente, sprich Zuweisungen.

    3. OOP ist mit OCaml experimentell. "Niemand nutzt OO-Fähigkeit von OCaml!". Kein Wunder das der Video-Titel "Caml Trade" und nicht "OCaml Trade" heißt.

    Das ist für mich eine positive Nachricht. Das OO-System von OCaml war für mich immer ein Grund, mich von dieser Sprache abschrecken zu lassen. Aber wenn man das in der Praxis gar nicht benutzt, sieht das anders aus.

    Zum "Optimizing Compiler" meinte der Redner, das der Compiler so heißt, aber nicht optimiert. Der Compiler erzeugt aber sehr guten Code. OK, damit kann man leben. 😉

    Ich glaube, dass er da lügt bzw. eine spezielle Vorstellung von "optimizing compiler" hat. Er vergleicht an der Stelle mit dem SML-Compiler MLTon, der wohl sehr ausgefeilte programmübergreifende Optimierungen durchführt. Sicher wird OCaml die eine oder andere Standardoptimierung durchführen, um die gröbsten Redundanzen loszuwerden.

    So ist es erstmal ernüchternd. Aber mal schauen was die Praxis bringt. Mein OCaml-Buch ist noch nicht da.

    Welches hast du eigentlich bestellt? Vor einiger Zeit ist mal "Practical OCaml" ziemlich verrissen worden.

    0
  • ?

    ALso ist SML schneller als OCaml`?

    0
Anmelden zum Antworten