Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How it feels to join an all-Haskell startup

wagonhq.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: How it feels to join an all-Haskell startup

#51

Post by tel »

thom wrote: post #47
thrwwy5 wrote: post #23

Earlier quoted context omitted.

This to me is the biggest barrier to reading anyone else's Haskell code. It seems like it's always full of unfamiliar, ungooglable infix operators.

One of our Haskellers once tried to explain the bizarre internal consistency of the many Haskell's lens operators. It's basically just trolling in API form: https://hackage.haskell.org/package/lens-3.8.5/docs/Control-...

It's tragic people feel that way. They're actually very well-designed, but if you don't like operator soup then no amount of design will convince you otherwise. Which is fine and why the Lens package is able to be imported operator-free.

Re: How it feels to join an all-Haskell startup

#52

Post by tel »

cherry_su wrote: post #19
saosebastiao wrote: post #2

How was that snippet an improvement to your coding style? The original was extremely clear, and now someone who reads your code has to understand what (,) and do. IMO this tendency for code golf one-upmanship is a huge detractor for anyone wanting to learn the language.

Of the three, I'd contend is the most reasonable to do since it's very similar to $ (which is commonly used), but applied to a boxed argument (Functor).

On the other hand, is closer in spirit to what $ is.

Re: How it feels to join an all-Haskell startup

#53

Post by spopejoy »

tel wrote: post #51
thom wrote: post #47

Earlier quoted context omitted.

One of our Haskellers once tried to explain the bizarre internal consistency of the many Haskell's lens operators. It's basically just trolling in API form: https://hackage.haskell.org/package/lens-3.8.5/docs/Control-...

It's tragic people feel that way. They're actually very well-designed, but if you don't like operator soup then no amount of design will convince you otherwise. Which is fine and why the Lens package is able to be imported operator-free.

My problem with the operators is they screw up function composition. `over`, `set`, `view`, `firstOf`, `toListOf` compose normally with the datastructure on the right. The operators flip this and therefore require the dumb `&`.

It's kind of like diagrams with `#`. I don't accept the argument that if it's a lens or a diagram, our meager brains can't comprehend right-to-left composition anymore.

Worst of all is when there isn't a non-infix alternative, effectively forcing you to use the soup. Case in point: `%=`.

Re: How it feels to join an all-Haskell startup

#54

Post by reagency »

chriswarbo wrote: post #43
dons wrote: post #41

Habitually rewriting things in applicative and/or pointfree is a sure sign of a junior Haskell dev. One who has never had to maintain someone else's code. There are cases where it helps (e.g. structured parsing), but all too often this is simply obfuscation. Even if motivation is good -- learning new structures -- you still have to focus on cost/benefit of each change in structure. Keep it simple, folks.

I'm generally in favour of introducing applicatives, but I don't think the code in the article is a good example: (bid, now) randomIO getCurrentTime The applicative code could be considered better, since it avoids one-shot variables. However, that's not the biggest smell with this code. To me, the problems are: - Constructing-then-destructing a pair; is it really necessary? - Use of `$`; is there a way to avoid havin…

How would you write it? Creating a pair does seem weird, unless those two values are going to be passed around through multiple method calls together for use in multiple locations.

Re: How it feels to join an all-Haskell startup

#55

Post by chriswarbo »

reagency wrote: post #54
chriswarbo wrote: post #43

Earlier quoted context omitted.

I'm generally in favour of introducing applicatives, but I don't think the code in the article is a good example: (bid, now) randomIO getCurrentTime The applicative code could be considered better, since it avoids one-shot variables. However, that's not the biggest smell with this code. To me, the problems are: - Constructing-then-destructing a pair; is it really necessary? - Use of `$`; is there a way to avoid havin…

How would you write it? Creating a pair does seem weird, unless those two values are going to be passed around through multiple method calls together for use in multiple locations.

> How would you write it?

As I said, I don't know; I'd have to see what the context is. As I've written in another comment, these few lines don't seem worth "fixing"; they're not bad. Yet they might be part of some larger arrangement that's overly complex, redundant, etc.

> Creating a pair does seem weird, unless those two values are going to be passed around through multiple method calls together for use in multiple locations.

Yet the pair is destructed immediately into two variables `bid` and `now`; if we want to pass a pair around, we'd need to create a new one using `(bid, now)`, just as if they were created separately.

If we need to use the pair, we should keep it; eg. `bidNow = liftIO $ ...`.

Re: How it feels to join an all-Haskell startup

#56

Post by creichert »

tjradcliffe wrote: post #30
pash wrote: post #17

Earlier quoted context omitted.

It's somewhat debatable whether the refactor is an improvement, but there is at least one good argument that it is, and (in my opinion) only a much poorer argument that it makes things less clear. If the applicative code is better, it's because applicatives are strictly less powerful than monads, in the sense that everything you can do with applicatives you can also do with monads, but not vice-versa. Many Haskellers…

> at this point Which is a huge problem. Optimizing around the current fashion is generally a mistake. As for the rest: the argument seems to come down to "there are no junior developers in Haskell, because if you don't understand the deep and dark abstractions you're really hardly better than a barbarian anyway." This translates to: Haskell is doomed as a production language in the real world beyond a few niche/feti…

It has nothing to do with fashion. The Haskell language has been around for decades and has grown in different directions based on experience and knowledge earned throughout it's lifetime. There are apps and libraries on Hackage which are 5-10 years old which are still in wide use among Haskell and others (Parse,XMonad, and Pandoc to name a few).

Re: How it feels to join an all-Haskell startup

#57

Post by tel »

spopejoy wrote: post #53
tel wrote: post #51

Earlier quoted context omitted.

It's tragic people feel that way. They're actually very well-designed, but if you don't like operator soup then no amount of design will convince you otherwise. Which is fine and why the Lens package is able to be imported operator-free.

My problem with the operators is they screw up function composition. `over`, `set`, `view`, `firstOf`, `toListOf` compose normally with the datastructure on the right. The operators flip this and therefore require the dumb `&`. It's kind of like diagrams with `#`. I don't accept the argument that if it's a lens or a diagram, our meager brains can't comprehend right-to-left composition anymore. Worst of all is when th…

The non-infix names are a bit more conservative, yes, but it's easy to define your own of course. And to even argue back about $ and & is pretty bike-sheddy. It's just a choice that was made.

Re: How it feels to join an all-Haskell startup

#58

Post by foldr »

pash wrote: post #36
tjradcliffe wrote: post #30

Earlier quoted context omitted.

> at this point Which is a huge problem. Optimizing around the current fashion is generally a mistake. As for the rest: the argument seems to come down to "there are no junior developers in Haskell, because if you don't understand the deep and dark abstractions you're really hardly better than a barbarian anyway." This translates to: Haskell is doomed as a production language in the real world beyond a few niche/feti…

Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away. The fashionistas are the programmers who want to pick up a bit of Haskell to impress their colleagues but don't want to learn the abstractions that make it a languange worth learning in the first place. They're the people who read about it on Hacker News and decide it's worth a few hours—enough that they can sl…

>Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away.

That doesn't really make any sense. Just because the abstractions have some kind of Platonic existence doesn't mean that people are going to keep using them.

Significant use of applicatives in day-to-day code is a relatively new development in the Haskell community. I used to write a fair bit of Haskell code around five or six years ago (well beyond basic Haskell 98), but the operators in that code were not familiar to me. (They may have been once, but I clearly didn't come across them often enough to remember them.) It's easy enough to understand the code once you look up the operators, but Haskell does seem to be gradually collecting a lot of abstractive cruft.

There's something to be said for deploying the fancier abstractions when they significantly reduce code size, rather than whenever you possibly can.

Re: How it feels to join an all-Haskell startup

#59

Post by pash »

foldr wrote: post #58
pash wrote: post #36

Earlier quoted context omitted.

Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away. The fashionistas are the programmers who want to pick up a bit of Haskell to impress their colleagues but don't want to learn the abstractions that make it a languange worth learning in the first place. They're the people who read about it on Hacker News and decide it's worth a few hours—enough that they can sl…

>Fashion? Haskell's core abstractions are not design patterns du jour. They're math. They're not going away. That doesn't really make any sense. Just because the abstractions have some kind of Platonic existence doesn't mean that people are going to keep using them. Significant use of applicatives in day-to-day code is a relatively new development in the Haskell community. I used to write a fair bit of Haskell code a…

Yes, applicative code is a relatively new development in Haskell: applicative functors were discovered only in 2008.
Post reply on HN