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

231–240 of 322 posts

Re: Pain Points of Haskell

#231

Post by [deleted] »

johnday wrote: post #198
ashtonkem wrote: post #186

Earlier quoted context omitted.

I fully grok monads. I’ve done enough reading and usage of them to understand them. They are not a useful abstraction for programming. They’re mathematically correct, but that’s not the same as what an industrial engineer needs. The big warning sign is monad transformers. Alone, monads are totally fine, but the issue is that you rarely want one . So you end up with this unwieldy tower of transformers that would make…

I firmly believe that monads (and monad transformers) are exactly what an industrial engineer needs, for the following important reason. A monad describes its scope in such a way that writing code outside of its scope is a compile time error. If your code needs certain capabilities, it must invoke the computational context of those capabilities (which is usually a monad in Haskell). If it doesn't, then the context ca…

[deleted]

Re: Pain Points of Haskell

#232

Post by amelius »

I think Haskell would be the perfect language to write reference implementations in. I.e., stuff that gets spec'd out by committees like RFCs or Web technologies.

Re: Pain Points of Haskell

#233

Post by mcguire »

rednum wrote: post #6

As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned. However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-techni…

Trying to explain monads is misguided. The formal definitions do not help practical understanding (at least without a strong background in category theory, maybe?).

It's better to simply use them until you get the idea: the IO monad is the same sequencing operation as in any traditional programming language, state monads are slightly weaker versions of the same, maybe and error monads are short-circuiting evaluation, and list is much less weird once you get that (and see the "Turn your failures into a list of successes" paper), and by that time you're probably deep into monad transformer territory.

Once you get comfortable with those, you're good to go. Unless the Haskellers have created a bunch of new nifty abstractions to learn.

Re: Pain Points of Haskell

#234

Post by klipt »

smabie wrote: post #225
klipt wrote: post #178

Earlier quoted context omitted.

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

You really think so? Take for example, kdb+/q. Not exactly widely used, but engineers who specialize it are making top dollar, it's not unusual for total comp to be around a million dollars, or sometimes a lot more, if you're the principle architect of a new system.

You're just saying that kdb has the opposite imbalance as Haskell (relative to mainstream languages).

If supply and demand for kdb favours employees, then presumably it disfavors employers, who would rather have a bigger pool of kdb programmers so they could pay less.

That doesn't contradict what I said about Haskell vs mainstream languages. I didn't say all niche languages are like Haskell.

Re: Pain Points of Haskell

#235

Post by AnimalMuppet »

johndoe42377 wrote: post #101
exdsq wrote: post #47

Earlier quoted context omitted.

What does this comment or linked article even mean? :D

Well, as you might know, there is a classic talk on YouTube in which SPJ half-jokes about religious zeal of purity in Haskell, to avoid "sins" of side effects as only religions purists might do. It is actually very clever and even beautiful analogy, because if there is anything good about any organized religion it is self-discipline and principle-guided minimalism. Haskell - the language defined in the Haskell report…

No, we downvote because you act like a jerk. If you want to talk to people here, lose the attitude.

For example: "normies". Yeah, you don't actually need to use putdowns to communicate. If you're going to be on HN, don't do that.

Re: Pain Points of Haskell

#236

Post by klipt »

lostcolony wrote: post #208
klipt wrote: post #178

Earlier quoted context omitted.

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

Well yeah, it seems you're reiterating that it's great for employers, not for employees. I don't disagree.

Of course if Haskell somehow takes off and all the FANG companies want to hire as many Haskell engineers as they can, then the situation would probably reverse.

Re: Pain Points of Haskell

#237

Post by ivanbakel »

Supermancho wrote: post #204
ivanbakel wrote: post #194

Earlier quoted context omitted.

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

> All the more reason to have an IDE

No, all the less reason. The path existing Haskell tools are taking makes sense. An IDE would be a massive community undertaking to do well, and still a waste of massive community effort to do poorly.

> IntelliJ is out of control, partly because java itself is horrendously convoluted, but that's an exception.

...and partly because Java is many users' first language, and partly because its ecosystem is notoriously complicated to configure and use, and partly because IntelliJ is so mature, and....

I think IntelliJ doesn't prove your point at all. It is essentially nothing like what a hypothetical Haskell IDE would be, either in users or use-cases.

I appreciate that beginners want tooling, but I am arguing that an IDE is precisely not what that tooling should be.

Re: Pain Points of Haskell

#238

Post by mcguire »

ashtonkem wrote: post #186
rednum wrote: post #6

As someone who stopped following Haskell world few years ago, this was quite interesting read. I wonder what is the state of ecosystem (libraries) now: a few years ago one of my friends complained that for most basic tasks there is some library but usually half-working and abandoned. However: I think the point about monads is fundamentally misguided. Monad is an abstract concept and trying to explain it in non-techni…

I fully grok monads. I’ve done enough reading and usage of them to understand them. They are not a useful abstraction for programming. They’re mathematically correct, but that’s not the same as what an industrial engineer needs. The big warning sign is monad transformers. Alone, monads are totally fine, but the issue is that you rarely want one . So you end up with this unwieldy tower of transformers that would make…

It might be nice to be able to compose monads some other way than transformers, but I don't know what that would be. Transformers are unwieldy, yes, but they're also completely trustworthy. If you try to assemble them randomly, without thinking about it, yes, you will have a bad time, in much the same way that you will have a bad time if you try building any abstraction without thinking about it.

Yes, they can be a useful abstraction (just like anything else); I have the same sort of feeling about your response as I have about "checked exceptions are evil".

Re: Pain Points of Haskell

#239

Post by mcguire »

yakshaving_jgt wrote: post #216
wilde wrote: post #202

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

Those two operators are very common, and they're typically called "fmap" and "bind", respectively.

Right, and when you have three or for libraries defining different symbolic languages, your code begins to resemble J.

This is one of the reasons I gave up on Scala.

Re: Pain Points of Haskell

#240

Post by misja111 »

2mol wrote: post #157
pdimitar wrote: post #16

As a guy who casually (definitely not in-depth) reviewed working with Haskell about 2 years ago I'd say the most relatable part of the article to me is: complexity in tooling and unnecessary tension when working with libraries. Also the String situation (several types of them). A lot of the other points could be addressed but the community's seeming unwillingness to tackle everyday productivity sends to me the messag…

The tooling situation has rapidly improved in my opinion, nowadays ghcide [0] (a language server implementation) is really great and easy to set up. I really do hope that not too many people feel like the message is "keep out". In recent years the community has generally strived to be welcoming to beginners and share the excitment of learning Haskell, without the arrogance. The aforementioned tooling improvements wer…

>> ghcide .. is really great and easy to set up

Honestly, I tried to set up ghcide because I would love to have a good ide for Haskell but stopped because the setup procedure is not easy at all. Or maybe I'm getting something completely wrong?

On the link you are giving, there are the following steps:

- clone a git repo

- run cabal install

- test that ghcide is able to load your code (!) Quote: "If it doesn't work, see the hie-bios manual to get it working."

- finally integrate it in the ide that you are currently using. I am using IntelliJ IDE with the Haskell plugin and apparently I am out of luck because it is not listed.

Post reply on HN