Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

Post reply on HN
Print view View original

181–190 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#181

Post by earth_walker »

kupopuffs wrote: post #159
muglug wrote: post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

Forgive my ignorance, I'd would like an example of the "functional" (hehe) benefits of automatic currying

Partial application and function composition are the meat-and-potatoes of functional programming.

Automatic currying is syntactic sugar that can make these two easier and clearer as it gets rid of a bunch of named arguments and lambdas. For example, I can write:

  foo a b c = a * b + c
I can then apply this partially like this (foo2 just takes argument c):

  foo2 = foo 10 20
and compose it with other functions, for example like this:

  composed = foo2 >> bar >> baz
Without currying, you'd have something like:

  foo (a, b, c) = a * b + c 

  foo2 (z) = foo (10, 20, z)

  composed (a) = (\b -> foo2 (b)) ((\c -> bar (c)) (baz (a)))

Re: OCaml Programming: Correct and Efficient and Beautiful

#182

Post by wyager »

octachron wrote: post #153
wyager wrote: post #146

Earlier quoted context omitted.

I wrote up a bunch of grievance examples for a blog post I never got around to publishing, but I'm traveling at the moment so can't pull up my laptop. I'll see if I can find them later. > The syntax for annotation for polymorphic functions is isomorphic between OCaml and Haskell. Sorry, but total bullshit. I had to use these pieces of shit all the time. https://v2.ocaml.org/manual/locallyabstract.html > If I take a r…

> Sorry, but total bullshit. Ok, locally abstract types are bit weird and historical quirk due to the pre-existing use of type variables as unification type variables. But first, they only matter with GADTs and local modules (a notion that doesn't exist in Haskell). And the good syntax for polymorphic function with GADTs is `type a. a monoid -> a` which requires just one explicit quantification compared to the Haskel…

> they only matter with GADTs and local modules

Local modules (assuming this means e.g. a module passed in as a function argument, constrained to have one of its types match the type of another argument) are how you write non-trivial polymorphic code.

> Atomic ... CCPair

More functors (in haskell terminology) - code that doesn't do anything interesting with the type parameter.

> What do you mean by LAT

Locally abstract type

> I am sorry to ask but are you confusing bounded polymorphism with parametric polymorphism?

Bounded polymorphism is an application of parametric polymorphism. Not sure what you are asking here. Possibly this will clarify my line of thought: I consider parametrically polymorphic code without any bounds to be "uninteresting"/"trivial", because either the code must treat the polymorphic type completely opaquely (leading to trivial functorial [in the haskell sense] operations like implementing fmap), or requiring you to explicitly pass in all supported operations on the instantiated type (basically requiring you to implement bounding by hand).

I think this may be a blub paradox thing, where the set of useful applications of PP is much more restricted in ocaml, to the point where ocamlers do not even consider what they are missing. A haskell or rust programmer would likely run into these semantic blocks quickly upon trying ocaml.

Re: OCaml Programming: Correct and Efficient and Beautiful

#183

Post by pharmakom »

tgflynn wrote: post #56
throwamon wrote: post #29

Earlier quoted context omitted.

> vastly superior typing system. (=> less bugs) I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature…

I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.

I think the big win is actually immutable data and pure functions. It just so happens that strong typing tends to come along with these things (e.g. Haskell, OCaml)

Re: OCaml Programming: Correct and Efficient and Beautiful

#184

Post by int_19h »

muglug wrote: post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

A big part of it is that currying is idiomatic, which, I think, is a design mistake that most functional languages carry as a historical baggage. But multi-argument functions can just as well be represented as functions of tuples, even in OCaml (and, if I remember correctly, it is idiomatic in SML), and then you get a proper error message about the type of argument rather than the result.

Re: OCaml Programming: Correct and Efficient and Beautiful

#185

Post by octachron »

wyager wrote: post #182
octachron wrote: post #153

Earlier quoted context omitted.

> Sorry, but total bullshit. Ok, locally abstract types are bit weird and historical quirk due to the pre-existing use of type variables as unification type variables. But first, they only matter with GADTs and local modules (a notion that doesn't exist in Haskell). And the good syntax for polymorphic function with GADTs is `type a. a monoid -> a` which requires just one explicit quantification compared to the Haskel…

> they only matter with GADTs and local modules Local modules (assuming this means e.g. a module passed in as a function argument, constrained to have one of its types match the type of another argument) are how you write non-trivial polymorphic code. > Atomic ... CCPair More functors (in haskell terminology) - code that doesn't do anything interesting with the type parameter. > What do you mean by LAT Locally abstra…

Ok, you are using "parametric polymorphism" to mean bounded polymorphism. This explain my confusion! Indeed, I can understand your point of view then: bounded polymorphism is indeed better done with functors in OCaml. And since functor are syntactically heavy in OCaml there are not used everywhere and only when they are useful. Which doesn't mean that they are not used at all, as the Mirage project can attest. MirageOS is essentially an Operating System build upon OCaml functors.

Re: OCaml Programming: Correct and Efficient and Beautiful

#186

Post by wyager »

octachron wrote: post #185
wyager wrote: post #182

Earlier quoted context omitted.

> they only matter with GADTs and local modules Local modules (assuming this means e.g. a module passed in as a function argument, constrained to have one of its types match the type of another argument) are how you write non-trivial polymorphic code. > Atomic ... CCPair More functors (in haskell terminology) - code that doesn't do anything interesting with the type parameter. > What do you mean by LAT Locally abstra…

Ok, you are using "parametric polymorphism" to mean bounded polymorphism. This explain my confusion! Indeed, I can understand your point of view then: bounded polymorphism is indeed better done with functors in OCaml. And since functor are syntactically heavy in OCaml there are not used everywhere and only when they are useful. Which doesn't mean that they are not used at all, as the Mirage project can attest. Mirage…

I don't really consider those separate things. Bounded polymorphism is parametric polymorphism, plus a type subset relationship. A quick sanity check on wikipedia is consistent with this model. BP is PP plus what's required to make it more than a toy

I remember one annoyance I had with ocaml was the effective inability to use point-free style. I can't remember what limitation was behind this; do you know off the top of your head?

Edit: it's the "value restriction", more annoying bullshit I forgot about! Huge limitation for polymorphic ocaml code.

Re: OCaml Programming: Correct and Efficient and Beautiful

#187

Post by int_19h »

throwaway894345 wrote: post #121
kitd wrote: post #118

Earlier quoted context omitted.

> OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax ... Hmm, I think "cryptic syntax" is probably in the eye of the beholder

I'm sure there's some element of subjectivity, but at a minimum there's something to be said for "unfamiliar to the overwhelming majority of programmers". I think it's also very likely that OCaml's incredibly terse syntax (and terse naming conventions) is objectively difficult to understand from a "how the human visual/symbolic processing pipeline works" perspective, but I don't have the data to back that up (I also…

Thing is, if OCaml is terse and weird syntactically (and I would agree), then so is Rust. Especially once you have to spell out signatures.

Re: OCaml Programming: Correct and Efficient and Beautiful

#188

Post by int_19h »

frankohn wrote: post #69

As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…

Ironically, I find the OOP part of OCaml to be the most interesting, seeing how it manages to provide a self-consistent and powerful structurally typed object model that is no less powerful than what you get in C++, for example.

Re: OCaml Programming: Correct and Efficient and Beautiful

#190

Post by akhmatova »

yawaramin wrote: post #175
akhmatova wrote: post #145

Earlier quoted context omitted.

If Jane Street can teach OCaml to traders, I can teach it to developers. You can if they are motivated to learn. Unless you are offering Jane Street levels of compensation; and in return, the candidate is willing to believe, or pretend to believe that company's shtick about OCaml being so categorically superior as a general-purpose development language so as to leave all the others in the dust -- most likely they won…

Or if, you know, they were hired to work on a project where they get paid a salary. That seems to incentivize most devs.

Not "a salary", but a Jane Street salary and resume cred. Otherwise you just won't find that many takers.
Post reply on HN