Though, that said, if you're familiar with OCaml then Haskell should be rather easy to pick up syntactically.
OCaml makes monads almost invisible. They're much more in-your-face in Haskell. I'm not sure which one I like better, but it's nice to have a plain ol' for-loop available in OCaml.
(* The entry point *)
let rec go content =
let env = { file = None; modified = []; line = 0; result = [] } in
let lines = split_lines content in
start env lines;
match List.rev env.result with
| [] -> []
| _ :: results -> results
(* Skip the text before the first +++ (to make things work with git show) *)
and start env = function
| [] -> ()
| line :: lines
when String.length line > 4 && String.sub line 0 3 = "+++" ->
header env line;
modified env 0 lines
| _ :: lines -> start env lines
Its beautiful to me because its very concise looking, while still using a fair bit of real English, meaningful symbols, and idioms like [] makes an empty array or whatever. I have to admit, much of this is lost on me, but it does feel more accessible than other FP languages. It almost has a Python feel.[0] https://github.com/facebook/flow/blob/master/hack/parsing/fo...
All in all, it's a combination of features (and a lesser enthusiasm for ASCII-heavy combinators-based DSLs) which makes for code that is potentially as readable as Python.
- :
Is that the prompt from the OCaml REPL (does OCaml have a REPL)?
EDIT: I think I misread things - it's the output from the examples that has the "- :" prefix, so I'm guessing it is REPL output.
# 3;;
- : int = 3
# fun x -> x*x;;
- : int -> int = <fun>that's what the REPL looks like on my end
But having it used in practical conditions, by companies intended to make money and writing "normal" software (i.e. not things related to formal semantics), is still really newsworthy.
And that's OCaml's appeal IMO: it focuses on things that aren't sexy to academics. Good compiler performances due to careful codegen rather than exotic theories, willingness to be "polluted" by side-effects rather than wrangling monad transformers, eager evaluation to get predictability rather than cute code...
Such that, even though they might be distantly familiar with FP in general, its quite likely that articles on particular FP techniques, FP languages, or applications of FP to a particular problem area can still be useful.
Sometimes, it'll be useful just by reminding you of something you've been too caught up with dealing with what is immediately useful to think much about since school, but which might be more applicable to the problems you have now than the problems you had in programming work closer to the time you were in school.
Doesn't it hurt having a GIL?
How awesome is having the ML module system?
GC pauses haven't hurt us really. We usually just spawn a ton of processes so if one process pauses a bit to GC we won't notice.
The module system is awesome. It's something i plan to cover next time I find the time to extend the article.
There is ongoing work to make the runtime multicore friendly without GIL.
Plus the GIL doesn't affect when you write concurrent code, which makes use of green thread, think go-routines.
It is only an issue in Python and Ruby because they jump out to C extensions which use the GIL, while OCaml is a native compiled language.
Anyway OCaml vnext whenever comes out, might be GIL free.
[0] http://issuu.com/careers/ocamldeveloperI did for instance find a couple of interesting (to me) libraries: https://github.com/esperco/ocaml-imap and https://github.com/nojb/ocaml-maildir . But only the first can i "opam install" -- as a newcomer to ocaml (or returnee of sorts) -- I my intuition tells me that being able to set up a chroot/image with just stuff via opam would probably be what I want.
But that's exactly why it'd be nice if someone that actually does this (and uses ocaml in anger) wrote up a proper "How I start"-article.