13 ms·

OCaml: what you gain

198 points by edwintorok 13y ago

thebiglebrewski 13y ago
Title made me think of this http://www.youtube.com/watch?v=B9MgWFU3JhM http://www.youtube.com/watch?v=B9MgWFU3JhM
p4bl0 13y ago
If you program in OCaml be sure to checkout Batteries [1], it is an extension (which also replaces some stuff) to the standard library which eliminate most of the criticisms I had against OCaml. Also, don't try to avoid opam [2], I didn't really want to use it at first because I always prefer to use my system's package manager (using Debian), but it makes your life so much easier. [1] http://batteries.forge.ocamlcore.org/ http://batteries.forge.ocamlcore.org/ [2] https://opam.ocaml.org/ https://opam.ocaml.org/
- samdk 13y ago
  If you haven't, also check out Jane Street's Core/Async, which is an almost-complete replacement (and extension) of the standard library. (Info here: http://janestreet.github.io/. http://janestreet.github.io/.) I work for JS so I'm biased, but I think it's quite a nice set of libraries. Because it's been developed mostly internally, we've had a lot of freedom to fix bad decisions, so it hasn't built up as much cruft as might be expected. (Although it is still obviously far from perfect.)
- amirmc 13y ago
  Do people try to avoid using package managers? Why? On my system I regularly use homebrew and opam but also have occasional need for pip, cabal and more recently npm. Not everything is packaged upstream (nor would I expect it to be). I can't imagine how the OCaml ecosystem worked before opam as it's rapidly become a fundamental tool.
  - p4bl0 13y ago
    I don't know, my instinct tells me that I should avoid having many independent package managers in order to keep everything in the same place and avoid conflicts. But I don't really have any reasons to think that those are better ways to do things.
    - avsm 13y ago
      That's a pretty reasonable thing to want. One area where we'd like to improve OPAM is to output Debian and RPM spec files. This requires some surgery in various build systems, but would make upstreaming binary packages and releases so much easier...
    - tommorris 13y ago
      My instinct agrees with you, but for one small matter. Ubuntu only just started packaging Ruby 1.9.3 - a version that came out years ago and which is to be deprecated next year - in the latest version. I don't know about OCaml but trying to do Ruby or Python development without using pip or gems (not to mention virtualenvs or RVM gemsets etc.) seems like an exercise in futility and perpetual brokenness. I'd like it if system package managers could actually keep up with the needs of developers, but they seem to have failed. Until they can get their shit together, we now have the irritation of managing all these many, many language-specific package managers rather than just using apt-get like sane people. If the system level package manager were able to talk to the language level package managers, that'd be a big improvement. The number of times I've typed `sudo gem install nokogiri` and then had to fumble around and work out exactly which variant of libxml-dev-0 or whatever is needed before I can install a RubyGem with a native dependency shows we've got some brokenness that needs fixing.
      - silentOpen 13y ago
        Conveniently, opam uses the same upgrade description format as apt < http://www.mancoosi.org/cudf/ http://www.mancoosi.org/cudf/ > which should make integration achievable.
      - technomancy 13y ago
nathell 13y ago
I have very fond memories of OCaml. It was OCaml that introduced me to functional programming, way back in 2000 in my freshman year at the uni. I'm a Lisper/Clojurian these days, but I think warmly of OCaml's type system, the speed, the self-containedness of the distribution, and the fact that getting the code to compile tends to mean getting it to actually work. My #1 gripe with OCaml is the fact that its strings are composed of single-byte characters. I know there's Camomile, but not having it as part of the language core creates a sense of disintegration akin to PHP and Python 2. There's also this: http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html which I mostly agree with. But, all in all, OCaml rocks.
- fzltrp 13y ago
  > I know there's Camomile Camomille is great, but it exhaustively covers the whole UTF standard, which you might not need for more casual uses. There are other libraries bringing lighter support for UTF strings (ocamlnet for instance I believe). Nevertheless, Camomille does a pretty good job if you're concerned by compliance. > There's also this: http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html which I mostly agree with. It's a pretty old page. I'm not sure its content is still accurate. I'll have to look into that.
  - agumonkey 13y ago
    > created: 2007-01-31 > updated: 2013-02-11 not that old, even though ocaml metabolic rate increased a lot in the recent years
    - silentOpen 13y ago
      Except it's no longer accurate (e.g. native backtraces work just fine). Would someone really think that OCaml sucks and maintain an accurate page about that fact for 6 years? That sort of nonsensical dedication should at least prompt you to check its facts.
    - fzltrp 13y ago
      Well, I don't know. The "No polymorphism" section is misleading (though polymorphism doesn't carry the same meaning from one language to the next): There's this comment on higher order functions not being supported which surprises me. See the section 7.13[1] and 7.14 of the OCaml documentation. These features are availabe since ver 3.12 of the distribution. [1]: http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#sec227 http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#se...
Buttons840 13y ago
OCaml looks really good, I've heard good things about it for awhile now. I'd like to learn more but and currently learning Haskell and want to focus on learning that for awhile. Does anyone know why OCaml gets compared to Haskell so often? It sounds like OCaml doesn't force a purely functional paradigm on you, so how is it any more functional that a number of good scripting languages (Python, Ruby, Peal, etc)?
- e12e 13y ago
  > Does anyone know why OCaml gets compared to Haskell so often? I seem to recall (incorrectly, apparently) that there is a common thread going back to Standard ML for both OCaml and Haskell. Appears, Haskell goes back to Miranda which borrows from SML -- but it's not entirely incorrect to say that both OCaml and Haskell are built on the shoulders of SML. My take is that OCaml was seen as a way to make a "useful" MetaLanguage, fit for more than experimental language implementations -- while Haskell was conceived by some crazy people that didn't think it was hard enough to get any useful work done in SML ;-) Now, Haskell has evolved into something that actually is useful, and the biggest difference AFAIK is that Haskell leans towards strict and lazy than OCaml. As they are both "modern" MLs, it's natural to compare them -- why Haskell isn't compared more often to SML might just be that there are a few programs actually written in OCaml that people are aware of ;-)
- MonkeyIsNull 13y ago
  Both are descended from ML, but have found a lot more "RealWorld" usage than ML. If you know ML it makes it a lot easier to learn Haskell or OCaml.
- chc 13y ago
  OCaml is not strictly pure, but it is definitely more strongly functional than Python or Perl. What matters is not that a language completely disallows mutation so much as that it helps you write in a functional style. The functional path is usually the happy path in OCaml, whereas in Ruby mutation and statefulness just come naturally. The basis of OCaml is functions that transform one thing into another. The basis of Ruby is objects that encapsulate some state and send messages to other objects to get them to change their state.
rjzzleep 13y ago
You might like F# even more(well except that clr is not as good outside of windows, but still pretty decent) As my coworker at the time put it. If Ocaml and python had a baby together it would be f#
- doorhammer 13y ago
  I'm a big fan of F# as well. I haven't tried it outside of windows, on mono. I've always wondered how well supported mono was and what the library ecosystem was like (I could just google that, and probably will) Any personal experience with it? Right now I'm diving into haskell, partly because I want a static, type-inferred, functional language on linux (my home platform of choice) and partly because I like the idea of using a language that has really pure (functionally and generally) ideas it's trying to implement. Digging it a lot so far as well.
  - platz 13y ago
    The performance on Mono is a bit less but I imagine it can do pure things just fine.
  - balakk 13y ago
    F# has a huge following on macs. The Xamarin guys drive it, and practically every major open source .Net library is available for mono. I haven't tested it on linux, but I've found it works pretty well on macs.
    - latkin 13y ago
      The Seattle F# user group just had an event last night, and the first talk was 1 hour on how to create iOS apps with F# using Xamarin/Mac. If anyone is interested, a recording is at http://www.youtube.com/watch?v=MriHEnq5MR4 http://www.youtube.com/watch?v=MriHEnq5MR4
  - Rickasaurus 13y ago
    It's getting better and better. They even have an F# programmer working stuff at Xamarin now. Check this out: http://7sharpnine.com/posts/danger-unstable-structure/ http://7sharpnine.com/posts/danger-unstable-structure/
srean 13y ago
If I may repeat an old comment of mine, lightly edited for freshness (I dont mean to hijack this thread. It is not often that I get an opportunity to interact with people on HN who are fond of OCaML or are likely to have an interest in it. This is the exact demographics who might appreciate Felix) -- For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tut/tutorial.fdoc http://felix-lang.org/share/src/web/tut/tutorial.fdoc The site is undergoing a major reorganization right now, so some links will break. It is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines baked in. 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. Its own demo webserver is based on coroutines, this is the same webserver that serves the language tutorials. 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. With inaccuracies in analogies assumed, Felix is to C++ what F# is to C# or to some extent Scala is to Java. 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 fullfledged 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 quite fast and not hard to beat or meet C with. -- Removing comment and putting it here to conserve real estate. @zem I think you just blew your cover :) As I said its been mostly a one man effort, so there are areas that need work. Its an exciting language, welcome aboard. @jnbiche Oh no! I am by no means the creator, just someone who finds it exciting.
- jnbiche 13y ago
  Assuming you're the creator, I'd highly suggest putting some code samples on the language home page, so people interested in the language can see what it looks like at a glance without wading through documentation. I'm sure you've got a million other things to do, but showing more code could help speed up adoption.
supercoder 13y ago
But what you lose seems to be readability if going by this code sample let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in explain#connect#activate ~callback:(fun () -> show_explanation impl) |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev);
- samdk 13y ago
  If you combine many lines of code into one, you lose readability in any language ;). Probably you would actually format this as follows: let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in explain#connect#activate ~callback:(fun () -> show_explanation impl) |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev); Which is rather nicer.
- fzltrp 13y ago
  I don't know how other similar languages deal with GUI. It's always sort of hairy, obscure code when you look at it closely. Mainstream languages (like Java) usually give you GUI building tools which generate all the boilerplate stuff, but if you look at that generated code, it doesn't look so appealing either imho. If you know the GUI libraries inside out, then the code becomes much easier to grasp though. The lablgtk library (which provides gtk support) is quite well written, providing both a modular interface and objects, but indeed there's a learning curve. Lastly, you might find it more palatable with a little bit of formatting: let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in let callback () = show_explanation impl in explain#connect#activate ~callback |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev)
  - Eiwatah4 13y ago
    > I don't know how other similar languages deal with GUI. It's always sort of hairy, obscure code when you look at it closely. The best languages for GUIs I've seen are specialized declarative DSLs. Things like QML, XAML, JavaFX FXML, XUL, and even HTML. Anything else very much sucks, in my experience.
mercurial 13y ago
> Another example is the Config object. When I started the Python code back in 2005, I was very excited about using the idea of dependency injection for connecting together software modules (this is the basis of how 0install runs programs). Yet, for some reason I can’t explain, it didn’t occur to me to use a dependency injection style within the code. Instead, I made a load of singleton objects. Later, in an attempt to make things more testable, I moved all the singletons to a Config object and passed that around everywhere. I wasn’t proud of this design even at the time, but it was the simplest way forward. That's called a "god object", unless I'm mistaken. It's an abomination in any language. I have the misfortune of maintaining a codebase with this "feature". Never, ever, do anything like this.
- raphinou 13y ago
  Never used or inherited such a design, but I'm curious about what practical problem you encoutered. Care to illustrate?
  - mercurial 13y ago
    Once you have implemented this design pervasively, you can forget about reusing your code in another context. Because it is impossible to tell which part of the god object is needed in a given part of the code, you have to initialize everything in the god object. With a bit of luck, you're working in Java and mixing this anti-pattern with some Spring dependency injection, in order to make this mess really impossible to untangle. And obviously it encourages mixing up layers. Why have modularity when you can access your data access components from anywhere? And in general, circular dependencies are a code smell. Whenever I thought I needed to use them, I came to realize it was the wrong decision.
raphinou 13y ago
I'm planning to learn ocaml in the coming weeks, as I want to try ocsigen (http://ocsigen.org/ http://ocsigen.org/). Seems to me there is good activity in the Ocaml community lately (eg new books came out recently)
- amirmc 13y ago
  New books as well as a lot of new tooling and libraries. A lot of it being coordinated from OCaml Labs in Cambridge UK (http://OCaml.io http://OCaml.io) and OCamlPro in France.
- p4bl0 13y ago
  I like OCaml but really, Ocisgen is crap. People making it have no idea how today's web works. Some parts of it (lwt, js_of_ocaml) are nice and maybe useful piece of code, but you don't want to use the framework as a whole to develop a webapp. The problem with Ocsigen is that it reinvents the meaning of everything, even the HTTP verbs, to suit its internal needs. For example, it is not possible (or it must be very painful) to make an API for your Ocsigen app so that other apps can interact with yours. First, you have to forget PUTs, HEADs, and DELETEs, but also GETs and POSTs are used incoherently by the resulting code to update parts of the webpage, submit forms, etc. If you want to make a site/webapp that only focus on itself and never have to interact with anything else than its visitors, then Ocsigen might be a suitable tool for the job, otherwise I wouldn't use it. Disclaimer: I only used Ocsigen for one day, it was at JFLO, which expansion in French would translate to French Ocsigen Lectures Day. I get what I know of it and what I'm saying here by the day-long courses and hands-on tutorials given by Ocsigen developers and by discussing these problems with them afterwards.
swah 13y ago
OCaml is a great language, but IIRC the creators didn't talk much to the community, about where they were going, etc. Contrast with Clojure, Golang, Python... So many people steer away and go bet on something else.
- username42 13y ago
  caml-light was a marvellous language to teach computer science (I have learned it in 1992). It was interpreted bytecode. Later "Caml Special Light" has improved its speed. More later OCaml has added objects. There is a good history at http://caml.inria.fr/about/history.en.html#idp1416640 http://caml.inria.fr/about/history.en.html#idp1416640 . The purpose of the language was research and teaching. I think it was never intended to be "battery included". The fact that so many people use it for real work and that so many libraries have been developed has a simple explanation: the difficulty to find a good language to have the job done. OCaml is a very good language. I think it is easier to learn OCaml than haskell. Scala is more recent than OCaml and is more "battery included". I think that Scala will progressively replace OCaml and it a better fit for professional work.
- avsm 13y ago
  The conversation between the OCaml creators and the community is a lot more focussed. Back in 2005 when we were developing the Xen toolstack using OCaml [1], I subscribed Xensource to the Caml Consortium [2]. This let us meet with the main team once a year, and air our concerns in a structured way. This is so much easier to handle than a firehose of e-mails. Nowadays I still attend the annual Consortium meeting, but more in a capacity of reporting on our activities at OCaml Labs and there are still a healthy set of industrial users who like this mode of interaction. [1] http://anil.recoil.org/papers/2010-icfp-xen.pdf http://anil.recoil.org/papers/2010-icfp-xen.pdf [2] http://caml.inria.fr/consortium/ http://caml.inria.fr/consortium/

198 points by edwintorok 13y ago

Title made me think of this http://www.youtube.com/watch?v=B9MgWFU3JhM http://www.youtube.com/watch?v=B9MgWFU3JhM

p4bl0 13y ago

If you program in OCaml be sure to checkout Batteries [1], it is an extension (which also replaces some stuff) to the standard library which eliminate most of the criticisms I had against OCaml. Also, don't try to avoid opam [2], I didn't really want to use it at first because I always prefer to use my system's package manager (using Debian), but it makes your life so much easier. [1] http://batteries.forge.ocamlcore.org/ http://batteries.forge.ocamlcore.org/ [2] https://opam.ocaml.org/ https://opam.ocaml.org/

samdk 13y ago
If you haven't, also check out Jane Street's Core/Async, which is an almost-complete replacement (and extension) of the standard library. (Info here: http://janestreet.github.io/. http://janestreet.github.io/.) I work for JS so I'm biased, but I think it's quite a nice set of libraries. Because it's been developed mostly internally, we've had a lot of freedom to fix bad decisions, so it hasn't built up as much cruft as might be expected. (Although it is still obviously far from perfect.)
amirmc 13y ago
Do people try to avoid using package managers? Why? On my system I regularly use homebrew and opam but also have occasional need for pip, cabal and more recently npm. Not everything is packaged upstream (nor would I expect it to be). I can't imagine how the OCaml ecosystem worked before opam as it's rapidly become a fundamental tool.
- p4bl0 13y ago
  I don't know, my instinct tells me that I should avoid having many independent package managers in order to keep everything in the same place and avoid conflicts. But I don't really have any reasons to think that those are better ways to do things.
  - avsm 13y ago
    That's a pretty reasonable thing to want. One area where we'd like to improve OPAM is to output Debian and RPM spec files. This requires some surgery in various build systems, but would make upstreaming binary packages and releases so much easier...
  - tommorris 13y ago
    My instinct agrees with you, but for one small matter. Ubuntu only just started packaging Ruby 1.9.3 - a version that came out years ago and which is to be deprecated next year - in the latest version. I don't know about OCaml but trying to do Ruby or Python development without using pip or gems (not to mention virtualenvs or RVM gemsets etc.) seems like an exercise in futility and perpetual brokenness. I'd like it if system package managers could actually keep up with the needs of developers, but they seem to have failed. Until they can get their shit together, we now have the irritation of managing all these many, many language-specific package managers rather than just using apt-get like sane people. If the system level package manager were able to talk to the language level package managers, that'd be a big improvement. The number of times I've typed `sudo gem install nokogiri` and then had to fumble around and work out exactly which variant of libxml-dev-0 or whatever is needed before I can install a RubyGem with a native dependency shows we've got some brokenness that needs fixing.
    - silentOpen 13y ago
      Conveniently, opam uses the same upgrade description format as apt < http://www.mancoosi.org/cudf/ http://www.mancoosi.org/cudf/ > which should make integration achievable.
    - technomancy 13y ago

nathell 13y ago

I have very fond memories of OCaml. It was OCaml that introduced me to functional programming, way back in 2000 in my freshman year at the uni. I'm a Lisper/Clojurian these days, but I think warmly of OCaml's type system, the speed, the self-containedness of the distribution, and the fact that getting the code to compile tends to mean getting it to actually work. My #1 gripe with OCaml is the fact that its strings are composed of single-byte characters. I know there's Camomile, but not having it as part of the language core creates a sense of disintegration akin to PHP and Python 2. There's also this: http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html which I mostly agree with. But, all in all, OCaml rocks.

fzltrp 13y ago
> I know there's Camomile Camomille is great, but it exhaustively covers the whole UTF standard, which you might not need for more casual uses. There are other libraries bringing lighter support for UTF strings (ocamlnet for instance I believe). Nevertheless, Camomille does a pretty good job if you're concerned by compliance. > There's also this: http://www.podval.org/~sds/ocaml-sucks.html http://www.podval.org/~sds/ocaml-sucks.html which I mostly agree with. It's a pretty old page. I'm not sure its content is still accurate. I'll have to look into that.
- agumonkey 13y ago
  > created: 2007-01-31 > updated: 2013-02-11 not that old, even though ocaml metabolic rate increased a lot in the recent years
  - silentOpen 13y ago
    Except it's no longer accurate (e.g. native backtraces work just fine). Would someone really think that OCaml sucks and maintain an accurate page about that fact for 6 years? That sort of nonsensical dedication should at least prompt you to check its facts.
  - fzltrp 13y ago
    Well, I don't know. The "No polymorphism" section is misleading (though polymorphism doesn't carry the same meaning from one language to the next): There's this comment on higher order functions not being supported which surprises me. See the section 7.13[1] and 7.14 of the OCaml documentation. These features are availabe since ver 3.12 of the distribution. [1]: http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#sec227 http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#se...

Buttons840 13y ago

OCaml looks really good, I've heard good things about it for awhile now. I'd like to learn more but and currently learning Haskell and want to focus on learning that for awhile. Does anyone know why OCaml gets compared to Haskell so often? It sounds like OCaml doesn't force a purely functional paradigm on you, so how is it any more functional that a number of good scripting languages (Python, Ruby, Peal, etc)?

e12e 13y ago
> Does anyone know why OCaml gets compared to Haskell so often? I seem to recall (incorrectly, apparently) that there is a common thread going back to Standard ML for both OCaml and Haskell. Appears, Haskell goes back to Miranda which borrows from SML -- but it's not entirely incorrect to say that both OCaml and Haskell are built on the shoulders of SML. My take is that OCaml was seen as a way to make a "useful" MetaLanguage, fit for more than experimental language implementations -- while Haskell was conceived by some crazy people that didn't think it was hard enough to get any useful work done in SML ;-) Now, Haskell has evolved into something that actually is useful, and the biggest difference AFAIK is that Haskell leans towards strict and lazy than OCaml. As they are both "modern" MLs, it's natural to compare them -- why Haskell isn't compared more often to SML might just be that there are a few programs actually written in OCaml that people are aware of ;-)
MonkeyIsNull 13y ago
Both are descended from ML, but have found a lot more "RealWorld" usage than ML. If you know ML it makes it a lot easier to learn Haskell or OCaml.
chc 13y ago
OCaml is not strictly pure, but it is definitely more strongly functional than Python or Perl. What matters is not that a language completely disallows mutation so much as that it helps you write in a functional style. The functional path is usually the happy path in OCaml, whereas in Ruby mutation and statefulness just come naturally. The basis of OCaml is functions that transform one thing into another. The basis of Ruby is objects that encapsulate some state and send messages to other objects to get them to change their state.

rjzzleep 13y ago

You might like F# even more(well except that clr is not as good outside of windows, but still pretty decent) As my coworker at the time put it. If Ocaml and python had a baby together it would be f#

doorhammer 13y ago
I'm a big fan of F# as well. I haven't tried it outside of windows, on mono. I've always wondered how well supported mono was and what the library ecosystem was like (I could just google that, and probably will) Any personal experience with it? Right now I'm diving into haskell, partly because I want a static, type-inferred, functional language on linux (my home platform of choice) and partly because I like the idea of using a language that has really pure (functionally and generally) ideas it's trying to implement. Digging it a lot so far as well.
- platz 13y ago
  The performance on Mono is a bit less but I imagine it can do pure things just fine.
- balakk 13y ago
  F# has a huge following on macs. The Xamarin guys drive it, and practically every major open source .Net library is available for mono. I haven't tested it on linux, but I've found it works pretty well on macs.
  - latkin 13y ago
    The Seattle F# user group just had an event last night, and the first talk was 1 hour on how to create iOS apps with F# using Xamarin/Mac. If anyone is interested, a recording is at http://www.youtube.com/watch?v=MriHEnq5MR4 http://www.youtube.com/watch?v=MriHEnq5MR4
- Rickasaurus 13y ago
  It's getting better and better. They even have an F# programmer working stuff at Xamarin now. Check this out: http://7sharpnine.com/posts/danger-unstable-structure/ http://7sharpnine.com/posts/danger-unstable-structure/

srean 13y ago

If I may repeat an old comment of mine, lightly edited for freshness (I dont mean to hijack this thread. It is not often that I get an opportunity to interact with people on HN who are fond of OCaML or are likely to have an interest in it. This is the exact demographics who might appreciate Felix) -- For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tut/tutorial.fdoc http://felix-lang.org/share/src/web/tut/tutorial.fdoc The site is undergoing a major reorganization right now, so some links will break. It is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines baked in. 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. Its own demo webserver is based on coroutines, this is the same webserver that serves the language tutorials. 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. With inaccuracies in analogies assumed, Felix is to C++ what F# is to C# or to some extent Scala is to Java. 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 fullfledged 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 quite fast and not hard to beat or meet C with. -- Removing comment and putting it here to conserve real estate. @zem I think you just blew your cover :) As I said its been mostly a one man effort, so there are areas that need work. Its an exciting language, welcome aboard. @jnbiche Oh no! I am by no means the creator, just someone who finds it exciting.

jnbiche 13y ago
Assuming you're the creator, I'd highly suggest putting some code samples on the language home page, so people interested in the language can see what it looks like at a glance without wading through documentation. I'm sure you've got a million other things to do, but showing more code could help speed up adoption.

supercoder 13y ago

But what you lose seems to be readability if going by this code sample let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in explain#connect#activate ~callback:(fun () -> show_explanation impl) |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev);

samdk 13y ago
If you combine many lines of code into one, you lose readability in any language ;). Probably you would actually format this as follows: let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in explain#connect#activate ~callback:(fun () -> show_explanation impl) |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev); Which is rather nicer.
fzltrp 13y ago
I don't know how other similar languages deal with GUI. It's always sort of hairy, obscure code when you look at it closely. Mainstream languages (like Java) usually give you GUI building tools which generate all the boilerplate stuff, but if you look at that generated code, it doesn't look so appealing either imho. If you know the GUI libraries inside out, then the code becomes much easier to grasp though. The lablgtk library (which provides gtk support) is quite well written, providing both a modular interface and objects, but indeed there's a learning curve. Lastly, you might find it more palatable with a little bit of formatting: let menu = GMenu.menu () in let explain = GMenu.menu_item ~packing:menu#add ~label:"Explain this decision" () in let callback () = show_explanation impl in explain#connect#activate ~callback |> ignore; menu#popup ~button:(B.button bev) ~time:(B.time bev)
- Eiwatah4 13y ago
  > I don't know how other similar languages deal with GUI. It's always sort of hairy, obscure code when you look at it closely. The best languages for GUIs I've seen are specialized declarative DSLs. Things like QML, XAML, JavaFX FXML, XUL, and even HTML. Anything else very much sucks, in my experience.

mercurial 13y ago

> Another example is the Config object. When I started the Python code back in 2005, I was very excited about using the idea of dependency injection for connecting together software modules (this is the basis of how 0install runs programs). Yet, for some reason I can’t explain, it didn’t occur to me to use a dependency injection style within the code. Instead, I made a load of singleton objects. Later, in an attempt to make things more testable, I moved all the singletons to a Config object and passed that around everywhere. I wasn’t proud of this design even at the time, but it was the simplest way forward. That's called a "god object", unless I'm mistaken. It's an abomination in any language. I have the misfortune of maintaining a codebase with this "feature". Never, ever, do anything like this.

raphinou 13y ago
Never used or inherited such a design, but I'm curious about what practical problem you encoutered. Care to illustrate?
- mercurial 13y ago
  Once you have implemented this design pervasively, you can forget about reusing your code in another context. Because it is impossible to tell which part of the god object is needed in a given part of the code, you have to initialize everything in the god object. With a bit of luck, you're working in Java and mixing this anti-pattern with some Spring dependency injection, in order to make this mess really impossible to untangle. And obviously it encourages mixing up layers. Why have modularity when you can access your data access components from anywhere? And in general, circular dependencies are a code smell. Whenever I thought I needed to use them, I came to realize it was the wrong decision.

raphinou 13y ago

I'm planning to learn ocaml in the coming weeks, as I want to try ocsigen (http://ocsigen.org/ http://ocsigen.org/). Seems to me there is good activity in the Ocaml community lately (eg new books came out recently)

amirmc 13y ago
New books as well as a lot of new tooling and libraries. A lot of it being coordinated from OCaml Labs in Cambridge UK (http://OCaml.io http://OCaml.io) and OCamlPro in France.
p4bl0 13y ago
I like OCaml but really, Ocisgen is crap. People making it have no idea how today's web works. Some parts of it (lwt, js_of_ocaml) are nice and maybe useful piece of code, but you don't want to use the framework as a whole to develop a webapp. The problem with Ocsigen is that it reinvents the meaning of everything, even the HTTP verbs, to suit its internal needs. For example, it is not possible (or it must be very painful) to make an API for your Ocsigen app so that other apps can interact with yours. First, you have to forget PUTs, HEADs, and DELETEs, but also GETs and POSTs are used incoherently by the resulting code to update parts of the webpage, submit forms, etc. If you want to make a site/webapp that only focus on itself and never have to interact with anything else than its visitors, then Ocsigen might be a suitable tool for the job, otherwise I wouldn't use it. Disclaimer: I only used Ocsigen for one day, it was at JFLO, which expansion in French would translate to French Ocsigen Lectures Day. I get what I know of it and what I'm saying here by the day-long courses and hands-on tutorials given by Ocsigen developers and by discussing these problems with them afterwards.

swah 13y ago

OCaml is a great language, but IIRC the creators didn't talk much to the community, about where they were going, etc. Contrast with Clojure, Golang, Python... So many people steer away and go bet on something else.

username42 13y ago
caml-light was a marvellous language to teach computer science (I have learned it in 1992). It was interpreted bytecode. Later "Caml Special Light" has improved its speed. More later OCaml has added objects. There is a good history at http://caml.inria.fr/about/history.en.html#idp1416640 http://caml.inria.fr/about/history.en.html#idp1416640 . The purpose of the language was research and teaching. I think it was never intended to be "battery included". The fact that so many people use it for real work and that so many libraries have been developed has a simple explanation: the difficulty to find a good language to have the job done. OCaml is a very good language. I think it is easier to learn OCaml than haskell. Scala is more recent than OCaml and is more "battery included". I think that Scala will progressively replace OCaml and it a better fit for professional work.
avsm 13y ago
The conversation between the OCaml creators and the community is a lot more focussed. Back in 2005 when we were developing the Xen toolstack using OCaml [1], I subscribed Xensource to the Caml Consortium [2]. This let us meet with the main team once a year, and air our concerns in a structured way. This is so much easier to handle than a firehose of e-mails. Nowadays I still attend the annual Consortium meeting, but more in a capacity of reporting on our activities at OCaml Labs and there are still a healthy set of industrial users who like this mode of interaction. [1] http://anil.recoil.org/papers/2010-icfp-xen.pdf http://anil.recoil.org/papers/2010-icfp-xen.pdf [2] http://caml.inria.fr/consortium/ http://caml.inria.fr/consortium/