9 ms·

Why OCaml, Why Now?

106 points by croyd 13y ago

qzwxecrvtb 13y ago
Here's the plan -- eliminate perl, python, ruby, php or java or any slow-starting jvm-based language(the featureless landscape of clojure for example), and use just bash, sed, awk, ocaml(to replace the fear of 'C'), and we can also do f# on windows, so there would be crossover between the worlds and peace throughout the land.
fnbr 13y ago
This might be entirely superficial of me, but I always preferred Haskell over OCaml simply because OCaml required me to type ";;" after every line. The only real reason that I can see to choose OCaml over Haskell is that if you learn OCaml, you might be able to work at Jane Street. Is there a strong argument for abandoning my Haskell-ing for OCaml?
- avsm 13y ago
  > This might be entirely superficial of me, but I always preferred Haskell over OCaml simply because OCaml required me to type ";;" after every line. That's easily fixed: only the toplevel requires ;; (to commence evaluation of the phrases you've typed in). Just don't use it in normal code and everything will parse fine.
  - andrewflnr 13y ago
    > everything will parse fine. That's an exaggeration. There are circumstances in files where it's necessary. I didn't realize this, which hung me up for a long time.
    - silentOpen 13y ago
      Don't put non-let expressions at the top level?
    - jon_smark 13y ago
      Would you care to share an example? I've never encountered a justifiable need to write ;; outside the REPL. The only uses of ;; I've encountered "in the wild" were hardly reasonable: essentially top-level code that was not wrapped in a "let () = ..." statement.
      - andrewflnr 13y ago
        I don't recall seeing that recommendation before this thread. That may just be my blindness in skimming things too quickly. In any case, I think it indicates a wart in the language when you have to wrap everything in otherwise useless let blocks just to get it to parse.
- detrino 13y ago
  ;; is a special token used only in the REPL to force evaluation, it is not something you ever use in real code.
  - fnbr 13y ago
    Well, that explains a lot! I'm embarrassed I never got past that.
    - talex5 13y ago
      Don't feel too bad about it. The official OCaml tutorial is also confused: http://ocaml.org/learn/tutorials/structure_of_ocaml_programs.html#Usingandomittingand http://ocaml.org/learn/tutorials/structure_of_ocaml_programs... (someone really should go through these tutorials and fix the various misleading parts) Basically, the rule is to use "let () = ..." for your main block / top-level code and don't use ";;" ever.
      - deleted 13y ago
        [deleted]
      - detrino 13y ago
        For reference, here is the tutorial's example reformatted in a more reasonable way: open Random open Graphics let rec iterate r x_init i = if i = 1 then x_init else let x = iterate r x_init (i - 1) in r *. x *. (1.0 -. x) let main () = self_init (); open_graph " 640x480"; for x = 0 to 639 do let r = 4.0 *. (float_of_int x) /. 640.0 in for i = 0 to 39 do let x_init = Random.float 1.0 in let x_final = iterate r x_init 500 in let y = int_of_float (x_final *. 480.) in Graphics.plot x y done done; ignore (read_line ()) let () = main ()
        throwaway7808 13y ago
        The trouble with Ocaml is that you will probably get something like: $ ocaml o.ml File "o.ml", line 2, characters 0-13: Error: Unbound module Graphics And after you've googled for a while and had done: sudo apt-get install liblablgl-ocaml-dev The thing would install 23(!) packages. And after that you will get: $ ocaml o.ml Exception: Graphics.Graphic_failure "fatal I/O error". After which, if you've been in the industry for a decade or two, you will probably decide that you'd better stop wasting your time on that particular language. Besides. It just looks ugly. Almost as ugly as perl.
chimeracoder 13y ago
I'm glad that the author is picking up a new functional programming language, but choosing OCaml over Haskell because of support for the Javascript implementations strikes me as choosing a BMW over a Mercedes[0] because of the number of cupholders it has. If you don't have a particular goal in mind (ie, "I work at Jane Street and need to be compatible with our existing code"), there are a number of other factors in the OCaml vs. Haskell discussion that are far more important. > JS is the only realistic way to write web apps Javascript is the only realistic way to write the front-end of webapps. But that doesn't mean you're wedded to it for your backend technology. And I don't think either OCaml or Haskell have sufficiently advanced DOM bindings, etc. that I'd recommend using either one for client-side work in the browser. [0] I'm not sure if this is a flamewar topic for car nerds - my point is to pick two high-end luxury cars that are both well-respected and each have their own merits.
- copergi 13y ago
  I write all my javascript in haskell, and haven't had any problems. What do you need/want "DOM bindings" for?
  - rprospero 13y ago
    As someone who would like to write his javascript in Haskell, how do you put text on the page without interfacing with the browser's DOM?
    - copergi 13y ago
      Is that a trick question? I don't know how or why you would try to do that.
      - jarrett 13y ago
        You do it all the time in web apps. For example, changing the text of a toggle link between "show" and "hide." For example, with jQuery: $('#toggleLink').click(function() { if ($('#toggleLink').html() == 'Show') { showRollout(); $('#toggleLink').html('Hide'); } else { hideRollout(); $('#toggleLink').html('Show'); ] });
lmm 13y ago
For me Scala has been the not-quite-as-good-as-haskell-but-more-industrially-acceptable language. I'd be very interested to see a more neutral comparison of functional languages for compile-to-JS, because if anything Haskell seems more popular for that - I hadn't heard anything about compiling OCaml to JS before this.
- dstefan 13y ago
  What are you mean at "not-quite-as-good-as-haskell"? What are the killer features of haskell?
  - kasey_junk 13y ago
    Not the original commenter but for me the big ones are purity and cheap direct access to C code.
    - dstefan 13y ago
      You can program in pure mode in scala too(and scalaz framework helps in it). FFI is great but i don't miss it. For better performance there is the java collections and libraries.
      - kasey_junk 13y ago
        Scalaz helps with the idioms but without the purity garuantees you miss out on all the optimizations and verifiability. The java collections & libraries don't help me when I need to manage my own memory. I've spent entirely too much time in the unsafe package because the JVM doesn't allow me to do cheap ffi unlike Haskell or even Microsoft's CLI.
- oddthink 13y ago
  I just started at a Microsoft shop a few months ago (first time for everything), and I actually quite like F#, now that I've had a little while to play with it. It's a good contender for the NQAGAHBMIAL throne. Having used CMUCL/SBCL for a while, I always found ocaml's "well, you can compile your code, but then you can't run it in the REPL" to be off-putting. (For my purposes the CLR JIT compiler for F# is good enough.)
bsaul 13y ago
How do those "to js" code generator behave when used together with frameworks like backbone or angular ? I know things like typescript or dart have special versions of the framworks, but i'm curious to know how the ocaml to js tools behave ( since i've searched for a decent strongly typed server side technology for years, that would be an argument for me to try that language).
- skybrian 13y ago
  I don't know about OCaml, but generally speaking, there is a foreign function calling interface. You'd typically use it for integrating with large standalone codebases you don't want to rewrite (say, CodeMirror) but typically not for frameworky things. If you're going to use the same UI framework there's not much point in switching languages.
- spyder81 13y ago
  OCaml has quite nice JavaScript integration; it has the ability to interact with JS objects, constructors, DOM objects, etc. See the "dom bindings" thread elsewhere in this discussion. Most other AltJS languages I've seen are primarily based around FFI declarations, where all interaction with JS is done via functions declared in the native language as external and implemented in JS.
srean 13y ago
Felix is to C++ what F# is to C# http://felix-lang.org/share/src/web/tut/tutorial.fdoc http://felix-lang.org/share/src/web/tut/tutorial.fdoc (I am not the author, just excited about this language) OCaML programmers will feel immediately at home. It is a mature yet actively developed whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines and threads baked in, although use of threads is somewhat discouraged. It has type-classes as well as modules. Functions written in it may be exported as a CPython module. This might be useful if one wants to gradually transition from a Python based src tree. It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Execution speed is comparable to hand written C++, mostly better. Its grammar is programmable in the sense that it is loaded as a library. So in the same way that languages may acquire libraries, Felix may acquire domain specific syntax. It is also mostly a one man effort but with a feverish pace of development so it comes with its associated advantages and disadvantages. Tooling info is here http://felix-lang.org/share/src/web/ref/tools.fdoc http://felix-lang.org/share/src/web/ref/tools.fdoc The author likes to call it a scripting language but it really is a full-fledged statically compiled language with a single push button build-and-execute command. http://felix-lang.org/ http://felix-lang.org/ The "fastest" claim is a bit playful and tongue in cheek, but it is indeed remarkably fast.
- jeremyjh 13y ago
  Have you actually used Felix? I agree it's a neat language but it felt to me like I'd really have to come up to speed on C++ to make much use of it. It's "FFI" is basically embedded strings of C++ source.
  - srean 13y ago
    You can of course inline C++ snippets in Felix code as you mentioned, but that is not the only way to talk to C++. Felix allows you to create a Felix object from a C++ object (and the reverse) with minimal glue. Take a look here http://felix-lang.org/share/src/web/tut/cbind_index.fdoc http://felix-lang.org/share/src/web/tut/cbind_index.fdoc. With this two styles the boundary between Felix and C++ can be very fluid. It does not incur the typical efficiency hit of a dynamically loaded FFI, although it does allow dynamically loading shared libraries too. If you dont want to use C++ libraries and classes from Felix, you dont need to know C++ to use Felix.
lholden 13y ago
I've found it interesting that OCaml hasn't had more interest given the amount of recent momentum in Haskell. Haskell is an Ivory Tower. The features that generally draw one to the language also tend to be the things that eventually push one away. Haskell has grown a lot over the years however as the language evolves to allow general programming within a pure framework. OCaml on the other hand tends to make a compromise, acknowledging that the programmer occasionally needs a different tool for the job. OCaml allows the programmer to opt into things like mutability and objected oriented code when the need arises. These compromises can also be seen as the languages downside however. I find it interesting that the driver for the author into OCaml is JavsScript... but it's nice to see OCaml come up a bit more often. :)
- tel 13y ago
  I feel it's similar to any competitive environment: differentiation requires making strong tradeoffs. Haskell's choice of tradeoffs---while initially very ivory tower---have led to to become a strongly differentiated language. You not only learn how HM typing and full commitment FP feel, but also how to structure code purely, compose effects, and abuse laziness. So for the very same reasons you give---Haskell has made fewer tradeoffs for "practical" programming---Haskell has become something valuable and interesting. On those tides the community has grown.
  - jamii 13y ago
    Another big obstacle was that the INRIA license effectively prevents forking the language (you can only distribute modified compilers as original source + patch, not as eg a github repo) so for a long time there was a bottleneck on the language evolution. Lots of useful extensions (eg delimited continuations, staging) wilted and died because of that. The rise of OcamlPro and Ocaml Labs does give me hope for the future of the language. There is already renewed momentum behind fixing packaging and handling multicore. Now if someone would just figure out ad-hoc polymorphism (just pick one of the dozens of propasals) and maybe even document camlp4/5....
- Dewie 13y ago
  So maybe "middle of the road" and "pragmatic compromises" are overrated.
jlukecarlson 13y ago
OCaml is actually taught in the second level computer science course at my university. I think its a great language for learning topics like recursion especially with its pattern matching. Its also a great intro to functional programming
boothead 13y ago
If ocaml is a language waiting for a killer app, this might be it: http://www.openmirage.org/ http://www.openmirage.org/ There was a presentation at the FP eXchange in London last Friday about mirage and many a mind was blown!
- andolanra 13y ago
  Haskell also has the analogous HaLVM: https://github.com/GaloisInc/HaLVM https://github.com/GaloisInc/HaLVM
- pjmlp 13y ago
  I really hope such systems take up, as we need OS designed with better languages.
CmonDev 13y ago
"...Facebook created ... a statically typed PHP variant..." - so happy to see another major tech company understand the merits of static typing.
- pestaa 13y ago
  ... and so sad about them further fragmenting the ecosystem with yet another language.
- _halgari 13y ago
  that's because PHP is such a horrible language you need static typing to make sense of the crap. </snark>
  - CmonDev 13y ago
    Agree, same true for JS - so many people trying to fix the mess...
mas644 13y ago
Look, I love OCaml and it's my favorite language syntax-wise, but the real big elephant in the room is not its JS-backend maturity. Rather it doesn't have kernel thread support...all threads are user-level just like Python due to a global lock for garbage collection. This means threads do not run concurrently across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since processors went multi-core. Intel is talking about having hundreds of cores on a single die by next decade and having programs that can't take advantage of that is extremely limiting. Xavier Leroy (the creator of OCaml) and his team at INRIA didn't think this was a big deal because when they were writing this stuff, processors were single core and had been since the beginning. Sure there were multiprocessor machines (not the same as multicore as there are multiple die), but those were only meant for servers/workstations. OCaml seemed very promising around 2006, the peak and end of the single core era with the Intel Pentium 4. What made OCaml so impressive was not only was it this beautifully simple, high-level functional language, but that the native compiler produced very fast code that was comparable to C/C++ performance. However, as multicore processors were introduced (Intel Core, Core 2), not having this capability made writing new code in OCaml less appealing. There are solutions like MPI, but that's lame. The same excuses you hear in the Python world about having true multithreading you hear in the OCaml world. Microsoft was able to do it with F#, which is essentially a clone of Caml by targeting their .NET CLR. Haskell is able to do it with GHC. I still think OCaml is a wonderful language -- not having true multithreading doesn't make it useless. However, to me it has become more like a statically-typed Python which I can use for scripting. Having to use hacks like MPI to do multicore processing is a huge turn off in a multicore world. This is again nothing against the language, but the standard implementation needs a concurrent garbage collector and kernel threads. Otherwise I think OCaml may be doomed to irrelevance in the long run, which would be truly sad.
- edwintorok 13y ago
  Apparently multicore ocaml is worked on again: https://github.com/ocamllabs/compiler-hacking/wiki/Multicore-runtime https://github.com/ocamllabs/compiler-hacking/wiki/Multicore... https://github.com/ocamllabs/compiler-hacking/wiki/Multicore-OCaml https://github.com/ocamllabs/compiler-hacking/wiki/Multicore... That being said you can still use multiple cores by using multiple processes, and that doesn't necesarelly imply MPI. OCamlNet (and probably some other libraries) provide a way to communicate between multiple OCaml processes.
marktangotango 13y ago
OCaml is Object Caml right? What about SML? I always loved SML, but it never got any traction at all. The O in Ocaml always turned me off, they cluttered up the syntax with all the object notation. Does anyone have any insight into why OCaml rose to (relative) prominence and not SML?
- detrino 13y ago
  Ocaml was always the more pragmatic language and for a long time the implementation was significantly faster than anything SML offered. MLton came along very late in the game and offers excellent performance, but doesn't support separate compilation. Edit: A more lengthy comparison: http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/
  - marktangotango 13y ago
    Thanks for the perspective!
- zem 13y ago
  what saddens me is that aliceml [https://www.ps.uni-saarland.de/alice/ https://www.ps.uni-saarland.de/alice/] seems to have died. i've kept it vaguely in the back of my mind as "this looks like a very pleasant language, and as soon as i have a problem in its sweet spot i'll give it a good look", but the last time i went to look at it i realised the last mailing list post was in 2012, and the last home page update in 2007.
- spyder81 13y ago
  For me (the author), it's because SML as it was taught to me is a closed language. It can never and will never change. Perfect for education, perhaps not so useful as a career choice. OCaml has been moving forward; GADTs were added recently, multicore support is coming, and who knows what else is on the horizon.
bunderbunder 13y ago
Considering how strongly opposed the author is to dynamic typing, I'm actually kind of surprised they'd consider OCaml's type system to be acceptable. Technically, yes, it's a statically typed system. But its use of structural typing instead of nominative typing effectively means it takes half the compiler assistance you can get out of static type checking and chucks it out the window. Using structural typing means that a type is nothing more than the sum of its parts; nominative typing makes it possible to add further specificity to types by naming them. This is huge. A language that doesn't do this is a language that can't be taught to understand the difference between 12 meters and 12 Newtons.
- lpw25 13y ago
  Abstraction provides the equivalent of nominative typing. It is easy to differentiate between 12 meters and 12 Newtons with OCaml's type system. In general, it is easy to get nominative behaviour out of a structural system. It is much harder to get structural behaviour out of a nominative system.
- jamii 13y ago
  You may be confused by the fact that the type system will notice the equivalence of two types if the implementations of both are public eg module M = struct type newtons = int let inc some_newtons = some_newtons + 1 end : sig type newtons = int val inc : newtons -> newtons end M.inc 1 (* this works *) module M = struct type newtons = int let inc some_newtons = some_newtons + 1 let in_newtons x = x end : sig type newtons val inc : newtons -> newtons val in_newtons : int -> newtons end M.inc 1 (* type error *) M.inc (in_newtons 1) (* this works *) The use of hidden types in OCaml gives far better control over encapsulation and implementation hiding than any over language I've used.
- lpw25 13y ago
  Also, only some things in OCaml are structurally typed (modules, objects, polymorphic vairants), others are not (records, variants). For example: # type meters = I of int;; type meters = I of int # let meters i = I i;; val meters : int -> meters = <fun> # type newtons = I of int;; type newtons = I of int # let newtons i = I i;; val newtons : int -> newtons = <fun> # let f b = if b then newtons 12 else meters 12;; Characters 36-45: let f b = if b then newtons 12 else meters 12;; ^^^^^^^^^ Error: This expression has type meters but an expression was expected of type newtons

106 points by croyd 13y ago

Here's the plan -- eliminate perl, python, ruby, php or java or any slow-starting jvm-based language(the featureless landscape of clojure for example), and use just bash, sed, awk, ocaml(to replace the fear of 'C'), and we can also do f# on windows, so there would be crossover between the worlds and peace throughout the land.

fnbr 13y ago

This might be entirely superficial of me, but I always preferred Haskell over OCaml simply because OCaml required me to type ";;" after every line. The only real reason that I can see to choose OCaml over Haskell is that if you learn OCaml, you might be able to work at Jane Street. Is there a strong argument for abandoning my Haskell-ing for OCaml?

avsm 13y ago
> This might be entirely superficial of me, but I always preferred Haskell over OCaml simply because OCaml required me to type ";;" after every line. That's easily fixed: only the toplevel requires ;; (to commence evaluation of the phrases you've typed in). Just don't use it in normal code and everything will parse fine.
- andrewflnr 13y ago
  > everything will parse fine. That's an exaggeration. There are circumstances in files where it's necessary. I didn't realize this, which hung me up for a long time.
  - silentOpen 13y ago
    Don't put non-let expressions at the top level?
  - jon_smark 13y ago
    Would you care to share an example? I've never encountered a justifiable need to write ;; outside the REPL. The only uses of ;; I've encountered "in the wild" were hardly reasonable: essentially top-level code that was not wrapped in a "let () = ..." statement.
    - andrewflnr 13y ago
      I don't recall seeing that recommendation before this thread. That may just be my blindness in skimming things too quickly. In any case, I think it indicates a wart in the language when you have to wrap everything in otherwise useless let blocks just to get it to parse.
detrino 13y ago
;; is a special token used only in the REPL to force evaluation, it is not something you ever use in real code.
- fnbr 13y ago
  Well, that explains a lot! I'm embarrassed I never got past that.
  - talex5 13y ago
    Don't feel too bad about it. The official OCaml tutorial is also confused: http://ocaml.org/learn/tutorials/structure_of_ocaml_programs.html#Usingandomittingand http://ocaml.org/learn/tutorials/structure_of_ocaml_programs... (someone really should go through these tutorials and fix the various misleading parts) Basically, the rule is to use "let () = ..." for your main block / top-level code and don't use ";;" ever.
    - deleted 13y ago
      [deleted]
    - detrino 13y ago
      For reference, here is the tutorial's example reformatted in a more reasonable way: open Random open Graphics let rec iterate r x_init i = if i = 1 then x_init else let x = iterate r x_init (i - 1) in r *. x *. (1.0 -. x) let main () = self_init (); open_graph " 640x480"; for x = 0 to 639 do let r = 4.0 *. (float_of_int x) /. 640.0 in for i = 0 to 39 do let x_init = Random.float 1.0 in let x_final = iterate r x_init 500 in let y = int_of_float (x_final *. 480.) in Graphics.plot x y done done; ignore (read_line ()) let () = main ()
      - throwaway7808 13y ago
        The trouble with Ocaml is that you will probably get something like: $ ocaml o.ml File "o.ml", line 2, characters 0-13: Error: Unbound module Graphics And after you've googled for a while and had done: sudo apt-get install liblablgl-ocaml-dev The thing would install 23(!) packages. And after that you will get: $ ocaml o.ml Exception: Graphics.Graphic_failure "fatal I/O error". After which, if you've been in the industry for a decade or two, you will probably decide that you'd better stop wasting your time on that particular language. Besides. It just looks ugly. Almost as ugly as perl.

chimeracoder 13y ago

I'm glad that the author is picking up a new functional programming language, but choosing OCaml over Haskell because of support for the Javascript implementations strikes me as choosing a BMW over a Mercedes[0] because of the number of cupholders it has. If you don't have a particular goal in mind (ie, "I work at Jane Street and need to be compatible with our existing code"), there are a number of other factors in the OCaml vs. Haskell discussion that are far more important. > JS is the only realistic way to write web apps Javascript is the only realistic way to write the front-end of webapps. But that doesn't mean you're wedded to it for your backend technology. And I don't think either OCaml or Haskell have sufficiently advanced DOM bindings, etc. that I'd recommend using either one for client-side work in the browser. [0] I'm not sure if this is a flamewar topic for car nerds - my point is to pick two high-end luxury cars that are both well-respected and each have their own merits.

copergi 13y ago
I write all my javascript in haskell, and haven't had any problems. What do you need/want "DOM bindings" for?
- rprospero 13y ago
  As someone who would like to write his javascript in Haskell, how do you put text on the page without interfacing with the browser's DOM?
  - copergi 13y ago
    Is that a trick question? I don't know how or why you would try to do that.
    - jarrett 13y ago
      You do it all the time in web apps. For example, changing the text of a toggle link between "show" and "hide." For example, with jQuery: $('#toggleLink').click(function() { if ($('#toggleLink').html() == 'Show') { showRollout(); $('#toggleLink').html('Hide'); } else { hideRollout(); $('#toggleLink').html('Show'); ] });

lmm 13y ago

For me Scala has been the not-quite-as-good-as-haskell-but-more-industrially-acceptable language. I'd be very interested to see a more neutral comparison of functional languages for compile-to-JS, because if anything Haskell seems more popular for that - I hadn't heard anything about compiling OCaml to JS before this.

dstefan 13y ago
What are you mean at "not-quite-as-good-as-haskell"? What are the killer features of haskell?
- kasey_junk 13y ago
  Not the original commenter but for me the big ones are purity and cheap direct access to C code.
  - dstefan 13y ago
    You can program in pure mode in scala too(and scalaz framework helps in it). FFI is great but i don't miss it. For better performance there is the java collections and libraries.
    - kasey_junk 13y ago
      Scalaz helps with the idioms but without the purity garuantees you miss out on all the optimizations and verifiability. The java collections & libraries don't help me when I need to manage my own memory. I've spent entirely too much time in the unsafe package because the JVM doesn't allow me to do cheap ffi unlike Haskell or even Microsoft's CLI.
oddthink 13y ago
I just started at a Microsoft shop a few months ago (first time for everything), and I actually quite like F#, now that I've had a little while to play with it. It's a good contender for the NQAGAHBMIAL throne. Having used CMUCL/SBCL for a while, I always found ocaml's "well, you can compile your code, but then you can't run it in the REPL" to be off-putting. (For my purposes the CLR JIT compiler for F# is good enough.)

bsaul 13y ago

How do those "to js" code generator behave when used together with frameworks like backbone or angular ? I know things like typescript or dart have special versions of the framworks, but i'm curious to know how the ocaml to js tools behave ( since i've searched for a decent strongly typed server side technology for years, that would be an argument for me to try that language).

skybrian 13y ago
I don't know about OCaml, but generally speaking, there is a foreign function calling interface. You'd typically use it for integrating with large standalone codebases you don't want to rewrite (say, CodeMirror) but typically not for frameworky things. If you're going to use the same UI framework there's not much point in switching languages.
spyder81 13y ago
OCaml has quite nice JavaScript integration; it has the ability to interact with JS objects, constructors, DOM objects, etc. See the "dom bindings" thread elsewhere in this discussion. Most other AltJS languages I've seen are primarily based around FFI declarations, where all interaction with JS is done via functions declared in the native language as external and implemented in JS.

srean 13y ago

Felix is to C++ what F# is to C# http://felix-lang.org/share/src/web/tut/tutorial.fdoc http://felix-lang.org/share/src/web/tut/tutorial.fdoc (I am not the author, just excited about this language) OCaML programmers will feel immediately at home. It is a mature yet actively developed whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines and threads baked in, although use of threads is somewhat discouraged. It has type-classes as well as modules. Functions written in it may be exported as a CPython module. This might be useful if one wants to gradually transition from a Python based src tree. It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Execution speed is comparable to hand written C++, mostly better. Its grammar is programmable in the sense that it is loaded as a library. So in the same way that languages may acquire libraries, Felix may acquire domain specific syntax. It is also mostly a one man effort but with a feverish pace of development so it comes with its associated advantages and disadvantages. Tooling info is here http://felix-lang.org/share/src/web/ref/tools.fdoc http://felix-lang.org/share/src/web/ref/tools.fdoc The author likes to call it a scripting language but it really is a full-fledged statically compiled language with a single push button build-and-execute command. http://felix-lang.org/ http://felix-lang.org/ The "fastest" claim is a bit playful and tongue in cheek, but it is indeed remarkably fast.

jeremyjh 13y ago
Have you actually used Felix? I agree it's a neat language but it felt to me like I'd really have to come up to speed on C++ to make much use of it. It's "FFI" is basically embedded strings of C++ source.
- srean 13y ago
  You can of course inline C++ snippets in Felix code as you mentioned, but that is not the only way to talk to C++. Felix allows you to create a Felix object from a C++ object (and the reverse) with minimal glue. Take a look here http://felix-lang.org/share/src/web/tut/cbind_index.fdoc http://felix-lang.org/share/src/web/tut/cbind_index.fdoc. With this two styles the boundary between Felix and C++ can be very fluid. It does not incur the typical efficiency hit of a dynamically loaded FFI, although it does allow dynamically loading shared libraries too. If you dont want to use C++ libraries and classes from Felix, you dont need to know C++ to use Felix.

lholden 13y ago

I've found it interesting that OCaml hasn't had more interest given the amount of recent momentum in Haskell. Haskell is an Ivory Tower. The features that generally draw one to the language also tend to be the things that eventually push one away. Haskell has grown a lot over the years however as the language evolves to allow general programming within a pure framework. OCaml on the other hand tends to make a compromise, acknowledging that the programmer occasionally needs a different tool for the job. OCaml allows the programmer to opt into things like mutability and objected oriented code when the need arises. These compromises can also be seen as the languages downside however. I find it interesting that the driver for the author into OCaml is JavsScript... but it's nice to see OCaml come up a bit more often. :)

tel 13y ago
I feel it's similar to any competitive environment: differentiation requires making strong tradeoffs. Haskell's choice of tradeoffs---while initially very ivory tower---have led to to become a strongly differentiated language. You not only learn how HM typing and full commitment FP feel, but also how to structure code purely, compose effects, and abuse laziness. So for the very same reasons you give---Haskell has made fewer tradeoffs for "practical" programming---Haskell has become something valuable and interesting. On those tides the community has grown.
- jamii 13y ago
  Another big obstacle was that the INRIA license effectively prevents forking the language (you can only distribute modified compilers as original source + patch, not as eg a github repo) so for a long time there was a bottleneck on the language evolution. Lots of useful extensions (eg delimited continuations, staging) wilted and died because of that. The rise of OcamlPro and Ocaml Labs does give me hope for the future of the language. There is already renewed momentum behind fixing packaging and handling multicore. Now if someone would just figure out ad-hoc polymorphism (just pick one of the dozens of propasals) and maybe even document camlp4/5....
Dewie 13y ago
So maybe "middle of the road" and "pragmatic compromises" are overrated.

jlukecarlson 13y ago

OCaml is actually taught in the second level computer science course at my university. I think its a great language for learning topics like recursion especially with its pattern matching. Its also a great intro to functional programming

boothead 13y ago

If ocaml is a language waiting for a killer app, this might be it: http://www.openmirage.org/ http://www.openmirage.org/ There was a presentation at the FP eXchange in London last Friday about mirage and many a mind was blown!

andolanra 13y ago
Haskell also has the analogous HaLVM: https://github.com/GaloisInc/HaLVM https://github.com/GaloisInc/HaLVM
pjmlp 13y ago
I really hope such systems take up, as we need OS designed with better languages.

CmonDev 13y ago

"...Facebook created ... a statically typed PHP variant..." - so happy to see another major tech company understand the merits of static typing.

pestaa 13y ago
... and so sad about them further fragmenting the ecosystem with yet another language.
_halgari 13y ago
that's because PHP is such a horrible language you need static typing to make sense of the crap. </snark>
- CmonDev 13y ago
  Agree, same true for JS - so many people trying to fix the mess...

mas644 13y ago

Look, I love OCaml and it's my favorite language syntax-wise, but the real big elephant in the room is not its JS-backend maturity. Rather it doesn't have kernel thread support...all threads are user-level just like Python due to a global lock for garbage collection. This means threads do not run concurrently across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since processors went multi-core. Intel is talking about having hundreds of cores on a single die by next decade and having programs that can't take advantage of that is extremely limiting. Xavier Leroy (the creator of OCaml) and his team at INRIA didn't think this was a big deal because when they were writing this stuff, processors were single core and had been since the beginning. Sure there were multiprocessor machines (not the same as multicore as there are multiple die), but those were only meant for servers/workstations. OCaml seemed very promising around 2006, the peak and end of the single core era with the Intel Pentium 4. What made OCaml so impressive was not only was it this beautifully simple, high-level functional language, but that the native compiler produced very fast code that was comparable to C/C++ performance. However, as multicore processors were introduced (Intel Core, Core 2), not having this capability made writing new code in OCaml less appealing. There are solutions like MPI, but that's lame. The same excuses you hear in the Python world about having true multithreading you hear in the OCaml world. Microsoft was able to do it with F#, which is essentially a clone of Caml by targeting their .NET CLR. Haskell is able to do it with GHC. I still think OCaml is a wonderful language -- not having true multithreading doesn't make it useless. However, to me it has become more like a statically-typed Python which I can use for scripting. Having to use hacks like MPI to do multicore processing is a huge turn off in a multicore world. This is again nothing against the language, but the standard implementation needs a concurrent garbage collector and kernel threads. Otherwise I think OCaml may be doomed to irrelevance in the long run, which would be truly sad.

edwintorok 13y ago
Apparently multicore ocaml is worked on again: https://github.com/ocamllabs/compiler-hacking/wiki/Multicore-runtime https://github.com/ocamllabs/compiler-hacking/wiki/Multicore... https://github.com/ocamllabs/compiler-hacking/wiki/Multicore-OCaml https://github.com/ocamllabs/compiler-hacking/wiki/Multicore... That being said you can still use multiple cores by using multiple processes, and that doesn't necesarelly imply MPI. OCamlNet (and probably some other libraries) provide a way to communicate between multiple OCaml processes.

marktangotango 13y ago

OCaml is Object Caml right? What about SML? I always loved SML, but it never got any traction at all. The O in Ocaml always turned me off, they cluttered up the syntax with all the object notation. Does anyone have any insight into why OCaml rose to (relative) prominence and not SML?

detrino 13y ago
Ocaml was always the more pragmatic language and for a long time the implementation was significantly faster than anything SML offered. MLton came along very late in the game and offers excellent performance, but doesn't support separate compilation. Edit: A more lengthy comparison: http://adam.chlipala.net/mlcomp/ http://adam.chlipala.net/mlcomp/
- marktangotango 13y ago
  Thanks for the perspective!
zem 13y ago
what saddens me is that aliceml [https://www.ps.uni-saarland.de/alice/ https://www.ps.uni-saarland.de/alice/] seems to have died. i've kept it vaguely in the back of my mind as "this looks like a very pleasant language, and as soon as i have a problem in its sweet spot i'll give it a good look", but the last time i went to look at it i realised the last mailing list post was in 2012, and the last home page update in 2007.
spyder81 13y ago
For me (the author), it's because SML as it was taught to me is a closed language. It can never and will never change. Perfect for education, perhaps not so useful as a career choice. OCaml has been moving forward; GADTs were added recently, multicore support is coming, and who knows what else is on the horizon.

bunderbunder 13y ago

Considering how strongly opposed the author is to dynamic typing, I'm actually kind of surprised they'd consider OCaml's type system to be acceptable. Technically, yes, it's a statically typed system. But its use of structural typing instead of nominative typing effectively means it takes half the compiler assistance you can get out of static type checking and chucks it out the window. Using structural typing means that a type is nothing more than the sum of its parts; nominative typing makes it possible to add further specificity to types by naming them. This is huge. A language that doesn't do this is a language that can't be taught to understand the difference between 12 meters and 12 Newtons.

lpw25 13y ago
Abstraction provides the equivalent of nominative typing. It is easy to differentiate between 12 meters and 12 Newtons with OCaml's type system. In general, it is easy to get nominative behaviour out of a structural system. It is much harder to get structural behaviour out of a nominative system.
jamii 13y ago
You may be confused by the fact that the type system will notice the equivalence of two types if the implementations of both are public eg module M = struct type newtons = int let inc some_newtons = some_newtons + 1 end : sig type newtons = int val inc : newtons -> newtons end M.inc 1 (* this works *) module M = struct type newtons = int let inc some_newtons = some_newtons + 1 let in_newtons x = x end : sig type newtons val inc : newtons -> newtons val in_newtons : int -> newtons end M.inc 1 (* type error *) M.inc (in_newtons 1) (* this works *) The use of hidden types in OCaml gives far better control over encapsulation and implementation hiding than any over language I've used.
lpw25 13y ago
Also, only some things in OCaml are structurally typed (modules, objects, polymorphic vairants), others are not (records, variants). For example: # type meters = I of int;; type meters = I of int # let meters i = I i;; val meters : int -> meters = <fun> # type newtons = I of int;; type newtons = I of int # let newtons i = I i;; val newtons : int -> newtons = <fun> # let f b = if b then newtons 12 else meters 12;; Characters 36-45: let f b = if b then newtons 12 else meters 12;; ^^^^^^^^^ Error: This expression has type meters but an expression was expected of type newtons