Comment by yazzku | Hacker News Reader

Comment by yazzku | Hacker News Reader

Parent Full thread

Engineer vs mathematician. Haskell is the schizophrenic product.

> If I come to an existing OCaml project, the worst thing previous developers could do to it is have poor variable names, minimal documentation, and 200+ LOC functions. That’s fine, nothing extraordinary, I can handle that. > > If I come to an existing Haskell project, the worst thing previous developer>s could do… Well, my previous 8 years of Haskell experience can’t prepare me for that

This is kind of like Go vs C++, or <anything> vs Common Lisp. The former is a rather unsophisticated and limited language, not particularly educational or enlightening but good when you need N developers churning code and onboard M new ones while you're at it. The latter is like tripping on LSD; it's one hell of a trip and education, but unless you adopt specific guidelines, it's going to be harder to get your friends on board. See, for example: https://www.parsonsmatt.org/2019/12/26/write_junior_code.htm...

Go is good for onboarding people onto a project, but not much else.

There's a reason Google is migrating Go services to Rust:

https://www.theregister.com/2024/03/31/rust_google_c/

> "When we've rewritten systems from Go into Rust, we've found that it takes about the same size team about the same amount of time to build it," said Bergstrom. "That is, there's no loss in productivity when moving from Go to Rust. And the interesting thing is we do see some benefits from it.

> "So we see reduced memory usage in the services that we've moved from Go ... and we see a decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness."

That matches my experience: Go serivces tend to be tire fires, and churn developers on and off teams pretty fast.

You'd expect a rewrite to take less time than development of the original system from scratch. So I'm not sure this is actually as favorable a result for Rust as it's presented.

Isn't Go's concurrency model an advantage over other approaches?

When it exactly fits your problem, yes. But it's not like you can't express that model in Rust (in a more cumbersome way) when you need to.

OCaml is not an unsophisticated language. It inherits the features of ML and has first class modules, which is not present by default in Haskell (present in backpack). Not having first class modules leads to a lot of issues.

Also, there is a better story for compilation to the web.

OCaml's type system is quite janky and simplistic compared to Haskell's. The first class module system is fairly nice, although it leads to an annoying problem where now you kind of have two "levels" to the language (module level and normal level). This is arguably analogous to Haskell having a "term level language" and a "type level language", where the type system is more prolog-y than the term language. Also, Haskell's type system is powerful enough to do most of the things you'd want the OCaml module system for, and more. I do occasionally miss the OCaml module system, but not most of the time.

Conversely, the Ocaml module system is powerful enough to do all the things you had want to do with Haskell except the Ocaml module system is nice to use.

Anyway, the issue has nothing to do with relative powerfulness. The issue is that the Haskell community encourages practices which lead to unreadable code: lot of new operators, point-free, fancy abstraction. Meanwhile, the Ocaml community was always very different with a general dislike of overly fancy things when they were not unavoidable.

> except the Ocaml module system is nice to use

This comment doesn't lead me to believe you've ever worked in an ocaml shop. It's only "nice to use" for trivial use cases, but quickly devolves into a "functorial" mess in practice

> the Ocaml community was always very different with a general dislike of overly fancy things when they were not unavoidable

This is the exact thing that people always say when they are coping about their language being underpowered.

If by "encourages" you mean "has features", then yes. The typical haskell shop doesn't really encourage complex feature use, it's the people learning/online who don't actually need to work within their solutions, do. That's what seems to draw (some) people to haskell.

Learning a “pure” language is a lot like tripping on LSD.

The people who do it can’t stop talking about how great it was, but also can’t really explain why it was so great, and when they try it just sounds ridiculous, maybe even to them. And then they finish by saying that you should drop acid too and then you’ll understand.

The reality is people want what you produce when you're sober, not having fantasy hallucinations.

> also can’t really explain why it was so great

I like it when

  assertTrue (f x)  -- passes in test

means that

  assertTrue (f x)  -- passes in prod

Is there a language where that isn’t the case?

Approximately all of them. The property is "referential transparency", and it's such a sensible thing to have that people assume they already have it (per your question).

The "test/prod" was an unnecessary detail - there's really nothing saying that f(x) will equal f(x) in most languages in most circumstances! It can return different things on repeated calls to it, it can behave differently if two threads call into it at once.

It's a major part of the reason people don't see the appeal of Haskell. They think they already have "type-safety" and "functional stuff" and "generics" and "null-safety" - but it's really not the same.

Haskell isn't all that pure.

what do you mean by that? all functions in haskell are pure unless you explicitly use unsafePreformIO or similar (which is rare to ever have to do)

They can still have side-effects like non-termination.

But I didn't mean purity in that formal sense. I meant that Haskell is plenty pragmatic in its design.

To me, "pure" means referential transparency: same input, same output. So an `Int -> Int` function will return same result on same argument. So, similar to `Int -> IO Int`, the function (action) will return an Int after interacting with outside world, `IO` tracking the fact that this is the case.

Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.

A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.

> Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.

Many typed lambda calculi do normalise. You can also have a look https://dhall-lang.org/ for some pragmatic that normalises.

> A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.

Well, but that's just unsafePerformIO (or unsafePerformIO-like) stuff under the hood; that was already mentioned.

> They can still have side-effects like non-termination.

you can still have total functions that don't finish in humanly/business reasonable amount of time.

Yes?

Just like pure functions can use more memory than your system has. Or computing them can cause your CPU to heat up, which is surely a side-effect.

It doesn't have great support for Dependent Types

what does that have to do with purity?

Nothing, but arguably a language with dependent types is more Haskell than Haskell

"You mean you're going to make a copy of that every time?"

Haha, can't tell if you're joking or not.

For anyone else reading - you don't need to make a copy if you know your data isn't going to change under your feet.

https://dev.to/kylec32/effective-java-make-defensive-copies-...

I was half-joking. I wasn't aware Java was promoting "defensive copies" :D

Reply on news.ycombinator.com