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

171–180 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#171

Post by camgunz »

laserlight wrote: post #137
camgunz wrote: post #93

Earlier quoted context omitted.

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.

I program primarily in (untyped) Python (which, I get is technically strongly typed but people don't think in technical terms) these days, and I almost never experience type errors. I guess I could attribute this to a couple things:

- I'm very specific about when I use None

- I'm a big fan of named function arguments

- I like to think my naming of things is pretty good, as are my conventions for parameters

- I try to handle all possible cases (what I mean here is I do and if I don't I made a mistake)

I use tests very sparingly in personal projects, but yet I haven't really felt their absence. If I ever write a piece of particularly hairy code (metaprogramming comes to mind... lord) I'll write a quick script testing some cases and then delete it.

Anyway, all that is to say I think part of dynamic programming is you build an immune system for this stuff.

Re: OCaml Programming: Correct and Efficient and Beautiful

#172

Post by abathologist »

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…

>Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains).

I think this assertion is false, but it would take a lot of careful evaluation to prove it one way or the other. The most salient counterexample that comes to mind is modularity and namespacing.

Of course it's possible I'm wrong, and Haskell is objectively superior in every regard. But the OCaml language and ecosystem has [a decades long track record of stable and evident success stories](https://ocaml.org/industrial-users) and I find it well suited for the kinds of problems I like to tackle. I also like the prevailing vibe in the (still) small community.

This exchange reminds of a difference I've observed in the cultural tendencies in the OCaml and Haskell ecosystems: in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml.

Re: OCaml Programming: Correct and Efficient and Beautiful

#173

Post by abathologist »

wyager wrote: post #147
substation13 wrote: post #127

Earlier quoted context omitted.

What about the performance challenges caused by lazy evaluation?

People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)

That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?

Re: OCaml Programming: Correct and Efficient and Beautiful

#174

Post by zumu »

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…

> To develop further the point about "what doesn't scale" there is also the function with unnamed arguments and currying.

Not sure what you mean by unnamed arguments, but criticizing automatic currying is totally valid.

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

This is a huge jump. Any imperative solution can just be expressed as a fold of some sort and many algorithms, esp. those that use stacks, are easily expressed recursively. Which one is more "natural" is 100% subjective, but I'm in the declarative is easier to reason about than imperative camp. Moreover, the idea that "unnatural" algorithm expression implies "doesn't scale" needs much more elaboration.

> What is needed is to bridge the good things from OCaml, the type system, the pattern matching with tagged types into a modern, imperative programming languages.

> Rust is a sort of answer but they got it wrong because it is too low level about managing the memory, the ownership pardon, and everything else so programmers cannot just express the algorithm or the logic they want to implement but they have to spend a lot of mental energy thinking about ownership issues and unneeded accidental complexity like lifetime annotations.

It's not "wrong" just not what you want, and honestly the ownership model isn't that bad. The overhead amortizes somewhat as you get used to it. I of course agree there is room for more languages with ML-like type systems though!

Re: OCaml Programming: Correct and Efficient and Beautiful

#175

Post by yawaramin »

akhmatova wrote: post #145
yawaramin wrote: post #129

Earlier quoted context omitted.

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.

If Jane Street can teach OCaml to traders, I can teach it to developers. You can if they are motivated to learn. Unless you are offering Jane Street levels of compensation; and in return, the candidate is willing to believe, or pretend to believe that company's shtick about OCaml being so categorically superior as a general-purpose development language so as to leave all the others in the dust -- most likely they won…

Or if, you know, they were hired to work on a project where they get paid a salary. That seems to incentivize most devs.

Re: OCaml Programming: Correct and Efficient and Beautiful

#176

Post by 0x69420 »

franz_kafkaagh wrote: post #157
0x69420 wrote: post #82

Earlier quoted context omitted.

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

I write Elixir for work and I love most things about the language. The pattern-matching would still be made better with static checks. It sucks to have a function blow up at runtime because of something as trivial as args being swapped or some code somewhere changing its return types. Someone brought up Gleam earlier, but god why with that syntax? I'd still rather have dynamic checked pattern matching over the altern…

dialyzer and a liberal sprinkling of typespecs gets a decent chunk of the way there, meanwhile the problem with gleam and friends is the fact that they're altogether new languages -- the pragmatic solution would be a restricted subset of erlang (that a likewise restricted subset of elixir could comfortably compile down to) where your module has to be fully typed, but you would need some pretty gnarly logics to handle things like "yes, when this function mashes these two iolists together in this way, it's still an iolist" etc

Re: OCaml Programming: Correct and Efficient and Beautiful

#177

Post by marcosdumay »

acchow wrote: post #150
muglug wrote: post #45

Earlier quoted context omitted.

yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.

Stockholm syndrome arrives quite quick in this case, as you become accustomed to this form as meaning "you're missing an arg" I agree the first 6 months of this is mind-numbingly frustrating.

This is not Stockholm syndrome. It's just learning a pattern.

That's one of the top few specialties tasks for humans. After you learn it, you immediately know its meaning, it becomes easy with no thinking at all required.

Anyway, the plain English example from Elm on the sibling comment is much better, because it's already easy to understand before you learn to recognize it.

Re: OCaml Programming: Correct and Efficient and Beautiful

#178

Post by marcosdumay »

substation13 wrote: post #127
wyager wrote: 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?

Most people don't even get to see those challenges. But make wide use of the many performance opportunities created by lazy evaluation. Anyway, when any problem appears, it is obvious, so if it was a large problem, it would be fixed by now. The only reason people keep talking about it is because it nearly never appears.

Really, lazy IO is a much larger source of problems, and even there, after a week or two writing IO people just learn to write code that doesn't break due to it.

Re: OCaml Programming: Correct and Efficient and Beautiful

#179

Post by wyager »

abathologist wrote: post #172
wyager wrote: 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…

>Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains). I think this assertion is false, but it would take a lot of careful evaluation to prove it one way or the other. The most salient counterexample that comes to mind is modularity and namespacin…

> but it would take a lot of careful evaluation

This is what I was doing for a number of years.

> The most salient counterexample that comes to mind is modularity and namespacing.

Polymorphic variants and ocaml namespacing are nice, granted. These are the two ocaml features I've ever missed while using haskell. Minor details overall though. Namespacing is not as useful with typeclasses and PVs have typing problems.

> in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml

Yeah, this is mostly because it's not as much of a marginal improvement, so it doesn't have as many people interested in shilling it.

Re: OCaml Programming: Correct and Efficient and Beautiful

#180

Post by wyager »

abathologist wrote: post #173
wyager wrote: post #147

Earlier quoted context omitted.

People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)

That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?

It's not that space leaks are not a concern; it's that it's actually quite easy to avoid creating them, and if you manage to do so and it becomes a problem, it's usually easy to track down. I don't know any experienced haskell programmer who would even mention this in a list of complaints about the language (which they are sure to have, but they will likely be more abstract).
Post reply on HN