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

81–90 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#81

Post by toolslive »

twh270 wrote: post #60
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:…

Not sure what you mean by "- OCaml vs Kotlin: no JVM needed." as Kotlin has support for native and JavaScript compilation, and WASM via native.

so it's either a JVM or either no libraries?

Re: OCaml Programming: Correct and Efficient and Beautiful

#82

Post by 0x69420 »

toastal wrote: post #53
zaptrem wrote: post #50

I took this class last semester. Michael Clarkson is an awesome professor. After learning OCaml I want pattern matching in JavaScript! Beyond the language itself, it absolutely made me a better programmer.

Pattern matching without ADTs though loses a lot of the power. The fact that you'd still have to handle null/undefined cases means it's still annoying to use and hardly exhaustive.

erlang/elixir programmers would disagree -- we match on ad-hoc dynamically typed tuples that serve broadly the same purpose as ADTs all the time, where the only exhaustiveness you get is the degenerate case ie `_ -> shit_the_bed()`

especially common are pattern-matching assignments (technically `=` is the “match operator”) that idiomatically behave much like matches on the left hand side of `these communicate programmer intent really well! you could probably have them in static land in a non-`monadFail` context too, but you'd want dependent types or something lest you go the way of typescript and resign yourself to unsoundness

in fact it's so nice that i feel pain in any dynamic language without full-fat pattern matching, like when i have to write disgusting if-else chains in complex nix expressions

Re: OCaml Programming: Correct and Efficient and Beautiful

#83

Post by haskellandchill »

blackerby wrote: post #49

A quick scroll through the comments and it looks like no one is actually talking about the book itself, so I will. I came across it at a really good time in my computer science self education. It helped me learn about some essential data structures and algorithmic analysis. The video lectures interspersed in the text augment the text and vice versa. The sections without videos were tougher for me to digest, but are w…

I'm enjoying the discussion of commutative diagrams, abstraction functions, and representation invariants in section 6.3. It is very well motivated and easy to understand.

Re: OCaml Programming: Correct and Efficient and Beautiful

#84

Post by raverbashing »

"beautiful"

But then it has quirks like using ;; to end statements (EDIT: only in the REPL). And comments with that weird syntax

But worse of all are the optional parenthesis in function calls. Yes, I know Ruby has it. But it feel super weird and a needless flexibility (that causes more confusion than it solves).

I can't get over this stuff, sorry.

Re: OCaml Programming: Correct and Efficient and Beautiful

#85

Post by substation13 »

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…

> Functional programming with immutable values is a wrong pattern for programming languages. Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or variables.

The optimal implementation might be imperative but that doesn't mean we need to define our code that way. SQL is a good example here.

Re: OCaml Programming: Correct and Efficient and Beautiful

#86

Post by baby »

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…

Btw you can actually write loops and mutate things with the ref keyword. It’s usually much clearer than writing a loop recursively but not everyone uses it.

The impossibility to return early in a function does create really convoluted code though. I’m wondering if there’s a solution to that in FL

Re: OCaml Programming: Correct and Efficient and Beautiful

#87

Post by cdaringe »

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…

I’m with octaron on this one. No disrespect, but a bit of hand waving and big claims.

I’m kindly invoking Hitchens razor, here

Re: OCaml Programming: Correct and Efficient and Beautiful

#88

Post by darthrupert »

tgflynn wrote: post #68
water8 wrote: post #20

Quoted post unavailable.

> It has no performance or coding benefit for teams larger than a few. That must be why Jane Street uses it then.

And pretty much only them.

Perhaps some day we'll learn how little the programming language matters for anything beyond coding.

Re: OCaml Programming: Correct and Efficient and Beautiful

#89

Post by ahmedalsudani »

muglug wrote: post #78
abathologist wrote: post #62

Earlier quoted context omitted.

Looks like that is exactly the error message predicted. It’s expecting a list of result values, but is getting a list of functions from some stuff to that result. IME, it’s definitely true that OCaml doesn’t have the didactic error messages that many have come to like in Rust et al. They said, imo they generally give the information needed solve problems and I like their concision. It takes a bit of time to learn to…

> It takes a bit of time to learn to read [OCaml's error messages] Yeah, and I think you could say the same of Rust when it comes to the borrow checker's messages. But in Rust's case the problem it's trying to describe is itself pretty complex. The complexity of OCaml's error messages are really not justified by the problem they're warning you about, which is itself very straight-forward.

The ML languages started appearing in the 70s. Rust is a very modern language.

Where do you think rust got (more than) half of its type inspiration from?

Either way no one has to use any language. Personally OCaml is not my cup of tea--Haskell is. But it is a great tool and it's solving hard problems.

Re: OCaml Programming: Correct and Efficient and Beautiful

#90

Post by throwaway894345 »

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…

I generally agree, and I'm hoping that Gleam fits the bill for "Rust with garbage collector" (also, when I say this, people leap to OCaml, but OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax, lower quality build tooling, unbounded type inference, competing "standard" libraries, a fairly toxic community, etc).
Post reply on HN