Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pain Points of Haskell

dixonary.co.uk

Post reply on HN
Print view View original

81–90 of 322 posts

Re: Pain Points of Haskell

#81

Post by foldr »

ghostwriter wrote: post #75
runeks wrote: post #71

Earlier quoted context omitted.

> In what scenarios does it make hard to reason about those complexities? I’m guessing OP is referring to reasoning about time/space usage by reading code, rather than by running the program.

This is not trivial in strict languages either, because implementation details of a particular language/library dictate the rules. For instance: l = list(range(N)) for _ in range(M): x = list(l) CPython will have MxN iterations (allocations?), whereas other languages/libraries where data is immutable may decide to optimise the list() constructor and return a reference to the same object when the input is an instance…

Of course you need to know the semantics of the programming language you're using. The point is that lazy evaluation introduces additional complexity on top of that.

Re: Pain Points of Haskell

#82

Post by mlthoughts2018 »

ghostwriter wrote: post #75
runeks wrote: post #71

Earlier quoted context omitted.

> In what scenarios does it make hard to reason about those complexities? I’m guessing OP is referring to reasoning about time/space usage by reading code, rather than by running the program.

This is not trivial in strict languages either, because implementation details of a particular language/library dictate the rules. For instance: l = list(range(N)) for _ in range(M): x = list(l) CPython will have MxN iterations (allocations?), whereas other languages/libraries where data is immutable may decide to optimise the list() constructor and return a reference to the same object when the input is an instance…

That example seems deeply contrived. I wouldn’t call that an “optimization” at all, since if you’re returning a reference, then mutating x will mutate the underlying original list, which is precisely not what the user requested by using specifically the list() constructor. If they wanted a reference they can just do x = l. This is not at all any kind of similar critique like the issues with reasoning about lazy evaluation from reading Haskell source.

Re: Pain Points of Haskell

#83

Post by HelloNurse »

pdimitar wrote: post #21
dunefox wrote: post #18

Earlier quoted context omitted.

From what I've seen of Ocaml it's similar but with strict evaluation. Then again, it has no support for unicode strings so I never really looked at it again. But algebraic data types, exhaustive pattern matching, and modules make it the next best thing, I think.

Yeah, one of the things I dislike in it as well. UTF-8 should be built-in, not relied upon by libraries, even if they are commonly used by everyone.

Lack of well-made strings puts the language as a whole in a bad light: if you don't bother supporting fundamental practical needs, asking me to use your experimental, half-engineered proof of concept is arrogant.

Re: Pain Points of Haskell

#84

Post by abjKT26nO8 »

danielscrubs wrote: post #68
rednum wrote: post #6

As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned. However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-techni…

A sidenote: how great would it be if someday an abounded, well written, non buggy piece of code could just stand the test of time like math does? Instead we throw projects and programming languages faster than I change my wardrobe. :)

The maths of today has very little to do with the maths of 500 years ago, let alone 2500 years ago. Sure, we still have the Pythagorean theorem, but in today's modern formulation it's trivial. We still have numbers, but they are no longer something that can be totally ordered. With numbers we even turned things upside down, because we used to first try to define single numbers and only then collections of numbers. These days we say that "a number is an element of a number field", "a vector is an element of a vector space" etc. and we define the structures first. But the biggest departure probably is the widespread reliance on proof. In XVI century you could call yourself a mathematician without proving things, as long as the ideas you came up with worked in practice.

I'm sure that in the programming world we'll still have "if"s and variables/aliases 200 years from now. And that's right about how much commonalities modern mathematics has with the mathematics of the age of Euclid.

Disclaimer: I took a course in history of mathematics and I have to say, if I was born as little as 200 years earlier I wouldn't be able to stand mathematics. These days, it's actually interesting to me. Similarly to how mathematics in primary through high school is really boring.

Re: Pain Points of Haskell

#85

Post by rowanG077 »

foldr wrote: post #80

One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution. (I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that re…

You can run Nix fine on any Linux distribution. But it's still a bad idea because I want Haskell to work sanely on Windows and going all in on a tech that doesn't support windows doesn't seem smart to me.

Re: Pain Points of Haskell

#86

Post by zozbot234 »

runeks wrote: post #72
logicchains wrote: post #23

Earlier quoted context omitted.

The -XStrict language extension is a lifesaver here, for when you want a language like Haskell but without lazy evaluation.

Except it only lets you define your own strict functions and data structures — i.e. you still need to consider laziness when using existing libraries.

It's also not a very principled solution. It would be better to use focusing and/or polarized logic so as to allow both "strict" and "lazy" data and functions on a first-class basis. Then language-level options could be used to manage "defaults" as a matter of language syntax, for the programmer's convenience.

Re: Pain Points of Haskell

#87

Post by pdimitar »

HelloNurse wrote: post #83
pdimitar wrote: post #21

Earlier quoted context omitted.

Yeah, one of the things I dislike in it as well. UTF-8 should be built-in, not relied upon by libraries, even if they are commonly used by everyone.

Lack of well-made strings puts the language as a whole in a bad light: if you don't bother supporting fundamental practical needs, asking me to use your experimental, half-engineered proof of concept is arrogant.

Absolutely. I know many engineers hate the word but this is simply extremely bad marketing.

I get it, you want to work on interesting scientific problems and/or you work for Jane Street (a huge financial company); but the lack of desire to circle back to certain basics and nail them once and for all sends a hostile message to me as a programmer looking to add OCaml to his tool-belt. It tells me "we don't care".

Re: Pain Points of Haskell

#89

Post by ghostwriter »

foldr wrote: post #81
ghostwriter wrote: post #75

Earlier quoted context omitted.

This is not trivial in strict languages either, because implementation details of a particular language/library dictate the rules. For instance: l = list(range(N)) for _ in range(M): x = list(l) CPython will have MxN iterations (allocations?), whereas other languages/libraries where data is immutable may decide to optimise the list() constructor and return a reference to the same object when the input is an instance…

Of course you need to know the semantics of the programming language you're using. The point is that lazy evaluation introduces additional complexity on top of that.

the point is that it's not semantics of a language alone, it's the semantics of the language + the libraries + the data constructors + the flow order. Lazy evaluation doesn't introduce additional complexity on top of that for no good reason, it actually trades a few of these complexities for one additional abstraction that lets you think about your programs in terms of data flows and transformations (instead of allocation semantics at every individual step), where program boundaries define the actual computations to perform and the complexity of the final algorithm. It's an extremely powerful tool and the complexity is justified.

Re: Pain Points of Haskell

#90

Post by tome »

foldr wrote: post #80

One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution. (I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that re…

Could you share what you mean by that, or how you got that impression?

I've used Nix once, four years ago, and I didn't really like it[1]. I've never used it since. The only thing in the Haskell ecosystem that requires Nix is GHCJS, I think, which is bleeding edge technology that few use. Cabal's new package management style is called "Nix-style" but otherwise has no connection to Nix whatsoever (I wish they'd use a different name actually -- "persistent style", "immutable style"?).

[1] For various reasons to do with user experience. I'm sure it's improved a lot by now.

Post reply on HN