Live data from Hacker News

An opinionated guide to Haskell

lexi-lambda.github.io

41–50 of 96 posts

Re: An opinionated guide to Haskell

#41
post #28

Earlier quoted context omitted.

Cabal version too high. Did you have a pre existing cabal installation independent of stack or something?

I don't think that I do. Is it possible that ghc-mod is broken on lts-10.5?

It isn’t broken in lts-10.5, it just isn’t in lts-10 at all. Go to https://www.stackage.org/lts-10.5 and search for ghc-mod—it just isn’t currently available.

Unfortunately, the reason for this is that ghc-mod still isn’t updated for GHC 8.2. It’s almost there—a package candidate has been uploaded that works alright—but it hasn’t made it into the LTS yet. There’s a way to build and install the package candidate in a way that will work with stack, which I have done on my personal machine, but honestly I decided it was just too much for this (already overly long) blog post.

Re: An opinionated guide to Haskell

#42
> There was a time when cabal-install had a (warranted) reputation for being nearly impossible to use and regularly creating dependency hell

> You almost certainly do not want to use stack install.

> The .cabal file is, ultimately, what is used to build your project, but modern versions of stack generate projects that use hpack, which uses an alternate configuration file, the package.yaml file, to generate the .cabal file. This can get a little bit confusing, since it means you have three configuration files in your project

> Frankly, I think the UX around this is terrible.

This goes to show that no amount of static typing can save you from implementing badly-designed software.

Re: An opinionated guide to Haskell

#43
post #28

Earlier quoted context omitted.

Cabal version too high. Did you have a pre existing cabal installation independent of stack or something?

I don't think that I do. Is it possible that ghc-mod is broken on lts-10.5?

Yes, see https://github.com/DanielG/ghc-mod/issues/900

Re: An opinionated guide to Haskell

#44
post #31

How good is the static analysis tooling (IDE / editor plugins) for Haskell? Given Haskell's powerful type system, I imagine that it must be possible to see warnings, hints, autocompletion and other early feedback about the code in the editor before compilation, like in Java, Kotlin etc. or even better - is that the case?

Maybe things have changed, but not a couple years ago when I was working with Haskell. No IDE story at all, which is just a crying shame when you think about the kind of refactoring and powerful features you could support. The fact that vim or other text editors were typically what was used was just odd and a waste IMO...like having a rocket propulsion system strapped to a Huffy.

Re: An opinionated guide to Haskell

#45
post #25

When I look at many modern Haskel guides, they all seem to recommend adding all these extensions/sugar into your code. If these things are so common to use, why doesn't Haskel adopt them into core?

Because a lot of them are a very bad idea: they overly complicate code to achieve with typeclasses what you can easily achieve without them in normal Haskell 98.

Re: An opinionated guide to Haskell

#46
post #29

I've tried messing around with haskell a few times, but the biggest problem I have is the tooling. I just tried to get haskell set up a few days ago and I couldn't get it working with either vscode or Idea. I also couldn't get ihaskell (jupyter notebook) installed successfully. I might give it another shot based on these instructions, but the fact that pretty much every program seems to make different assumptions abo…

What operating system are you running on? I paid for and downloaded Haskell For Mac[1] and it's been a great dev experience so far. The IDE is similar to Xcode (I'm an iOS developer) and the REPL is great for trying stuff out. [1] - http://haskellformac.com

What sort of apps can you build with Haskell For Mac? The website gives me the impression it’s more akin to Swift Playgrounds than IntelliJ.

Re: An opinionated guide to Haskell

#47
post #25

When I look at many modern Haskel guides, they all seem to recommend adding all these extensions/sugar into your code. If these things are so common to use, why doesn't Haskel adopt them into core?

Haskell is a standardized language that moves very slowly. Some of the extensions may be integrated into Haskell2020.

The most recent progress on Haskell 2020 seems to be a GitHub issue in which the committee members admitted work had stalled and put forth some ideas to improve things. That was 9 months ago though.

Re: An opinionated guide to Haskell

#48
post #21
post #8

Earlier quoted context omitted.

If you’re in it for the two-week thing rather than the long term, “learn you a Haskell for great good” is a good choice. Not terribly informative if your goal is writing large applications, but pretty good introduction to the mindset that goes with writing haskell

To elaborate on LYAH, I think it's a pretty bad resource for actually learning Haskell. It's very "here's a feature, now copy it". Which works fine for learning syntax, but works poorly for learning Haskell. Check here for a review that really resonated with my experiences about LYAH: http://bitemyapp.com/posts/2014-12-31-functional-education.h... Note the author of that post is also the author behind the Haskell boo…

I have to disagree about LYAH here.

Allen can argue that LYAH is incomplete, and he seems to think the university courses he mentions are the best way to learn Haskell. But not all developers want to go down that route, at least not as a first step. For me, LYAH was an important stepping stone to getting productive, while at the same time fully understanding that it was not the final word on anything.

This is, I suspect, what Allen doesn't get. His Haskell book is actually yet another example of why many developers find Haskell daunting to learn; it starts at the deep end, like many books before it. LYAH succeeds precisely because it doesn't go into several pages about beta reduce before explaining how variables are declared. Sure, it's chatty, it likes to rely on the REPL to show evaluations, and it also doesn't start with a formal introduction to functional languages or lambda theory. But it's a book written for programmers who already know how to code. It's approachable, doesn't go into unnecessary detail (if you want to know everything about List, go somewhere else; the Haskell Book has 59 pages devoted to it!), and lets you get up to speed fast without falling off along the way. It's an introductory mini course, and by the end of it you'll be able to write programs.

I don't buy Allen's arguments about it being "unpedagogical". I've never used book exercises and I never will, yet I didn't have any issues learning Haskell, or any other programming book for that matter. The absence of exercises in LYAH doesn't make it a bad book.

As an aside, Allen co-wrote what he claims is a superior book, and then published it as... a PDF. I just purchased it, and was immediately disappointed I had paid $59 for what amounts to a paper book in digital form, with no web version (the "online" version on gumread.com doesn't even provide hyperlinks within the book). LYAH is great because it's adapted to the web. I'm sure the Haskell Book is wonderful (and I'm reading it), but this is another way he misses the point of LYAH.

Re: An opinionated guide to Haskell

#49

I've tried messing around with haskell a few times, but the biggest problem I have is the tooling. I just tried to get haskell set up a few days ago and I couldn't get it working with either vscode or Idea. I also couldn't get ihaskell (jupyter notebook) installed successfully. I might give it another shot based on these instructions, but the fact that pretty much every program seems to make different assumptions abo…

Same with me. I download some code (or git clone) from an article or gist or somewhere which looks cool.

I'd estimate 80% of the time I fail to compile. Typical reasons are errors from Cabal, stack is wrong version, things like that.

If it was C or Python or even Rust I'd forge ahead and make it work. But with Haskell's tooling I'm too far out of my depth to bother.

Re: An opinionated guide to Haskell

#50

Earlier quoted context omitted.

Haskell + Nix is the best environment I've ever used for any development. My go-to project manager is this script in the reflex-platform, which is a bit poorly named (it will change eventually), because it's actually an environment for doing general cross-platform full stack Haskell development: https://github.com/reflex-frp/reflex-platform/blob/develop/p... The learning curve is definitely , shamelessly high. We've…

I couldn't disagree more. Nix doesn't make development easier. In fact, it substantially complicates development to ease open source delivery and client dependency management. These are things that are of questionable value to the Haskell or product dev ecosystem, as people far more often prefer fully static (admittedly large) binaries anyways. And, Nix doesn't work well with existing tools like intero, it requires t…

I didn't, at all, recommend nix to anybody. What are you responding to?
Post reply on HN