5 ms·
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 i
by yazzku 2y ago
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.html https://www.parsonsmatt.org/2019/12/26/write_junior_code.htm...
- shermantanktop 2y agoLearning 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.
- CyberDildonics 2y agoThe reality is people want what you produce when you're sober, not having fantasy hallucinations.
- yazzku 2y ago"You mean you're going to make a copy of that every time?"
- mrkeen 2y agoHaha, 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-when-necessary-4bd6 https://dev.to/kylec32/effective-java-make-defensive-copies-...
- yazzku 2y agoI was half-joking. I wasn't aware Java was promoting "defensive copies" :D
- eru 2y agoHaskell isn't all that pure.
- ChadNauseam 2y agowhat 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)
- agnishom 2y agoIt doesn't have great support for Dependent Types
- eru 2y agoThey 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.
- kreetx 2y agoTo 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.
- tromp 2y agoLambda 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.
- mrkeen 2y ago> 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
- shermantanktop 2y agoIs there a language where that isn’t the case?
- mrkeen 2y agoApproximately 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.
- enugu 2y agoOCaml 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.
- wyager 2y agoOCaml'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.
- RandomThoughts3 2y agoConversely, 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.
- kreetx 2y agoIf 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.
- wyager 2y ago> 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.
- hedora 2y agoGo 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/ 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.
- krmboya 2y agoIsn't Go's concurrency model an advantage over other approaches?
- lmm 2y agoWhen 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.
- foldr 2y agoYou'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.