4 ms·
> Functional programming languages shine when they deal with complex, recursive data structures While I obviously can't comment on the details of the course yo
by avsm 12y ago
> Functional programming languages shine when they deal with complex, recursive data structures
While I obviously can't comment on the details of the course you took a decade ago, I do have to disagree vehemently with this. OCaml is close to as ideal a systems programming language as I've ever used since:
- it has a simple, stable and predictable runtime with strict evaluation semantics, so you can identify what statements allocate memory by inspecting code.
- the compilation to native code is fast and Unix-like, with standard object files generated that can be linked to and from C programs easily.
- the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted.
- OCaml's basic language features such as algebraic data types and exhaustive pattern matching are fantastic for both building low-level programs, and refactoring them in the future as they inevitably get more complex.
> not for simple tasks which are primarily IO and need to handle many cases.
And this is exactly where libraries like Async or Lwt are so useful, since you can juggle millions of concurrent threads and still do high-level programming without getting lost in the noise. Error monads, failure monitors, function wrappers to ensure resources get freed, can all be built directly within the language itself using the usual ML abstractions, and the compiled code is still lightweight and natively compiled.
For those interested in reading more about the runtime system in OCaml, the entire third part of Real World OCaml is dedicated to this topic: https://realworldocaml.org/v1/en/html/pt03.html https://realworldocaml.org/v1/en/html/pt03.html
- deleted 12y ago[deleted]
- krenoten 12y agoWhat's the current state of parallel execution with OCaml? Historically, I've been attracted to the type system and I think it's generally one of the most beautiful languages out there, but I build things that need to take advantage of many cores at once. Are there now at least nice wrappers around going multi-process like python's multiprocessing library?
- avsm 12y agoThere are a few libraries out there; Async_parallel is one: https://blogs.janestreet.com/async-parallel/ https://blogs.janestreet.com/async-parallel/ Lwt also has the Release framework which does multiprocess: https://github.com/andrenth/release https://github.com/andrenth/release and more if you search through OPAM.
- krenoten 12y agoThanks for the pointers! I'll definitely be playing with these :)
- ihnorton 12y agoNo idea what the current status is, but there is an in-progress branch linked from here: http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/compiler.html#Multicore http://www.cl.cam.ac.uk/projects/ocamllabs/tasks/compiler.ht...
- ptc 12y ago> - the memory representation of values is uniform and native code debugging with gdb/lldb works great, thanks to the DWARF symbols emitted. Besides being able to get a simple backtrace, I've always had nothing but headaches trying to print out variables. It's not tightly integrated with gdb, so the default "p my_ocaml_var" of course doesn't work and info locals rarely if ever works. Only time the debugging is good is when you get to the C code underlying the system calls. I would love for this not to be the case, but I'm not sure if anyone is working on making OCaml better to debug in gdb.
- avsm 12y ago> I'm not sure if anyone is working on making OCaml better to debug in gdb Mark Shinwell is working on just this; he has a very impressive branch of OCaml which can do OCaml-level source backtraces in gdb; WIP tree is here for anyone who wants to glance at the patches: https://github.com/mshinwell/ocaml/compare/ocaml:4.02...4.02-gdb https://github.com/mshinwell/ocaml/compare/ocaml:4.02...4.02... Also a nice talk from a couple of years ago by him on some tips and tricks for using gdb/OCaml: https://www.youtube.com/watch?v=NF2WpWnB-nk https://www.youtube.com/watch?v=NF2WpWnB-nk
- ptc 12y agoThanks for the links, I'll have to take a look at that gdb/OCaml debugging video. Might as well dive into the OCaml internals a bit too. I just really wish OCaml would move to a fully threaded execution model instead of forcing evented systems on everyone.