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

301–310 of 322 posts

Re: Pain Points of Haskell

#301

Post by thepratt »

bjz_ wrote: post #38
thepratt wrote: post #30

Earlier quoted context omitted.

Using bazel as a build tool (on top of cabal) allows you to provide patches or modifications to found versions.

What happens if you are building a library that is published to Hackage?

Yes, you can apply patches from (mostly) any source. There'd be a slightly different markup/setup depending on how you popoulate your stackage/hackage - nix or http_archive (stack_snapshot). If you're modifying something from an upstream it'd be best to reference it as vendored, e.g. `@org//:package` and not the stack populated version `@stack//:package`. This is how you'd do it pulling from git directly (there's a whole lot more involved if this were to be done for a stackage package).

    http_archive(
        name = ...,
        build_file_content = """
          load(
            "@org//bazel:defs.bzl",
            "pai_haskell_library",
          )

          pai_haskell_library(
            name = ...,
            version = ...,
            srcs = glob(["src/**/*.hs"]),
            stackage_deps = [...],
            visibility = ["//visibility:public"]
          )
        """,
        patch_args = ["-p1"],
        patches = [
            "//dir:git-patch-file",
        ],
        sha256 = "...",
        urls = ["https://github.com/org/repo/archive/1.0.0.0.tar.gz"],
    )

Re: Pain Points of Haskell

#302

Post by Nebasuke »

ghostwriter wrote: post #53

> There is no featureful Haskell plugin for any major text editor which can be installed without command-line intervention This is not true for at least a year already, as there's IntelliJ Haskell: * https://github.com/rikvdkleij/intellij-haskell * https://plugins.jetbrains.com/plugin/8258-intellij-haskell

It can be installed, but I still spent 3 or more hours debugging before I got everything to work on Windows. I had to spend some time reading obscure GitHub issues to find some of the underlying problems and fix them (this included manually installing some package which didn't work under the command line default code page).

To compare, it took me less time to get Agda working.

Re: Pain Points of Haskell

#303

Post by hajile »

klipt wrote: post #188
chriswarbo wrote: post #124

Earlier quoted context omitted.

I agree, although the arguments in that article aren't the strongest. In particular: The main reason given for 'String' being slow is that it's immutable and hence leads to many duplicate Strings being created. In fact, the main reason Strings are slow is that their linked-list structure has a lot of overhead, and may be scattered around in memory. For example, the String "abc" will be represented something like this…

Sounds a bit like the Rope data structure from 1995: https://en.wikipedia.org/wiki/Rope_(data_structure) Although instead of a list of chunks, a rope is an immutable binary tree of chunks, so more editing operations are efficient, eg insertion or deletion in the middle of the rope. Abseil library contains an open source C++ implementation of a similar structure called a Cord: https://github.com/abseil/abseil-cpp/blob…

I believe both Firefox and Chrome now use Ropes as their string implementation due to those rather desirable editing operations.

Re: Pain Points of Haskell

#304

Post by mlthoughts2018 »

ghostwriter wrote: post #297
mlthoughts2018 wrote: post #288

Earlier quoted context omitted.

Hey, I actually used to work on the numba compiler team at Continuum. I can say I don’t understand the last rant paragraph at all or why you think it’s related to my point about generators.

> I can say I don’t understand the last rant paragraph at all or why you think it’s related to my point about generators. This is not a rant, you made a claim about generators' allocations inefficiencies compared to physical list() and tuple() allocations, I'd like to see the case where it's true.

It is true in many many cases. For a very simple illustration consider

    def f():
        x = list(range(10000))
        yield from x
vs

    list(range(10000))
The former includes the overhead of memory for both the materialized list and function execution frames.

The same thing happens when people naively split up generators that hold onto a lot of data, for example (this comes from real life experience where someone wanted to essentially “memoize with generators” a membership check on the response from a database call).

    def check_expensive_in():
        s = large_db_call()
        while True:
            x = yield
            yield x in s

    def expensive_filter():
        f = check_expensive_in()
        next(f)

        def helper(item):
            v = f.send(item)
            f.next()
            return v

        while True:
            items = yield
            for item in items:
                yield helper(item)
            yield None

    e = expensive_filter()
    next(e)
    e.send(some_list)
    # iterate e until None.
(Sorry for any typos or minor glitches with send(), I am writing this on my phone as I eat breakfast.)

It’s a very simple issue, which is that memoizing with generators maintains the memory footprint of the memoized data _and_ additional memory footprint of the generator (and also of large sent values into the generator too, but this is less common).

It’s better to just materialize the things you need in memory and reuse them in regular function calls, which don’t have fixed permanent overhead for a long lifetime like generators.

This can absolutely happen with small data examples too, where generators are less efficient than just materializing everything, but normally nobody cares because with small data, the effect of any inefficiency won’t be noticed.

Even in that case though, generators often lead to spaghetti code like my example above, because depending on laziness as you compose multiple functions is just a poor conceptual way to organize code. Very rarely, but sometimes, it’s worth it to avoid memory bottlenecks or to do stream processing. But it’s overstated how often this matters generally - it’s very rare unless you’re in a specialized domain where that’s all do.

Lastly I’d like to say that your tone comes across as needlessly antagonistic and it seems extremely obvious you are engaging in bad faith. You don’t seem open to consider what I am saying, rather in a rush to demand some kind of “proof” with no willingness to think through it, and likely not seeking proof to learn anything but just to try to create shallow, undermining retorts.

I won’t be continuing to check back here or engage any further with you. If you want the last word in the thread, take it.

Re: Pain Points of Haskell

#305

Post by hajile »

chriswarbo wrote: post #124
ghostwriter wrote: post #49

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

I agree, although the arguments in that article aren't the strongest. In particular: The main reason given for 'String' being slow is that it's immutable and hence leads to many duplicate Strings being created. In fact, the main reason Strings are slow is that their linked-list structure has a lot of overhead, and may be scattered around in memory. For example, the String "abc" will be represented something like this…

> In fact, the main reason Strings are slow is that their linked-list structure has a lot of overhead, and may be scattered around in memory.

This is almost entirely a myth in the context of Garbage Collected languages. Most popular GC'd languages use a copying and compacting garbage collector. They should follow the pointers when copying and put the list together in one place. Furthermore, if the compiler were to mark the list as contiguous memory region of the same type (data/data pointer and one pointer to the next link), it could jump directly to the Nth element with the same performance as a real array (assuming you do bounds checking). The only significant difference is when you get long lists and due to the doubled size, you can't fit them in a cache line, but that's not a huge issue for most lists or arrays. If cache lines are actually that much of an issue for most programs, then b-trees are a much, much larger issue as they tend to hold more data for longer and necessarily can't be lined up in access order.

I believe another factor is too much dynamic experience. With a dynamic language like lisp, list items generally won't be carrying their own types. Instead, the list will be pointers to a boxed value where the box contains type info. Implementing in a language like Haskell with the requirement of static types should (in theory anyway) decrease the need for unboxing and radically improve performance (I believe common lisp type hints also reduce the need to box everything).

It is also possible to have a linked list pattern, but not a linked list implementation. Javascript is a good example here. You can add/remove at both ends and even splice to add/remove in the middle too. For years, everyone implemented all the lists as linked lists. Today, they mostly use arrays with fill pointers. Add/removing at the beginning and middle takes a performance hit, but the much more common pushing to the end does not (until you exceed the array size). You can add a start pointer offset to an array and decrease penalties for pushing the beginning too.

Re: Pain Points of Haskell

#306

Post by johnday »

smichael wrote: post #278
johnday wrote: post #201

Earlier quoted context omitted.

> Nowadays, the Haskell IDE engine is good enough for general use. Sadly I am unconvinced of this. If it were true, there would not be an immediate and significant push to make `haskell-language-server`. Having tried many times to get `hie` working, I can say that it's a pain in the bum. Suppose I have 12 projects, one made every month for the last year. Each of these 12 will be using a different stack resolver, poss…

I don't think it's quite that bad. Most likely you could easily use 1-2 ghc versions for those, and you need one build of IDE tools per ghc version, not per resolver, no ?

Sure, I'm outlining a worst-case. But realistically, even having two different hie versions is enough to make switching environments a Hard Problem.

Re: Pain Points of Haskell

#307

Post by foldr »

gnulinux wrote: post #197
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…

One of the design philosophies of Nix is that it can work in any Unix environment, at least in theory. It certainly works in any Linux distro. There is also nix-darwin project that promises to work in OSX. I don't know the state of affairs for Windows.

> I know that you can install nix as a package manager on OS X and other Linux flavours,

Re: Pain Points of Haskell

#308

Post by apta »

nickbauman wrote: post #122

It strikes me that I need to be a mathematician to use Haskell. Especially when someone like Rob Pike makes claims that "I cannot read the syntax of Haskell and understand it."

Perhaps that explains how they ended up with a subpar language like golang.

I'd recommend reading to someone who has a deep understanding of programming like John Carmack.

Re: Pain Points of Haskell

#309

Post by diegoperini »

Eliezer wrote: post #117
diegoperini wrote: post #104

Earlier quoted context omitted.

Atom editor with its Haskell IDE plugin works like a charm. It has REPL and all other inspection stuff you need out of box. What other feature you would need is an unknown unknown to me.

An Atom plugin that actually worked after at most 3 days of effort trying to get it to work would have been nice.

If you have ghc and stack installed, this plugin will automatically recognize a project bootstrapped with stack and decorate Atom with IDE like widgets, without requiring a configuration. It can take a few minutes to make it work if your bash_profile doesn't do unexpected stuff on the PATH variable.

Re: Pain Points of Haskell

#310

Post by tome »

hopia wrote: post #300
tome wrote: post #256

Earlier quoted context omitted.

> Haskell would be more widely used if the ecosystem was more cohesive (perhaps a bit more centralized). > I’ve been enjoying Haskell enough that I’d like to help improve things. I am hatching an idea along these lines. How do I get in touch with you? Alternatively can email me at the address here if you like: http://web.jaguarpaw.co.uk/~tom/contact/

Gonna write anything publicly about whatever you're working on? If I'm correct, you've already made Opaleye which is really great, I'd be interested to hear if you got a new Haskell project coming up.

Thanks, glad you like Opaleye! I would like to start a project to improve programmer experience in Haskell. It's not ready to go public yet but if you want to know more then feel free to email me: http://web.jaguarpaw.co.uk/~tom/contact
Post reply on HN