3 ms·

Steve Yegge, who you're quoting as being in favor of OCaml, has since implied that he found it lacking on closer inspection, but, uncharacteristically, without

by mdemare 19y ago

Steve Yegge, who you're quoting as being in favor of OCaml, has since implied that he found it lacking on closer inspection, but, uncharacteristically, without writing at length about it.

yters 19y ago
At the top of his follow on article he says it isn't good for server applications, but he'd use it for client side.
- mdemare 19y ago
  Yeah, here's the quote: "(Note, long after I wrote this entry: I think OCaml has some fairly fundamental problems that keep it from being a first choice for server-side development. If I were to use it for anything, it would be as a substitute for C++ in delivering client-side executable/GUI programs, e.g. for Windows systems. And I still think it's a really cool language.)" Anyone know what he's referring to?
  - mfp 19y ago
    Maybe the lack of parallelism in OCaml's threads at the time he wrote that? There are now at least two solutions to obtain speedups on multi-core and multi-processor machines plus scalability by allowing seamless distributed processing: the JoCaml extension, which integrates the join calculus (http://jocaml.inria.fr/ http://jocaml.inria.fr/), and coThreads (http://cothreads.sourceforge.net/ http://cothreads.sourceforge.net/), which comprises shared-memory (with extensions like STM) and message passing while keeping backwards-compatibility with the original Threads library.
  - rkts 19y ago
    He's criticized the lack of a generic print function, calling it "a face-smashing insult to usability." http://steve.yegge.googlepages.com/when-polymorphism-fails http://steve.yegge.googlepages.com/when-polymorphism-fails Note that like many of the alleged deficiencies of OCaml, this was a compromise for performance.
    - mfp 19y ago
      Good find. I don't see how this keeps OCaml "from being a first choice for server-side development" while making it an acceptable language for client-side development, though. There are a several hackish polymorphic print implementations, but the best solution so far seems to be the "deriving" camlp4 extension (http://code.google.com/p/deriving/wiki/Introduction http://code.google.com/p/deriving/wiki/Introduction). This looks pretty good: type 'a tree = Leaf of 'a | Branch of 'a tree * 'a * 'a tree deriving (Show) type point = { x : float; y : float } deriving (Show) let points = Branch (Leaf {x=0.0; y=0.0;}, {x=2.0; y=2.0}, Branch (Leaf {x=1.0; y=1.0}, {x=1.0; y=0.0}, Leaf {x=0.0; y=1.0})) Show.show<point tree> points => "Branch (Leaf {x =0.; y =0.}, {x =2.; y =2.}, Branch (Leaf {x =1.; y =1.}, {x =1.; y =0.}, Leaf {x =0.; y =1.}))"

by mdemare 19y ago

Steve Yegge, who you're quoting as being in favor of OCaml, has since implied that he found it lacking on closer inspection, but, uncharacteristically, without writing at length about it.

yters 19y ago

At the top of his follow on article he says it isn't good for server applications, but he'd use it for client side.

mdemare 19y ago
Yeah, here's the quote: "(Note, long after I wrote this entry: I think OCaml has some fairly fundamental problems that keep it from being a first choice for server-side development. If I were to use it for anything, it would be as a substitute for C++ in delivering client-side executable/GUI programs, e.g. for Windows systems. And I still think it's a really cool language.)" Anyone know what he's referring to?
- mfp 19y ago
  Maybe the lack of parallelism in OCaml's threads at the time he wrote that? There are now at least two solutions to obtain speedups on multi-core and multi-processor machines plus scalability by allowing seamless distributed processing: the JoCaml extension, which integrates the join calculus (http://jocaml.inria.fr/ http://jocaml.inria.fr/), and coThreads (http://cothreads.sourceforge.net/ http://cothreads.sourceforge.net/), which comprises shared-memory (with extensions like STM) and message passing while keeping backwards-compatibility with the original Threads library.
- rkts 19y ago
  He's criticized the lack of a generic print function, calling it "a face-smashing insult to usability." http://steve.yegge.googlepages.com/when-polymorphism-fails http://steve.yegge.googlepages.com/when-polymorphism-fails Note that like many of the alleged deficiencies of OCaml, this was a compromise for performance.
  - mfp 19y ago
    Good find. I don't see how this keeps OCaml "from being a first choice for server-side development" while making it an acceptable language for client-side development, though. There are a several hackish polymorphic print implementations, but the best solution so far seems to be the "deriving" camlp4 extension (http://code.google.com/p/deriving/wiki/Introduction http://code.google.com/p/deriving/wiki/Introduction). This looks pretty good: type 'a tree = Leaf of 'a | Branch of 'a tree * 'a * 'a tree deriving (Show) type point = { x : float; y : float } deriving (Show) let points = Branch (Leaf {x=0.0; y=0.0;}, {x=2.0; y=2.0}, Branch (Leaf {x=1.0; y=1.0}, {x=1.0; y=0.0}, Leaf {x=0.0; y=1.0})) Show.show<point tree> points => "Branch (Leaf {x =0.; y =0.}, {x =2.; y =2.}, Branch (Leaf {x =1.; y =1.}, {x =1.; y =0.}, Leaf {x =0.; y =1.}))"