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

201–210 of 322 posts

Re: Pain Points of Haskell

#201

Post by johnday »

ivanbakel wrote: post #194
Supermancho wrote: post #175

Earlier quoted context omitted.

> I personally don't understand the hangup on the existence of an IDE. I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg chec…

My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a…

> 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, possibly with different ghc versions. As a result, I will need to compile and use up to twelve different versions of hie, and make sure that the correct one is on my $PATH depending on which project I have open.

Re: Pain Points of Haskell

#202

Post by wilde »

One additional pain point for me is the number of symbolic operators. It’s hard to search for what some of them do, and even harder to have a conversation with a coworker when half your code is things like or >>=.

Re: Pain Points of Haskell

#203

Post by johnday »

weareconvo wrote: post #181
spekcular wrote: post #5

This is a great post. However, there are so many more things that should be on here! If I could suggest just one, it would be lazy evaluation by default, which makes it exceedingly hard to reason about time and space complexity. Also relevant is the author's article on problems using Haskell on Arch Linux: https://dixonary.co.uk/cabal-2020

FYI: As of the time of this reply, https://dixonary.co.uk/cabal-2020 returns a 404.

Yeah, sorry, my website got nuked from orbit. Hopefully it'll be back up tomorrow.

Re: Pain Points of Haskell

#204

Post by Supermancho »

ivanbakel wrote: post #194
Supermancho wrote: post #175

Earlier quoted context omitted.

> I personally don't understand the hangup on the existence of an IDE. I don't understand the lack of a hangup. It's obvious from using an IDE to going back to a text editor. It hurts adoption, it hurts beginners, it hurts the ecosystem...ie disparate tools grouped with known interactions are not necessary to fully understand when creating a program, leave those details in the IDE as a simplified interaction (eg chec…

My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor. More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a…

> My point is there's no "lack" of tooling.

All the more reason to have an IDE.

> More and more beginners nowadays do not want to install a whole new IDE

That's incommensurate with reality, to put it mildly. IntelliJ is out of control, partly because java itself is horrendously convoluted, but that's an exception. A beginner would rather have a tool to support their learning curve than not. I guess it's a matter of what constitutes a "beginner".

I do not disagree that people prefer to keep their own IDEs, but that's impractical across all languages. You're going to lose tooling along the integration path, naturally.

Re: Pain Points of Haskell

#205

Post by johnday »

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

I promise, you don't need to be a mathematician to use Haskell.

If you've written shell scripts before, you understand how Haskell functions calls are written.

If you've used `forEach()` in imperative languages then you understand functors.

These two things alone are half of the groundwork you need to read basic Haskell code! Of course, the fundamental underpinnings of the language will not appear just from a surface reading of the code, but if you're a person who learns by example then the above two are more than good enough.

If you're more of a linear learner then Learn You A Haskell [1] is an excellent, if earnest, introduction to the language. Depending on your confidence level you may be able to skip a decent way in.

[1]: http://learnyouahaskell.com/starting-out#ready-set-go

Re: Pain Points of Haskell

#206

Post by Koshkin »

ivanbakel wrote: post #168

I personally don't understand the hangup on the existence of an IDE. Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language serv…

Why, a good IDE is an example of something that is a powerful tool. It increases your productivity, whether you are a beginner or not. (The problem arises when it becomes easier not to use the IDE.)

Re: Pain Points of Haskell

#207

Post by Koshkin »

nilkn wrote: post #185
ivanbakel wrote: post #168

I personally don't understand the hangup on the existence of an IDE. Don't get me wrong - IDEs are great, especially for beginners. But "one-editor-per-language" is an increasingly outdated mode of thinking. The culture shock of having to download a whole new IDE for a new language is a distinct negative. Beginners benefit from new languages slotting neatly into existing tools, which is exactly what the language serv…

Personally I don't want an IDE, just solid integration with existing editors. I didn't fully understand the power of this until I started working with Rust and VS Code. It's a really first-class experience. Hints and type errors show up so immediately and responsively in the editor with complete contextual information that I can develop essentially an entire library or application without ever running a build once. I…

What you are saying is that you do not want an Integrated DE, just a DE with Integration.

Re: Pain Points of Haskell

#208

Post by lostcolony »

klipt wrote: post #178
MaxGabriel wrote: post #154

Earlier quoted context omitted.

I'm the CTO at Mercury ( https://mercury.com/ ) and we have 100% of our backend written in Haskell. It's gone really well so far. Answering another commenter's question, I would say the "secret weapons" are: 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. 2. Correc…

> 1. Hiring: Haskell is a very in-demand language by very good engineers. For a startup, it's absolutely amazing for recruiting and I can't overstate how important recruiting good people is for a startup. Although for engineers, supply-and-demand favoring employers typically means it disfavors employees: you may effectively be taking a pay cut to use Haskell compared to more popular languages.

Sure, but those that are willing to because they're sufficiently excited about the language means you can have a higher confidence in your hires, since they, A. Know what Haskell is, B. Want to learn it, C. Are willing to take a pay cut to be able to get paid to learn/use it. Very high signal to noise I'd wager.

If you're a Java shop, you better be paying higher than market rate if you want to be able to attract good talent, but then you still have to figure out who they are amidst all the mediocre/poor devs, who are interested because of the higher comp. Very low signal to noise.

It seems like a less popular language, that has real business value, helps achieve the thing every company that isn't "hire fast, fire fast" tries to do with their hiring policy. It does mean you can't easily hire people who already know the language, so you have to consider the ramp up time, but I don't think that's nearly as painful as many hiring managers seem to think it is.

Re: Pain Points of Haskell

#209

Post by tylerhou »

johnday wrote: post #205
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."

I promise, you don't need to be a mathematician to use Haskell. If you've written shell scripts before, you understand how Haskell functions calls are written. If you've used `forEach()` in imperative languages then you understand functors. These two things alone are half of the groundwork you need to read basic Haskell code! Of course, the fundamental underpinnings of the language will not appear just from a surface…

> If you've used `forEach()` in imperative languages then you understand functors.

You understand a single (or a class of) functor but I don't think it means you understand functors in general.

You also definitely don't understand how functors fit into Haskell's type hierarchy — its relation to monoids, monads, etc.

Re: Pain Points of Haskell

#210

Post by lambdasquirrel »

This is nice, and yet, not much different from what the Haskell community was dealing with 5 years ago. They are also mostly programming concerns, as opposed to engineering concerns.

How do you deal with simple things like exceptions and string interpolation? There are guides trying to explain monads, but no straightforward answer for dealing with these sorts of things, with building separate libraries / packages, setting up your own CI with your own stackage repo. And we haven’t gotten into production yet. The ecosystem doesn’t have these things built out, or, it’s just not documented/agreed upon so you’d effectively be starting from scratch.

While it might be nice to use Haskell for math-y things, in the end, you’d have to be able to instrument it, monitor/log it, etc. That doesn’t appear to be in place either. When I worked with Haskell last, these were all blockers.

Post reply on HN