Live data from Hacker News

Reflecting on Haskell in 2015

stephendiehl.com

31–40 of 106 posts

Re: Reflecting on Haskell in 2015

#31
Stack is absolutely wonderful. stack setup command works wonders, building is effortless, moving to new library versions is as easy as ever and ever since I've started using it I've been writing more and more code in Haskell.

Tooling is absolutely great, Atom plugins are very fine, really, it's very enjoyable and it all happened in a single year.

Re: Reflecting on Haskell in 2015

#32
post #19

Earlier quoted context omitted.

For learning functional programming I find Racket to be the best for teaching functional programming. I think I took 4 tries at teaching myself Haskell and then learning Racket really helped me to get over the learning curve of Haskell though i still consider myself a beginner.

I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different leve…

I had to read Real World Haskell's chapter twice: http://book.realworldhaskell.org/read/monads.html to figure it out.

It's essentially a hidden argument that's passed around between the environment (the stuff in "do ... ") and the actions (the stuff called in "do ...", e.g, "x Stuff that doesn't use the hidden arg doesn't have the action type (e.g., IO ()), so it has to be lifted, which essentially passes the old world state verbatim to the next step.

Re: Reflecting on Haskell in 2015

#33
I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it.

But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep getting added to it. Every project uses a different set of GHC extensions.

I feel that without more standardization or stability, Haskell can never be more than a playground for PL researchers who can afford to spend all their time learning and implementing advanced language features.

Re: Reflecting on Haskell in 2015

#34
post #27

Earlier quoted context omitted.

I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different leve…

This [1] might help 'get it' with regards to monads. Very easy to digest. You mention LINQ and the List abstraction. Yes IEnumerable is a monad (LINQ isn't in itself - it [the grammar] is the equivalent of 'do' notation in Haskell). Monads are simply 'wrapper types' that follow a couple of rules: 1. You must be able to construct one from the un-wrapped value (return in Haskell, new List (...) in C#) 2. It must implem…

Thanks for taking the time to write all that up. I think (too early to say) that seeing all this expressed in C#/Java(script)/Ruby/Python syntax is key for someone like me.

I learned LINQ/Select(Many) and later all the map/filter/reduce functional goodness by playing with Clojure and never had a problem and never heard the word "monad" and was fine, totally fine.

Later watching a video on Rx (MS's reactive extensions) and hearing Erik Meijer talk about monads and Haskell and how Rx was inspired by that is what led me to try to learn Haskell. I just didn't see the "connection" between the functional and reactive patterns I was applying daily without any kind of mental problem and the Haskell stuff which was supposedly "the same", yet so....abstract?

I need to read your sample code and the links more carefully, but maybe this is the "key" I was lacking. Thanks !!!!

Re: Reflecting on Haskell in 2015

#35

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.

Re: Reflecting on Haskell in 2015

#36

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

I don't really feel that way. In fact, I think that there's just so much going on in Haskell that it kind of frees me from having to understand it all. Being comfortable with fundamentals of purely-functional programming (basically ADTs and use of first-class functions e.g. with maps/filters/folds), and the essential types and type classes (Functor, Applicative, Monad, State, etc) give one enough of a grounding as to be able to write pretty much any program one could want. Sure, I could try to learn lenses, or the parallelism libraries, or software transactional memory, or DataKinds, or the infinitude of Ed Kmett Prosemicofunctor type classes... or not. If it turns out I need those, or I think they'd be particularly useful, I can learn them, but I don't need to. I'll never know everything there is to know, so I don't feel an obligation to.

Re: Reflecting on Haskell in 2015

#37
post #19

Earlier quoted context omitted.

For learning functional programming I find Racket to be the best for teaching functional programming. I think I took 4 tries at teaching myself Haskell and then learning Racket really helped me to get over the learning curve of Haskell though i still consider myself a beginner.

I've tried Haskell 4 times. No joke. I have no problem with currying, higher-order functions, foldl, etc., but Monads. Get. Me. Every. Time. My brain just refuses to fully "grok" them. I still don't see why they're so awesome. I know I use them day-to-day - LINQ, the "List" abstraction (supposedly also a monad??) but I just don't see why it's important to understand them on this whole new fundamentally different leve…

In my opinion, the only way to understand monads is to use them. They'll be a little weird at first, but the type system will guarantee you're using them in the right way. The thing is that you don't really need to understand how a given monad works under the hood; you just need to know how it's going to act when you use it. For example, I couldn't write the State monad instance right now, not without quite a bit of puzzling anyway. But I use the State monad all the time, because I know how it's going to act:

    addToState :: Int -> State Int ()
    addToState number = do
      currentState 
How is this working exactly? Well who cares. I know that once this function is called, my state will have been incremented by the given amount.

Re: Reflecting on Haskell in 2015

#38
post #30

I've learned haskell at the university level, and really enjoyed it(and found it very easy to pick up), but find it puzzling where I should use it. It's very easy to say this problem requires a scripting language, and this problem is better suited for an object oriented language, but I don't quite understand what problems would be easier with a functional language. At least in terms of problems that I want solved.

> ...this problem requires a scripting language...

Cool, we have that in Haskell these days![1] Except, of course, it has all the good high-level stuff of Haskell, which reduces boilerplate and increases correctness.

[1]: https://hackage.haskell.org/package/turtle-1.2.3/docs/Turtle...

Re: Reflecting on Haskell in 2015

#39
post #2

I like Haskell but I see no future in terms of widespread adoption for it. It's simply too alien for your typical CS grad and for some projects one would like to use it for (let's say security critical), laziness (and non-predictable behavior in terms of memory use and performance) is a big problem. We do however see some of its features being slowly introduced to other languages which is nice, I guess.

"It's simply too alien for your typical CS grad"

That's just a question of teaching it to more CS students then. I don't think it's outside of the reach of the average programmer.

And yes you probably wouldn't use it to build real-time applications. But you probably wouldn't use Python to write an operating system. No language fits all use-cases.

Re: Reflecting on Haskell in 2015

#40

I consider myself a functional programmer, and I also have an interest in logic and type theory, and have learned enough Haskell to write some student-level projects in it. But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast. There are too many language extensions, and more and more conceptually sophisticated features keep…

This matches my experience.

At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth.

We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the reason why is because we're able to constrain the education effort to the slice of Haskell that we want them to read and write.

For instance, we accept the fact that we have new teammates who haven't yet truly understood what "do" blocks are all about. These people are nevertheless able to write perfectly serviceable, production-ready code. They've learned that they can chain imperative actions together in a particular way, and that's enough for awhile. Deep understanding comes later.

Post reply on HN