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.
Pain Points of Haskell
91–100 of 322 posts
Re: Pain Points of Haskell
#92Earlier 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…
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 evalu…
In Python world, list() may be called to explicitly guarantee an expected shape of a value in runtime. I see it regularly, when various functions call list(iterable) on their input data internally, just to be able to list.append() later on, even though there's itertools.chain() for the same purpose, which is lazy by the way.
Re: Pain Points of Haskell
#93The community has different priorities than industry
Re: Pain Points of Haskell
#94Earlier quoted context omitted.
It is in your interest to have multiple string-like datatypes in a lazy language, especially when some of them are not real strings, but rather streams of binary data. https://mmhaskell.com/blog/2017/5/15/untangling-haskells-str...
Sure, same as Erlang has "binaries" (which can be C strings or literally any binary data as you said) and Elixir built on top of that to give us UTF-8 strings. But, you know, only these two. No more. I quite dislike when languages start choking me with analysis paralysis. There have to exist sensible defaults!
Re: Pain Points of Haskell
#95Earlier quoted context omitted.
Having an SMP compiler/runtime is half of the story, the other half is safe parallelism. I expect another decade is going to be spent on chasing bugs due to mutable data escape hatches in OCaml world.
This is my main worry about Multicore OCaml. You nailed it. There's a lot of legacy in the ecosystem -- which is not a bad thing at all! Many people appreciate stable environments and learn to circumvent their problems. All completely fine and we all do it. But I worry that by chasing backwards compatibility and not just saying "guys, you need to modernise your libraries to do X and Y, otherwise you will never be Mul…
Re: Pain Points of Haskell
#96Earlier quoted context omitted.
This is my main worry about Multicore OCaml. You nailed it. There's a lot of legacy in the ecosystem -- which is not a bad thing at all! Many people appreciate stable environments and learn to circumvent their problems. All completely fine and we all do it. But I worry that by chasing backwards compatibility and not just saying "guys, you need to modernise your libraries to do X and Y, otherwise you will never be Mul…
It's actually called Raku ( https://raku.org using the #rakulang tag on social media), not Raiku.
Re: Pain Points of Haskell
#97Earlier quoted context omitted.
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
#98Earlier quoted context omitted.
> OCaml's is also excellent but not immediately obvious (their docs have improved a lot) Interesting! The last time I tried OPAM, it actually seemed more frustrating than Cabal! Maybe it's improved? Last time I tried OPAM it would install packages globally by default, and avoiding that was a confusing process, when that should be the default behavior. Cargo (while not perfect) has really nice defaults out of the box…
> Really hoping OCaml and Haskell can improve their package management story - they are getting there, but it still holds me back from really using them on a daily basis. Cabal 3.x with Nix-style buildscovers all packaging needs that I ever had with Haskell ecosystem[1]. And there's a new wave of tooling based on incremental Nix builds, that you can begin using today [2] [1] https://cabal.readthedocs.io/en/latest/nix…
As the article says, it just needs to correct the default behavior (deprecating the old behavior is on the roadmap, interestingly, the documentation doesn't even say what is the standard right now) and some improvements on usability (just better docs goes a long way).
Re: Pain Points of Haskell
#99IDE has been my largest point of pain so far. I'm just used to a more interactive development experience, and sadly the tooling is just not there yet with Haskell. That said, there's great effort right now in that area so hopefully it'll improve.
On top of the broken record system, another annoying part is that the runtime monitoring and introspection story isn't so great compared to the likes of Erlang.
Re: Pain Points of Haskell
#100Earlier quoted context omitted.
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 evalu…
that's why I mentioned "other languages/libraries where data is immutable". Replace a constructor for list() with a constructor for graph() from a random library. You won't be able to estimate the complexity of it just by reading the client code, you need to know implementation details. In Python world, list() may be called to explicitly guarantee an expected shape of a value in runtime. I see it regularly, when vari…
Some of the most common mistakes I see Python beginners make are using list or tuple when they could use a generator instead. Rarely it leads to serious memory consumption issues, more often it just leads to messy list-append-copy style code, which is very forgivable.
Some of the most common mistakes I see intermediate Python programmers make involve overuse of generators and lazy evaluation in situations where eager evaluation simplifies the code or is needed for other reasons.
This class of mistakes is a lot worse than the beginners’ mistakes, because you end up baking a reliance on handling generators deep in the code, often in places you don’t want it. People will cut off their nose to spite their own face, e.g. convert a simple list comprehension into a series of chained helper functions that all use yield to behave as generators, not realizing the memory footprint of this can be far, far worse than just materializing the whole list in memory, depending on the situation.
Often in veteran code, you see a lot of calls to list() specifically to remove propagation of bad generators, and ensure a certain function acts as a bottleneck on that type of behavior by design.