Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

131–140 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#131
post #59

This is a very specific question but I thought I'd ask it here on the chance someone might have a good answer. I've been slowly working my way through this course and I ran into an issue recently when I upgraded my OCaml installation to the latest version (4.13.1). With this version I find that the simple instructions for building an executable with dune (especially one that uses OUnit) given here https://cs3110.gith…

FYI: If you have more questions, the OCaml forum is very friendly and helpful: https://discuss.ocaml.org/

Re: OCaml Programming: Correct and Efficient and Beautiful

#132
post #105
post #44

Earlier quoted context omitted.

Nope, I must say I have only used a small subset of languages from the FP-language-zoo, so my opinion on OCaml might be biased But as an example when writing Typescript, I feel so frustrated of not having a clean way of doing pattern-matching

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#133
post #41

Earlier quoted context omitted.

Hey, it's not a feeling. It's a fact.

It is certainly a fact, that you feel superior. I would like to confirm that fact, by comparing productive output..

Define "productive output".

Re: OCaml Programming: Correct and Efficient and Beautiful

#135
post #60

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.

Did you even try it? It still requires Java, Gradle and Kotlin compiler to work. Also, good luck making it work without using Intellij.

Re: OCaml Programming: Correct and Efficient and Beautiful

#136

Earlier quoted context omitted.

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

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

Ideally I would write my code in a declarative way and the compiler would figure it out. Second to that, the language can allow interior mutability so I can optimize.

Re: OCaml Programming: Correct and Efficient and Beautiful

#137
post #93
post #56

Earlier quoted context omitted.

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.

This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dyn... . I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.

I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.

Re: OCaml Programming: Correct and Efficient and Beautiful

#138
post #18

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

What about Swift?

On the server, less ecosystem than OCaml. Long compile times. A big part of its "market share" is taken by Rust instead.

Re: OCaml Programming: Correct and Efficient and Beautiful

#139

Earlier quoted context omitted.

> worst of all are the optional parenthesis in function calls ?? > let r = some_function x y z in ... There are no parentheses here, and it's not optional. What you probably are missing is that if `some_function` takes 3 arguments, then `some_function x y` is a function value that takes 1 parameter (currying). Btw, iirc, SML doesn't have this: there you only have 1 parameter but it could be a tuple

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

Re: OCaml Programming: Correct and Efficient and Beautiful

#140
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?

Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure.

In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files.

    Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages.

    slow =  
      let  files = mapM makeAndReadFile [1..500] ::  IO  [ String ]     
      in  files >>= (putStrLn . show)


    Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand.

    safe ::  IO  ()  safe =    
    foldl ( \ io id ->   io >> makeAndShow id  ) (return ()) [1..500]
Post reply on HN