21–30 of 84 posts
If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.
If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.
OCaml is a bit more traditional. Strict evaluation and mutability may be more friendly to programmers with an imperative background. My general experience with OCaml hasn't been great. To be blunt, it seems sort of like a less-well-thought-out version of Haskell. The biggest downsides that I remember were: * IO sequencing via (;) : () -> () -> (). This is sort of a relic from before we had monads, and is relatively p…
Earlier quoted context omitted.
> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also…
What if I want some hybrid? From OCaml, I want the awesome module system and strictness by default. (I'm not dismissing laziness or any other evaluation strategy - just saying strictness is a better default.) From Haskell, I want effects tracked in types, higher-kinded types and painless parallelism.
Earlier quoted context omitted.
> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also…
"- you want a build system that doesn't suck" This is a very surprising claim. Do you have any examples how Ocaml specifically induces systems built on it to suck?
And here is the pending effort for better experience of OCaml on Windows: https://github.com/ocaml/opam/issues/2191
Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being able to just write `show x` is so nice!
Edit: while I often see "modular implicits are being worked on" it is not very clear whether there is a concrete plan to add them to the language. Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status?
And here is the pending effort for better experience of OCaml on Windows: https://github.com/ocaml/opam/issues/2191
For me, this has been the central issue for not moving many of my projects to OCaml. OPAM sort of works on Windows, but most of the packages I tried to pull broke and fixing them was difficult. Making OPAM work seamlessly on Windows would be a big win in my opinion.
The packages that I needed and that didn't compile in the standard repository were working thanks to patches applied in his repository.
Also, the maintainer was very prompt and helpful when dealing with my pull request.
There are other forks of that repository, but when googling for "opam windows" they do not appear on the first page, which is unfortunate since they seem to me the best currently available option.
Earlier quoted context omitted.
> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also…
What if I want some hybrid? From OCaml, I want the awesome module system and strictness by default. (I'm not dismissing laziness or any other evaluation strategy - just saying strictness is a better default.) From Haskell, I want effects tracked in types, higher-kinded types and painless parallelism.
If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.
Its easy to write imperative code in OCaml. OCaml also has a class system. These two points make transition from languages such as Python, Java... easier.
Java programmers would be confused the most, because they would have to unlearn the most. In Java, a class is a type on its own right. An object of class (and, hence, type) `Foo` has a very specific data structure, even if this data structure is unknown to the user. On the other hand, in OCaml, a class is just a constructor for objects of a particular structural type. Two objects with the same structural type can have completely different underlying data structures. Making things even more confusing, inheritance doesn't entail subtyping - a class `foo` can inherit from a class `bar`, without `foo`'s type being a subtype of `bar`'s type. This happens if `bar`'s type contains negative occurences of its self-type. As a result, few intuitions about Java's class system carry over to OCaml.
Python programmers would be somewhat less surprised, but if their idea of a typed object-oriented language is “something that looks like Java”, they could encounter all the difficulties mentioned in the preceding paragraph. On the other hand, if they have no experience at all with typed languages, OCaml's class system can still be a source of pain, in that inferred object types can be utterly incomprehensible for someone not familiar with how the type checker works. By contrast, the inferred type signatures for the non-object-oriented subset of OCaml are usually very tame.
---
Sorry, e_d_g_a_r, I can't reply to you directly, because the website says I'm “submitting too fast”, but here is an example: http://pastebin.com/yUmNnFD5 . By the way, this isn't a bug in OCaml's type checker - it's the way it's supposed to work.
Earlier quoted context omitted.
What if I want some hybrid? From OCaml, I want the awesome module system and strictness by default. (I'm not dismissing laziness or any other evaluation strategy - just saying strictness is a better default.) From Haskell, I want effects tracked in types, higher-kinded types and painless parallelism.
There's one language I know that gives nearly all of those things, which is Ur (of the ur/web framework fame). Modules, type classes, eager evaluation, HKTs. It even adds features that aren't in either language such as first-class records and row polymorphism, type-level programming, macros and probably more. It's apparently very high performance, and even has a nice C FFI. The major downside is that it's only meant…