Live data from Hacker News

An opinionated guide to Haskell

lexi-lambda.github.io

71–80 of 96 posts

Re: An opinionated guide to Haskell

#71
post #56
post #32

A lot of people use Atom, but I think emacs + intero is currently the best Haskell tooling. I use it with spacemacs. Has everything I would need from an IDE, including highlighting errors on the fly, auto completion, jump to definition, auto formatting. It’s no intellij, but I’ll take Haskell’s type safety over that any day of the week, and twice on Sunday. http://commercialhaskell.github.io/intero/

+1, emacs+intero is the way to go. Emacs in general is highly underrated due to years of RSI/muh loading time shitflinging. Evil mode is by far the most complete vim emulation out there, and other than JS pretty much every language I write has been a more enjoyable/easy experience on Emacs than it was on vim or st3.

I'm writing a lot of Java right now, and it's frustrating that the experience is so horrible on Emacs -- or so much better in Intellij. I tried using Eclim with Emacs for a while, but it's so tedious moving through Java without a specialized IDE. Still, I keep Emacs open on Java code solely for the git interface (magit) and helm integration with `ag`, which I find vastly superior to find-in-path / regex search capabilities in Intellij.

Re: An opinionated guide to Haskell

#72

Earlier quoted context omitted.

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.

If you upgrade stack and then do stack build , it's very close to being guaranteed to work. Stack (and stackage) is the best nicest, most-reliable build-system of any language.

Thanks and fully and completely understand why and how the current situation happened. And I fully appreciate the efforts people make to alleviate it. My sole concern is that the situation is accurately seen for what it is.

So far, just in these comments I've seen:

    1. just use plain cabal
    2. use stack, you don't need cabal
    3. use gchid
    4. haskell+nix is best
    5. use hpack
To emphasise again, this is not a severe criticism. I've been around for too long not to know that this is an almost inevitable result of people working in open source with disparate purposes and heterogeneous environments.

PS. I bought HaskellForMac and it's great. It ties you a Haskell version a little older than the latest but that's OK too.

Re: An opinionated guide to Haskell

#73
For people who wanna learn Haskell:

1. Don't touch Haskell platform. Install Stack.

If you did, Uninstall it.

https://mail.haskell.org/pipermail/haskell-cafe/2011-March/0...

Why? It is considered harmful

https://mail.haskell.org/pipermail/haskell-community/2015-Se...

2. Install Stack:

https://haskell-lang.org/get-started/osx

If you do not wish to install these dependencies, you may use a virtual machine instead

https://github.com/data61/fp-course/blob/master/ops/README.m...

3. Learning resources:

https://github.com/allenleein/brains/projects/9

Re: An opinionated guide to Haskell

#74
post #16

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…

Ocaml tooling has actually gotten substantially better over the past year or two. VSCode as an editor that just works. Opam for package management JBuilder for managing builds. Stdlib situation is still kind of a mess, but I think Base (which is just a stripped down Core) solves a lot of the current issues.

I agree that jbuilder (dune) more or less solved the fragmentation problem for build systems, and is nice to use. I switched most of my projects to it.

On the other hand I'm more pessimistic about the stdlib situation because Base breaks compat with the stdlib, thus making the migration impossible (or really painful) for a lot of projects. I'll therefore stick to my own extension of the stdlib (containers) in the foreseeable future…

Re: An opinionated guide to Haskell

#75

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…

I help maintain IHaskell and I'm sorry to hear you had trouble setting it up. If you'd like to open an issue on the IHaskell repo I can try to help you troubleshoot your install.

Re: An opinionated guide to Haskell

#76
post #11

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…

ihaskell is a somewhat fragile project briding several disparate ecosystems/languages. I'm not really sure the value-add is there yet; in any case it is not a tool for beginners or the preferred method to get feedback from your programs. Haskell proper is pretty turn-key these days with stack. Stay away from edgelord / niche projects. Stay away from most of the IDE tooling, including ghc-mod. You don't need to be fig…

I don't think it's fair to say IHaskell isn't for beginners, I found it invaluable when I was starting out as a richer REPL than GHCi. I agree with everything else you say about it though. I help maintain the project now and would love to know how I could make it easier to install and use.

Re: An opinionated guide to Haskell

#77
post #10

Earlier quoted context omitted.

It takes a while for the Haskell community to reach consensus. Stack is definitely recommended by almost everyone for both beginners and production projects. It is used on every project I’ve run in to lately. Sure there are different ways to configure it, but these days there’s really one way to get started. Just download stack, make a new project, and start coding

I get that Stack is what people should be using now but it's still not that helpful if I can't actually get actual instructions for setting up vscode, etc. based on using stack without "stack install." The fact that haskell users seem to think these things are completely obvious and doesn't need to be explained is frankly a big part of the problem.

A very quick Google search found Haskelly [0] and Haskero [1] for VS Code, both of whose installation instructions say to install Intero [2] locally in your project directory with "stack build intero" if you don't want to use "stack install" to install Intero globally.

[0] https://marketplace.visualstudio.com/items?itemName=UCL.hask...

[1] https://marketplace.visualstudio.com/items?itemName=Vans.has...

[2] https://github.com/commercialhaskell/intero

Re: An opinionated guide to Haskell

#78
post #32

A lot of people use Atom, but I think emacs + intero is currently the best Haskell tooling. I use it with spacemacs. Has everything I would need from an IDE, including highlighting errors on the fly, auto completion, jump to definition, auto formatting. It’s no intellij, but I’ll take Haskell’s type safety over that any day of the week, and twice on Sunday. http://commercialhaskell.github.io/intero/

Emacs + Intero is absolutely the way to go, I switched to Emacs to learn Haskell and have loved it ever since.

Re: An opinionated guide to Haskell

#79
post #54

> 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…

> This goes to show that no amount of static typing can save you from implementing badly-designed software. Sure, but that's like saying "you can die to cancer even if you drive around in a Volvo."

This analogy (as any analogy) is wrong. A slightly better one would be "an expensive camera doesn't automatically make you a great photographer".

There's a long running tradition of languages with static typing and better type systems making fun of dynamically typed languages and those with "worse" type systems.

A good example is[1]: """ It's 2018 - static type systems are not optional... It is especially worrying that these people think they are gaining velocity by trading correctness. """

And yet I'm seeing more and more examples where (often preceived) correctness is often offset by much bigger problems. Another example is mini-thread on how horrible DateTime is in Haskell: https://twitter.com/chris__martin/status/956002730778288128

[1] https://twitter.com/timperrett/status/957493915937943554

Re: An opinionated guide to Haskell

#80
post #54

Earlier quoted context omitted.

> This goes to show that no amount of static typing can save you from implementing badly-designed software. Sure, but that's like saying "you can die to cancer even if you drive around in a Volvo."

This analogy (as any analogy) is wrong. A slightly better one would be "an expensive camera doesn't automatically make you a great photographer". There's a long running tradition of languages with static typing and better type systems making fun of dynamically typed languages and those with "worse" type systems. A good example is[1]: """ It's 2018 - static type systems are not optional... It is especially worrying th…

Any weaknesses with the Haskell "time" library have nothing to do with static types in particular nor the language in general.

To stretch your analogy further "Having an expensive camera does not prohibit you from also taking photography lessons".

Post reply on HN