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

31–40 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#31

Post by contificate »

toolslive wrote: post #16
xyproto wrote: post #14

Earlier quoted context omitted.

I also find it hard to spot why OCaml is the natural "step up" for creating real world applications instead of Haskell, Rust, Clojure or even Kotlin, C++, Python and Go.

let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) ) - OCaml vs Clojure: vastly superior typing system. (=> less bugs) - OCaml vs Kotlin: no JVM needed. - OCaml vs C++: more safety. once it compiles it will not segv. - OCaml vs Go: vastly superior typing system. (=> less bugs) - OCaml vs Python:…

I think the languages you selected in your final remark sum it up for me. If one is truly taken by functional programming, much of their mental model starts to revolve around algebraic (inductively defined) data types and structural recursion (aided by pattern matching) over them - such that mentally reducing the set of candidate languages really does become an implicit process of questioning: "does X have ergonomic, statically-typed, discriminated sums?".

Lots of mainstream languages simply fail this test and make it feel like intellectual poverty or that there's extreme, turgid, boilerplate required for a weak imitation of the features (see the idiomatic class-hierarchy encoding of ADTs in large projects - such as LLVM - in C++, for example).

It's absolutely no surprise that more mainstream languages are picking up a match-like construct and lighter encodings of discriminated sums. So, it really comes to what else you wish to be burdened with when compiling an OCaml-like mental model to X in your head: Tagged unions a-la C? Class hierarchies for ADTs in C++? The travesties of std::variant? Monad transformers in Haskell? Lazy evaluation? No static typing at all? Caring about memory management and ownership? Box and Arc-ing recursive components of ADTs? Writing your own arena allocator? Compiling to the JVM? Spotty TCO support?

OCaml is just a nice, fairly simple (at its core, at least), language that captures the essence of the ML family, compiles to native (and bytecode and, transitively, JavaScript), has great tooling (opam, dune, ocamllex, memhir, etc.), great libraries (official LLVM bindings, for example), and a great community. Lots of OCamlers are well aware of other potential languages that somewhat suit their style of programming, they just don't want to be burdened by the other stuff.

Re: OCaml Programming: Correct and Efficient and Beautiful

#32

Post by pwiecz »

newsoul wrote: post #24
pwiecz wrote: post #22

Earlier quoted context omitted.

Not the original commenter, but my first year course of Introduction of Programming 15 years age was also using OCaml. There were two groups of students, standard one was using Pascal, and the functional one using OCaml. I was studying on Warsaw University and the lecture notes are in Polish: https://mimuw.edu.pl/~kubica/wpf/wpf.pdf

Thanks! 15 years, that's quite a long time ago.

Yup. I really loved all the functional stuff I've learned there from OCaml to SML+Extended ML, to Haskell.

Unfortunately, I haven't had a chance to professionally program functionally since the n. :(

It was all Java and C++. Though I like C++, maybe it's a Stockholm syndrome. ;)

Re: OCaml Programming: Correct and Efficient and Beautiful

#33

Post by octachron »

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…

Do you have a more precise example in mind?

The example that you are describing should emit an error message of the form

    This expression has type type_of_arg_3 -> return_type
    but an expression of   type return_type was expected
which seem alright to me. (But I cannot not be called an OCaml aficionado). The type error might be delayed in sufficiently polymorphism context but that is a more infrequent occurrence (outside of functors whose error messages have been improved in OCaml 4.13 partially for this reason).

Re: OCaml Programming: Correct and Efficient and Beautiful

#34

Post by munchler »

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…

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'

Re: OCaml Programming: Correct and Efficient and Beautiful

#35

Post by bobthechef »

afarviral wrote: post #26
kubb wrote: post #3

My introduction to programming course in my university was in OCaml. It was all downhill from there when it comes to the programming languages I had to use.

Seems its better to start with javascript so you can have the reverse experience.

No post body was provided.

Re: OCaml Programming: Correct and Efficient and Beautiful

#36

Post by shadowgovt »

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…

This mirrors my experience in SML/NJ, where for the longest time the most common error message the compiler would spit out was 'tycon mismatch' and a Google search would not tell you what a tycon was (it's a type constructor).

I think, unfortunately, I've observed a pattern in much functional programming (F# being a blessed exception) that relatively excellent computer language designers suffer from the utter ineptitude of the human language competency of the tool authors. These days, I am far more interested in an elegant tool chain and support infrastructure than an elegant language.

Re: OCaml Programming: Correct and Efficient and Beautiful

#38

Post by toolslive »

throwamon wrote: post #29
toolslive wrote: post #16

Earlier quoted context omitted.

let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) ) - OCaml vs Clojure: vastly superior typing system. (=> less bugs) - OCaml vs Kotlin: no JVM needed. - OCaml vs C++: more safety. once it compiles it will not segv. - OCaml vs Go: vastly superior typing system. (=> less bugs) - OCaml vs Python:…

> 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…

Take any open source python project on github (or others) look at the list of issues and count the number of 'NoneType' has no attribute ... instances. All these could have been avoided by a decent type system. I rest my case ;)

Re: OCaml Programming: Correct and Efficient and Beautiful

#40

Post by shikoba »

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…

> when signatures changed in an unstable dependency

The problem is not OCaml here.

Post reply on HN