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

121–130 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#121

Post by throwaway894345 »

kitd wrote: post #118
throwaway894345 wrote: post #90

Earlier quoted context omitted.

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

> OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax ... Hmm, I think "cryptic syntax" is probably in the eye of the beholder

I'm sure there's some element of subjectivity, but at a minimum there's something to be said for "unfamiliar to the overwhelming majority of programmers". I think it's also very likely that OCaml's incredibly terse syntax (and terse naming conventions) is objectively difficult to understand from a "how the human visual/symbolic processing pipeline works" perspective, but I don't have the data to back that up (I also don't think OCaml is alone in this regard).

Re: OCaml Programming: Correct and Efficient and Beautiful

#122

Post by the_duke »

kaba0 wrote: post #119
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…

There are two ways to improve performance of a given program. You either go lower level, giving more control over the execution and specifying what you want exactly, or you go higher , not constraining the execution as much, allowing for better optimizations. For example a manual for loop will almost always be harder to optimize than a map. The latter gives explicit permission for reordering, allowing for vectorizati…

> modern CPUs employ just as much FPism

Do you have some references where I could learn more about that?

Re: OCaml Programming: Correct and Efficient and Beautiful

#123

Post by octachron »

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

You can add a dune-project file at the root of your project with just `(lang dune 3.2)` (or your dune version rather than 3.2). The file can also be generated by "dune init project project_name" for fresh projects.

Re: OCaml Programming: Correct and Efficient and Beautiful

#124

Post by throwaway17_17 »

agentultra wrote: post #103
substation13 wrote: post #85

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…

I tend to believe that there is an issue of map/territory confusion in teaching ‘programming’ and in general thinking about programming. Programs are usually envisioned as being statements which are performed in a sequence one after the other. This is comparable to the nature intuition about what an algorithm is, i.e. a series of steps to achieve a result when given some input.

The problem then lies in the deeper explanation. It is said that the hardware is just taking instructions and executing them one after another, and that is then mapped to the execution of programming language statements. The issue of ‘imperative’ vs ‘non-imperative’ implementations is really a question of granularity. The map between machine instructions and language constructs is so large (for most every modern machine) that while the imperative algorithm seems more reflective of the underlying architecture it is just a layer of cover up to make programmers feel better.

I really think that the appearance of control over fine grained instructional behavior give people the feeling that their imperative code is truer/more-correct in relation to the machine. This feeling leads to the presumption that imperative is more efficient.

As a final caveat, the ability for a non-imperative algorithm to be equivalent to its imperative alternative tends to rely on the language’s compiler (and the restrictions inherent in the non-imperative language). This is the origin of the ‘with-a-smart-enough-compiler’ argument that people sometimes level against non-imperative programming, i.e. there is not a compiler smart enough to take your high level language and produce the same machine code I do in my low level language.

So I’m sum, I think it is both a teaching error (the continual re-enforcing of confusion between what a program says vs what a machine does) and a general human level confusion as to what an algorithm is at the level of silicon in 2022.

Re: OCaml Programming: Correct and Efficient and Beautiful

#125

Post by zasdffaa »

agentultra wrote: post #103
substation13 wrote: post #85

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…

> 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 stuff which looks immutable but isn't, under the hood.

As ever, it depends.

> Or is it easier to reason about algorithms in terms of their operational semantics?

Good question. I'd say people think in terms of actions not mathematical functions. I certainly do. Imagine teaching an 8-year old. And it does map so well onto the underlying reality of fundamentally mutable hardware.

Re: OCaml Programming: Correct and Efficient and Beautiful

#126

Post by raverbashing »

toolslive wrote: post #116
raverbashing wrote: post #84

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

> 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

#127

Post by substation13 »

wyager wrote: post #96
abathologist wrote: post #66

Earlier quoted context omitted.

Haskell is a great language but has plenty of its own warts. The value prop and trade offs between OCaml and Haskell really makes it hard to use one as a drop in for the other imo.

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?

Re: OCaml Programming: Correct and Efficient and Beautiful

#128

Post by kaba0 »

the_duke wrote: post #122
kaba0 wrote: post #119

Earlier quoted context omitted.

There are two ways to improve performance of a given program. You either go lower level, giving more control over the execution and specifying what you want exactly, or you go higher , not constraining the execution as much, allowing for better optimizations. For example a manual for loop will almost always be harder to optimize than a map. The latter gives explicit permission for reordering, allowing for vectorizati…

> modern CPUs employ just as much FPism Do you have some references where I could learn more about that?

What I mean mostly are out-of-order-execution (reorder these instructions and return results as if they were executed in order - it is worthwhile because useful work can be done “in the background” while the CPU waits for memory. But this transformation is not too imperative in my opinion) and SIMD instructions (and in extension GPUs) are much more about transformations on data than a traditional Turing-machine - but there are no sharp boundaries anywhere here. It is just not smart to dismiss such a big and important part of CS, when it has plenty of applications.

Re: OCaml Programming: Correct and Efficient and Beautiful

#129

Post by yawaramin »

water8 wrote: post #21
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:…

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#130

Post by xvilka »

frou_dh wrote: post #92
cmrdporcupine wrote: post #23

Earlier quoted context omitted.

I learned SML/NJ and OCaml around the same time and for some reason I found SML more pleasant. I particularly liked the SML "Basis" library, it felt really well designed to me. Still, I'd pick either over Scala. Superior compilation times, cleaner syntax, less complex. Haskell also just feels excessively clever. I had hoped Rust would be "OCaml but for systems programming" and it sort of is, -- but the borrow checker…

SML definitely has a more tastefully designed syntax also, and not only because it's a smaller grammar. OCaml syntax is the "scuffed" version of SML syntax, as the kids say! Unfortunately to be a real-world SML user these days is a very isolating proposition, because although there are some really nice implementations (MLton, PolyML), to a first approximation there are zero libraries.

SML is the dead end because specification wasn't updated for decades.
Post reply on HN