11 ms·
OCaml looks really good, I've heard good things about it for awhile now. I'd like to learn more but and currently learning Haskell and want to focus on learning
by Buttons840 13y ago
OCaml looks really good, I've heard good things about it for awhile now. I'd like to learn more but and currently learning Haskell and want to focus on learning that for awhile.
Does anyone know why OCaml gets compared to Haskell so often? It sounds like OCaml doesn't force a purely functional paradigm on you, so how is it any more functional that a number of good scripting languages (Python, Ruby, Peal, etc)?
- e12e 13y ago> Does anyone know why OCaml gets compared to Haskell so often? I seem to recall (incorrectly, apparently) that there is a common thread going back to Standard ML for both OCaml and Haskell. Appears, Haskell goes back to Miranda which borrows from SML -- but it's not entirely incorrect to say that both OCaml and Haskell are built on the shoulders of SML. My take is that OCaml was seen as a way to make a "useful" MetaLanguage, fit for more than experimental language implementations -- while Haskell was conceived by some crazy people that didn't think it was hard enough to get any useful work done in SML ;-) Now, Haskell has evolved into something that actually is useful, and the biggest difference AFAIK is that Haskell leans towards strict and lazy than OCaml. As they are both "modern" MLs, it's natural to compare them -- why Haskell isn't compared more often to SML might just be that there are a few programs actually written in OCaml that people are aware of ;-)
- MonkeyIsNull 13y agoBoth are descended from ML, but have found a lot more "RealWorld" usage than ML. If you know ML it makes it a lot easier to learn Haskell or OCaml.
- chc 13y agoOCaml is not strictly pure, but it is definitely more strongly functional than Python or Perl. What matters is not that a language completely disallows mutation so much as that it helps you write in a functional style. The functional path is usually the happy path in OCaml, whereas in Ruby mutation and statefulness just come naturally. The basis of OCaml is functions that transform one thing into another. The basis of Ruby is objects that encapsulate some state and send messages to other objects to get them to change their state.
- mrbrowning 13y agoDoes OCaml do any sort of structural sharing behind the scenes? This is always the thing that bothers me about the functional JavaScript movement, since mutable state everywhere makes such sharing infeasible, meaning that I have to worry a lot more about space complexity when I'm doing something like a map over a collection. How does OCaml fare in that regard?
- gsg 13y agoSharing is both common and expected, as it arises naturally as a result of writing functions over variants. The language also provides an identity test (==) by which sharing can be observed, so it can't be said to be "behind the scenes". Several of the data structures in the stdlib make good use of sharing to reduce the cost of operations - Set.union is a particularly good example. map, however, is not the sort of operation that leads to sharing.
- tel 13y agoOCaml has a similar type system to Haskell's. It has algebraic data types. It also has all the normal higher order functions and combinators "done right". It also commits strongly to using first class modules as an organizational component atop the functional core. I don't think "functional" means a whole lot. Many languages with lightweight, first-class lambdas like to jump on that bandwagon by implementing map/fold/scan/take combinators on lists, sometimes even lazy ones, but that whole game is just a sideshow to the real meat of what makes Hindley-Milner typed languages with ADTs quite fun to work in.
- andreasvc 13y agoHM type inference is one possible aspect of functional programming, but there's also the Lisp family of languages which are characterized by macros and homoiconicity, as opposed to purity and static typing. Functional programming doesn't seem to have a single definition, but the languages do share a family resemblance: instead of one or more properties shared by all members, each pair of members shares some properties.
- tel 13y agoI'm more in the camp that "functional" is just too much an umbrella term to mean much. I think it's completely fair to say that anything with light syntax for lambdas and the regular "list combinator zoo" of (map/fold/zip/unfold/scan/take) is "functional" enough for me. All the other features are orthogonal and specialized.
- seanmcdirmid 13y agoHindley-Milner is fun until you need nominal subtyping or mutable assignment, then the whole "semi-unification is undecidable in general" comes up to bite you.
- tel 13y agoHow does HM get in the way of mutable assignment?
- nousernamesleft 13y agoTwo reasons. First, they are both languages with useful type systems. There's not many languages in that group. Second, ocaml is a multiparadigm language for real, and with a focus of functional first. Python, ruby, perl, etc are procedural/OO languages that have map and filter. It is a huge pain and tons of extra code to write a program in functional style in python, it is lacking basically everything. It is normal to write a program in a functional style in ocaml. If you learn haskell first, ocaml will serve no purpose for you. But for someone coming from imperative land, learning ocaml can be a helpful half-way house on the way to haskell.
- silentOpen 13y agoAs always, it depends on the job. For some systems, OCaml is superior; for others, Haskell is superior. One big question informing the choice is "do I want to program primarily lazily or primarily eagerly?" Another is "is time to achieve system performance a big factor in success?" If eager, performance-eager -> Ocaml If lazy, performance-lazy -> Haskell
- nousernamesleft 13y agoHaving spent 6 years with ocaml, I can honestly say I both never wrote anything where ocaml offered a benefit haskell does not, and can not even think of such a program. You pose two questions, one of which is effectively irrelevant, and the other I believe is based on an incorrect assumption. Maybe 5% of code the evaluation strategy matters. It makes no difference whether you are adding strictness for 2% of your code or adding laziness for 2% of your code. The performance question I think is a misconception. Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors. Ocaml offers two things over haskell. One, imperative constructs. This matters for people making a transition to functional programming, but not for people who've finished that transition. Second, the compiler is fast. I don't mean generates fast code, ghc does that too. I mean it generates code quickly. This is an annoyance with ghc, no question. Haskell offers a lot over ocaml. A useful standard library. Cabal and hackage. Parallelism done right, out of the box (super cheap green threads multiplexed over a pool of OS threads). Tons of libraries that don't exist in ocaml, everywhere from attoparsec and aeson, to binary and lenses, pipes-concurrency and STM. A community that is ten times the size of ocaml's. There are good reasons it has gone from ocaml having the larger community to haskell dwarfing ocaml in community size, language usage, library availability, etc. in the last decade.
- pjmlp 13y ago> Does anyone know why OCaml gets compared to Haskell so often? Because both belong to the ML family branch of programming languages.