While the core OCaml language is fun to play around in, a lot of the build tools are scattered across the web and hard to decipher (4 year old blog posts with only half-working code don't help). This aims to remedy that, and I'd appreciate any feedback :).
I highly recommend you check out oasis (http://oasis.forge.ocamlcore.org/). It's a meta build system which is quickly gaining traction in the OCaml community. It's still in early development but works extremely well for most projects.
Over the past half year I've been exploring Haskell and so naturally my interest has recently piqued at OCaml. Thank you for this, it couldn't have come at a better time. I wonder if you think it would be worth including camlp4/p5 in the skeleton?
Cool, this would have helped me a lot when I was getting started. An idea: You might want to start the README with 'Skeleton is X'. I had to scan around for a while to figure out what your project actually does.
This is missing one key feature of OCaml: module functors.
Briefly stated, module functors allow you to wrap up a set of functions and types as a module, and state not only which functions and types this module provides but also which functions and types the modules requires. You can plug together module functors with complementary provides and requires, like building with toy bricks.
Many languages support the provides half of this feature (e.g. Java's interfaces) but few support the requires half (Scheme's units are one of the few that come to mind). The advantage of supporting both provides and requires include ability to swap out equivalent implementations of some module, perform massive code abstraction, and to better isolate unit tests without resorting to conditional compilation. (You can quite literally plug a high-level module into a fake lower-level module in order to test the high-level one using one line of code.)
The "language of 2020" will have this, or an equivalent, means of massive abstraction. Or better still, such a mechanism will exist as a separate language unto itself which can work with multiple languages. (Think C-style symbolic linking combined with a .NET ABI.)
Functors simply provide dependency injection for modules. It's no different from any other kind of dependency injection, except that modules themselves are a very flexible unit of organisation.
Look at this video[1], 1:09:40. Apparently their code is too functional (heh…) for F# (or, well, the CLR). Not sure whether that has changed with recent versions of both F# and the .NET platform, although I think some problems are really, really hard to solve if you want to stay compatible with .NET libraries.
I love Ocaml. My only gripe is that the language has a ton of ways to do something.. ie there is a syntactical shortcut for almost everything. So I can see how Python guys might scoff at the language.
It would be pretty cool if someone made a node.js (event lib) like web server for Ocaml.
Sorry about that, I suppose I should'nt lay true faith on the HN dup detector. I typically delete a dup, but for some reason the conversation on this thread has been hot.
This is one of the most important articles of the past year.
It's not just about functional programming being powerful and concise and awesome, even though it is those things. (Mostly, that is. Functional programming, taken too far, can be incomprehensible.)
Ocaml's a very simple language: a bare-bones skeleton for what a 2020 language will look like, a functional C. I don't intend to claim that everyone should drop their favorite languages and switch to ML, but it's important to grok the idea of ML to get a taste for: (1) higher-order functions (instead of objects) as the default abstraction when mutability's not needed, and (2) the power of strong, static typing. The actual "language of 2020" won't be this Ocaml (no multicore support) implementation and probably not Ocaml at all, but it will look a lot like Ocaml, Haskell, and Scala.
Let me bring out one snippet:
Reading code was part of the firm's approach to risk from before we had written our first line of OCaml. Early on, a couple of the most senior traders (including one of the founders) committed to reading every line of code that went into the core trading systems, before those systems went into production.
That's not bullshit. A smart person with a general sense of algorithms, but who's not necessarily a full-time programmer, can read and understand most OCaml code. In C++ this would be impossible; you'd need a C++ expert just to make sure you're not going to get impaled by undefined behavior.
What makes OCaml awesome is that it's the only language I've encountered (Haskell and Scala may have this property; insufficient exposure) where reading average-case code is fun. Haskell is a great language as well, but it seems to be optimized for writers of code; Ocaml's optimized for readers. Yes, there's horrid Ocaml code out there and there's beautiful code in lesser languages, but Ocaml is the only language I've ever encountered where 50th-percentile code looks attractive. The consequence is that people do read code. Sometimes, just for fun. (Yes, imagine that.) I learned a hell of a lot about programming when I was working in Ocaml simply because I enjoyed reading the code. Average-case C++ code is never fun to read, and what matters in a professional environment is not what the language makes possible, but what average code actually ends up looking like.
If you're not familiar in detail with the benefits of functional programming and strong static typing, read this article. Read it 3 times, even.
[+] [-] scott_s|14 years ago|reply
[+] [-] kkwok|14 years ago|reply
[+] [-] chollida1|14 years ago|reply
Yaron really does know his stuff when it comes to OCaml. http://ocaml.janestreet.com/?q=node/61
people interested in some great OCaml libraries should check out what Jane street has released to the public:
http://ocaml.janestreet.com/?q=node/13
[+] [-] Stasyan|14 years ago|reply
[+] [-] wickedchicken|14 years ago|reply
While the core OCaml language is fun to play around in, a lot of the build tools are scattered across the web and hard to decipher (4 year old blog posts with only half-working code don't help). This aims to remedy that, and I'd appreciate any feedback :).
[+] [-] aplusbi|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] fogus|14 years ago|reply
[+] [-] iskander|14 years ago|reply
[+] [-] colanderman|14 years ago|reply
Briefly stated, module functors allow you to wrap up a set of functions and types as a module, and state not only which functions and types this module provides but also which functions and types the modules requires. You can plug together module functors with complementary provides and requires, like building with toy bricks.
Many languages support the provides half of this feature (e.g. Java's interfaces) but few support the requires half (Scheme's units are one of the few that come to mind). The advantage of supporting both provides and requires include ability to swap out equivalent implementations of some module, perform massive code abstraction, and to better isolate unit tests without resorting to conditional compilation. (You can quite literally plug a high-level module into a fake lower-level module in order to test the high-level one using one line of code.)
The "language of 2020" will have this, or an equivalent, means of massive abstraction. Or better still, such a mechanism will exist as a separate language unto itself which can work with multiple languages. (Think C-style symbolic linking combined with a .NET ABI.)
[+] [-] raphscallion|14 years ago|reply
[+] [-] cwzwarich|14 years ago|reply
[+] [-] Stasyan|14 years ago|reply
[+] [-] j2labs|14 years ago|reply
[+] [-] mhd|14 years ago|reply
[1]: http://video.google.com/videoplay?docid=-2336889538700185341
[+] [-] sausagefeet|14 years ago|reply
[+] [-] chrisaycock|14 years ago|reply
http://www.janestreet.com/technology/ocaml.php
[+] [-] chrisaycock|14 years ago|reply
http://news.ycombinator.com/item?id=3047682
[+] [-] agentgt|14 years ago|reply
It would be pretty cool if someone made a node.js (event lib) like web server for Ocaml.
[+] [-] silentbicycle|14 years ago|reply
There's also an OCaml-to-Javascript compiler.
[+] [-] silentbicycle|14 years ago|reply
[+] [-] fogus|14 years ago|reply
[+] [-] michaelochurch|14 years ago|reply
It's not just about functional programming being powerful and concise and awesome, even though it is those things. (Mostly, that is. Functional programming, taken too far, can be incomprehensible.)
Ocaml's a very simple language: a bare-bones skeleton for what a 2020 language will look like, a functional C. I don't intend to claim that everyone should drop their favorite languages and switch to ML, but it's important to grok the idea of ML to get a taste for: (1) higher-order functions (instead of objects) as the default abstraction when mutability's not needed, and (2) the power of strong, static typing. The actual "language of 2020" won't be this Ocaml (no multicore support) implementation and probably not Ocaml at all, but it will look a lot like Ocaml, Haskell, and Scala.
Let me bring out one snippet:
Reading code was part of the firm's approach to risk from before we had written our first line of OCaml. Early on, a couple of the most senior traders (including one of the founders) committed to reading every line of code that went into the core trading systems, before those systems went into production.
That's not bullshit. A smart person with a general sense of algorithms, but who's not necessarily a full-time programmer, can read and understand most OCaml code. In C++ this would be impossible; you'd need a C++ expert just to make sure you're not going to get impaled by undefined behavior.
What makes OCaml awesome is that it's the only language I've encountered (Haskell and Scala may have this property; insufficient exposure) where reading average-case code is fun. Haskell is a great language as well, but it seems to be optimized for writers of code; Ocaml's optimized for readers. Yes, there's horrid Ocaml code out there and there's beautiful code in lesser languages, but Ocaml is the only language I've ever encountered where 50th-percentile code looks attractive. The consequence is that people do read code. Sometimes, just for fun. (Yes, imagine that.) I learned a hell of a lot about programming when I was working in Ocaml simply because I enjoyed reading the code. Average-case C++ code is never fun to read, and what matters in a professional environment is not what the language makes possible, but what average code actually ends up looking like.
If you're not familiar in detail with the benefits of functional programming and strong static typing, read this article. Read it 3 times, even.
[+] [-] unknown|14 years ago|reply
[deleted]