3. Von C++ zu OCaml?

Von C++ zu OCaml?

  • ?

    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
  • K

    SideWinder schrieb:

    Kann Haskell dort ansetzen wo OCaml versagt?

    Keine Ahnung, wo versagt denn OCaml? Die Tools sollen fuer ML-Sprachen besser sein. Auch scheint z.B. mit MetaML dinge moeglich zu sein, die so in keiner Sprache angeboten werden. Aber so genau kenne ich mich damit nicht aus.

    Gibt es in Haskell Namespaces? Sind das quasi die Modules?

    Ja.

    Wie sieht es mit Parallelisierung im Haskell-Bereich aus?

    Sehr gut: http://donsbot.wordpress.com/2009/09/03/parallel-programming-in-haskell-a-reading-list/ .ThreadScope scheint recht brauchbar zu sein. Gab es schon fuer MPI und wurde auch von MS fuer Visual Studio kopiert.

    0
  • ?

    Leute, seid doch mal realistisch. Keine große Firma, benutzt Sprachen wie SML, F# oder OCaml für reale Projekte. Das sind ganz nette experimentelle Sprachen für Unis, aber nix für die reale Welt.

    0
  • S

    Realist22 schrieb:

    Leute, seid doch mal realistisch. Keine große Firma, benutzt Sprachen wie SML, F# oder OCaml für reale Projekte. Das sind ganz nette experimentelle Sprachen für Unis, aber nix für die reale Welt.

    MfG SideWinder

    0
  • ?

    Nö. Wozu auch. Ich kenne den Markt. Schon mal Stellenanzeigen gelesen? Keine Sau sucht OCaml Programmierer. Jede große Software, die ich in den letzten 4 Jahren gesehen habe wurde in C++, Fortran, Java oder .NET geschrieben. OCaml hat keinerlei Relevanz in der Wirtschaft. Allein schon weil es keine guten Tools und Optimierer dafür gibt.

    0
Anmelden zum Antworten