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…
OCaml Programming: Correct and Efficient and Beautiful
131–140 of 251 posts
Re: OCaml Programming: Correct and Efficient and Beautiful
#132Earlier 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.
We already get stuff like type narrowing and generics.
Re: OCaml Programming: Correct and Efficient and Beautiful
#133Re: OCaml Programming: Correct and Efficient and Beautiful
#134Re: OCaml Programming: Correct and Efficient and Beautiful
#135Earlier 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.
Re: OCaml Programming: Correct and Efficient and Beautiful
#136Earlier 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…
Re: OCaml Programming: Correct and Efficient and Beautiful
#137Earlier 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.
Re: OCaml Programming: Correct and Efficient and Beautiful
#138Earlier 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?
Re: OCaml Programming: Correct and Efficient and Beautiful
#139Earlier 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...
Re: OCaml Programming: Correct and Efficient and Beautiful
#140Earlier 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?
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]