[deleted]
Real World OCaml
41–50 of 83 posts
Re: Real World OCaml
#42Ocaml: Love the language, but I don't think I've seen a worse standard library. I don't mean that it's sparse -- I don't mind that so much. I mean that it's really just badly designed. For example, global, mutable variables in a functional language? Really? Thankfully, Jane Street and the Batteries Included projects are supplementing it, but I'm still of the opinion that the standard library should be torn out and re…
It's important to remember that the standard library is the compiler standard library . It's actually very useful to have it be so minimal when compiling OCaml to odd embedded and microkernel targets (such as our own MirageOS at https://openmirage.org ). We took an explicit decision not to use the compiler standard library in Real World OCaml, and instead work using the Core stdlib from Jane Street. I think it's quit…
Even if you don't use / plan to use the Core stdlib, the book is quite useful.
Re: Real World OCaml
#43Crazy coincidence; I just met someone who works at Jane Street on Saturday. My jaw pretty much dropped when he told me what his company does. When I got home and did some research, I was blown away by their dedication. I'm very happy to see a company realize the value in their language ecosystem and contribute as much back as they have.
Re: Real World OCaml
#44Earlier quoted context omitted.
Having used fork/join to parallelize an OCaml genetic algorithm, I can say from experience it is neither safe nor practical. Edit: Intentionally only supporting single-threaded processes is a perfectly fine design decision, however I haven't seen this argument made for OCaml, rather I've seen "multi-threading our GC would be hard" as the justification for the single-thread limitation. Admittedly it was 3-4 years ago…
There are now several experimental multithreaded OCaml runtimes floating around, which also have the key property of not slowing down the single-threaded case. I don't expect multicore to remain a limitation for OCaml in 2014.
My impression was that the core team was actively opposed to adding parallelism support. Has this changed?
Re: Real World OCaml
#45For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tutorial.fdoc It is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ code and has coroutines baked in. Its own demo webserver is based on coroutines. It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Exec…
I had a look at it and it sounded pretty cool. The one thing I found unfortunate is the lack of separation between safe and unsafe code, but it certainly has a lot going for it.
Re: Real World OCaml
#46Ocaml: Love the language, but I don't think I've seen a worse standard library. I don't mean that it's sparse -- I don't mind that so much. I mean that it's really just badly designed. For example, global, mutable variables in a functional language? Really? Thankfully, Jane Street and the Batteries Included projects are supplementing it, but I'm still of the opinion that the standard library should be torn out and re…
I was pretty impressed with how a single `open Core.Std` line you can basically do the whole "tear out the standard library and replace with something nice" on a per-module basis. Unfortunately it has the side-effect of making small native binaries impossible, but depending on the project it's nice to have the choice.
> has the side-effect of making small native binaries impossible
fear not; support for module aliases in signatures will resolve that problem quite soon, and quite elegantly too.
Re: Real World OCaml
#47Where is OCaml's place in the current world? I find it interesting as it seems to generate little "buzz", but has two new books this year, and is a pre-cursor to another functional language that itself seems to be gaining traction, and is yet produced my Microsoft: F# My observational / untested impression is OCaml seems to be more practical, and maybe a little easier to transition to for someone like me who uses mos…
A major limiting factor is that OCaml has no support for parallelism, and due to it's use of a global interpreter lock for GC it can't run multiple threads. That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.
That's a feature not a bug; it would slow down Coq is the reason.
Re: Real World OCaml
#48In my progression of Haskell-OCaml-Common Lisp-Clojure-Scala, I remember OCaml having odd edge cases, modules of functors or some such that didn't really help me in solving real world problems (this was 2007-2008 so my memory could be off). I'm currently a fan of Scala, which has all the functional and Algebraic Data Type goodness I remember from OCaml but is more "practical", more companies and projects are using it…
It depends on what you are working on. OCaml lets you interact more closely with Unix and with C libraries, if you need that. It also has a lot faster startup time and lower memory overhead, making it somewhat more suitable for writing Unix-style programs that need to run quickly with low overhead. I also moved from OCaml to Scala for my primary programming, and have really enjoyed it. The functional goodness on top…
Once you get used to OCaml's type inference that just works, Scala seems a bit clunky.
Re: Real World OCaml
#49For the early adopters and experimenters amongst you, you might like Felix http://felix-lang.org/share/src/web/tutorial.fdoc It is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ code and has coroutines baked in. Its own demo webserver is based on coroutines. It uses a mix of lazy and eager evaluation for performance and compiles down to C++. Exec…
I had a look at it and it sounded pretty cool. The one thing I found unfortunate is the lack of separation between safe and unsafe code, but it certainly has a lot going for it.
Yeah, that is D's strength, that and compile time function execution.
Re: Real World OCaml
#50Where is OCaml's place in the current world? I find it interesting as it seems to generate little "buzz", but has two new books this year, and is a pre-cursor to another functional language that itself seems to be gaining traction, and is yet produced my Microsoft: F# My observational / untested impression is OCaml seems to be more practical, and maybe a little easier to transition to for someone like me who uses mos…
If you want to use a functional language on Unix, _and_ have a type system, _and_ avoid JVM/.Net then you don't have many choices. There is Haskell of course, but it is lazy by default, which makes it harder to reason about how your program will execute, and how much space it'll use. Rust is something interesting to keep an eye on, but AFAIK it is not ready yet for production use. Hence I prefer OCaml.
Why OCaml over ML?