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

141–150 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#141

Post by jimbokun »

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…

> Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or variables.

https://www.goodreads.com/en/book/show/594288.Purely_Functio...

Re: OCaml Programming: Correct and Efficient and Beautiful

#142

Post by pjmlp »

sn9 wrote: post #132
pjmlp wrote: post #105

Earlier quoted context omitted.

You will have to wait for JavaScript to add it first. The whole point of Typescript and why it is so successful, is because they only add type system on top of JavaScript. Pattern matching would introduce new language constructs beyond what is required for defining types.

Typescript gets compiled to Javascript anyway. What's stopping any pattern matching construct from being compiled to vanilla JS? We already get stuff like type narrowing and generics.

The philosophy of not adding language constructs beyond what is required for the type system.

Typescript code without type annotations should be JavaScript compatible, minus features still in flight for standardisation.

There are other languages for that like ReasonML.

Re: OCaml Programming: Correct and Efficient and Beautiful

#143

Post by agentultra »

zasdffaa wrote: post #125
agentultra wrote: post #103

Earlier quoted context omitted.

> The optimal implementation might be imperative There are times when it isn't. I'm thinking of Richard Bird's functional pearl, The Smallest Free Number , where the divide-and-conquer algorithm is faster than the imperative one. From the conclusion: One of the differences between a pure functional algorithm designer and a procedural one is that the former does not assume the existence of arrays with a constant-time…

> Yet people are more convinced by imperative implementations I like and use functional and immutable but saying that's best is like saying a screwdriver is better. Sometimes imperative is cleaner. In a video, the creator of Scala, M. Odersky, said Scala allows mutability because sometimes it is cleaner. As an SQL guy, I remember one time a cursor solution was cleanest and best. Scala's librares have some string stuf…

> And it does map so well onto the underlying reality of fundamentally mutable hardware.

It maps well to the abstraction provided by the hardware. In reality we know that modern architectures are executing instructions out-of-order for efficiencies' sake and that data-accesses are not necessarily sequential either. And we haven't even considered multiple-core processors that are so common these days!

As Bird points out in his book, when one looks close enough there are cases where the logarithmic gap between the imperative vs. functional approach disappears.

And further, with register targeting and stuff it's not often true that recursive calls are less efficient than their imperative counterparts anymore... although I suppose historically this could be why, at least for small arrays, imperative programmers could assume constant-time indexing and updating.

I'm not nearly as versed in functional programming as I'd like to be. I was raised on C and algorithms were always described in terms of procedures to me where the proofs took quite a bit of work to follow. However as I learn more about algorithm design in functional programming and functional data structures I can't help but notice that the proofs are much easier to follow while sometimes the solution seems quite alien and I wonder if that's because of my heritage of thinking operationally rather than by calculation. I've often been surprised to learn that many of my assumptions about the logarithmic complexity of functional algorithms are not always there!

Re: OCaml Programming: Correct and Efficient and Beautiful

#144

Post by raverbashing »

toolslive wrote: post #139
raverbashing wrote: post #126

Earlier quoted context omitted.

> Note how OCaml is flexible about whether you write the parentheses or not, and whether you write whitespace or not. from here https://cs3110.github.io/textbook/chapters/basics/toplevel.h...

isn't that the case in most programming languages ? In essence, if you have an expression exp then (exp) is also an expression. So nothing special about OCaml in that regard. [note, just checked python, php, and js and it is the case]

Ok so maybe the example is confusing, because it seemed it was talking about function calls (where they are mandatory in the languages you mentioned)

Re: OCaml Programming: Correct and Efficient and Beautiful

#145

Post by akhmatova »

yawaramin wrote: post #129
water8 wrote: post #21

Earlier quoted context omitted.

OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.

If Jane Street can teach OCaml to traders, I can teach it to developers. That's not a concern for anyone other than a sweatshop.

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't be.

Re: OCaml Programming: Correct and Efficient and Beautiful

#146

Post by wyager »

octachron wrote: post #113
wyager wrote: post #98

Earlier quoted context omitted.

> OCaml does not require more annotations than Haskell for polymorphic functions? A) I am fairly confident this is not actually true in a technical sense, although it's been several years since I've thought about it B) In any case, in the (many) instances where you (by rule or convention) need to put a type signature on your function (e.g. because it's a top-level function, one that you export, etc.), it is a pain in…

Do you have any examples? Unfortunately from my perspective, I cannot make sense of your statements. OCaml typing is principal in all situation where type inference is decidable. The syntax for annotation for polymorphic functions is isomorphic between OCaml and Haskell. If I take a random module in the standard library, let's say Array, 95% of the functions in this module are parametric polymorphic. I am thus genuin…

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 random module in the standard library, let's say Array

As I specifically called out, all the core data structures are polymorphic. (Let's not talk about the float array hack; is that still around?)

It's so annoying that pretty much every other library is monomorphic or functorized.

> I am thus genuinely puzzled by your statement that "OCaml programmers almost never write polymorphic functions".

Not sure what to tell you man. I spent 4 years reading & writing ocaml and 95% of the code that would have been polymorphic in haskell (because it would be easy/free) was either monomorphic or (multiple layers of) functors. Many/most of the devs I worked with (great devs with years of OCaml experience) didn't even know what LATs were, let alone used them, which means they were almost certainly not writing polymorphic code which "did anything" with the type. The only polymorphic code that you can write in ocaml without such things are functorial (in the categorical sense, not the ocaml sense). Arrays, map values, that's about it.

Re: OCaml Programming: Correct and Efficient and Beautiful

#147

Post by wyager »

substation13 wrote: post #127
wyager wrote: post #96

Earlier quoted context omitted.

Strong disagree; I have thousands of hours with both and I would essentially never recommend ocaml over haskell unless your company already has an ocaml codebase/ocaml expert employees. I'm very conscious of the existence of pareto tradeoffs; I am asserting that, in this case, there is essentially no tradeoff to be made. Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For doma…

What about the performance challenges caused by lazy evaluation?

People fixate on this, and all I can say is

* it has never been an issue for me

* I don't think the performance implications are nearly as hard to understand as often implied

* in the extreme you can just enable the STRICT language pragma in your project and forget about it :)

Re: OCaml Programming: Correct and Efficient and Beautiful

#148

Post by c-cube »

shikoba wrote: post #109
muglug wrote: post #48

Earlier quoted context omitted.

I have a good point of contrast: I'm doing a similar task with an unstable Rust dependency, and when APIs change the error messages from the typechecker are crystal clear about why things are incompatible.

I see, you made the beginner mistake with OCaml. You should never read the OCaml error message except if all other options failed. Try to not read those messages, but just look at the line where the error occured. You can use -annot or -bin-annot when compiling and the Tuareg function caml-types-show-type in Emacs will be your best friend.

This is old advice :-). Use the LSP server and dune and the error displays instantly, no further setup required.

Re: OCaml Programming: Correct and Efficient and Beautiful

#149

Post by yuppiemephisto »

jimbokun wrote: post #141
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…

> Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or variables. https://www.goodreads.com/en/book/show/594288.Purely_Functio...

Have you read the book and implemented its algorithms?

Re: OCaml Programming: Correct and Efficient and Beautiful

#150

Post by acchow »

muglug wrote: post #45
munchler wrote: post #34

Earlier quoted context omitted.

FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'

yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.

Stockholm syndrome arrives quite quick in this case, as you become accustomed to this form as meaning "you're missing an arg"

I agree the first 6 months of this is mind-numbingly frustrating.

Post reply on HN