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

Reflecting on Haskell in 2015

stephendiehl.com

Post reply on HN
Print view View original

71–80 of 106 posts

Re: Reflecting on Haskell in 2015

#71

Post by jfoutz »

PopsiclePete wrote: post #20
baldfat wrote: 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…

If you understand currying, you've got monads pretty much. They curry in a hidden thing.

Re: Reflecting on Haskell in 2015

#72

Post by jfoutz »

PopsiclePete wrote: post #20
baldfat wrote: 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…

If you understand currying, you've got monads pretty much. They curry in a hidden thing.

Re: Reflecting on Haskell in 2015

#73

Post by mbrock »

chrisseaton wrote: post #35
jasperry wrote: post #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…

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.

Abstraction, like optimization, is nice when it serves a purpose. If it doesn't serve a purpose, you're probably just making your program harder to understand for no reason. You can see this in Java too, with proliferating class hierarchies introducing needless concepts. Haskell is also a research language and there are people working on abstractions for the sake of it, much like mathematicians sometimes do. If that's not your interest, just write programs that work and don't worry about being abstract for the sake of abstraction!

Re: Reflecting on Haskell in 2015

#74

Post by throwaway000002 »

rdc12 wrote: post #66

"Call-By-Push-Value On the topic of evaluation methods there is interesting research opportunity into exploring an alternative evaluation methods for the lambda calculus under the so-called “Call-By-Push-Value” method. Surprisingly this technique has been around for 11 years but lacks an equivalent of SPJ’s seminal “stock hardware implementation” paper describing an end to end translation from CBPV to x86. This would…

He's probably referring to SPJ's work on the spineless tagless G-machine [1].

In truth, though, I think trying to incorporate Call-By-Push-Value into Haskell would radically change the language unless there's some research in type theory that allows for the implicit Call-By-Need nature of Haskell to be extended into a form that can accommodate CBPV, which itself explicates a kind duality between Call-By-Name and Call-By-Value.

If advancements have been made here, I'd love to hear about it.

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=6708...

Re: Reflecting on Haskell in 2015

#75

Post by dandrews »

codygman wrote: post #65
dandrews wrote: post #60

Earlier quoted context omitted.

" Why do you want to 'grok' them? Just use them. " You remind me of my first ground school instructor. I'd asked her why it was necessary to use rudder in a turn, and she waved her hand dismissively. "Just step on the ball" she recited, referring to the turn-and-bank indicator. No thank you, I'd rather know what's keeping my plane stable, so I found the answer elsewhere: Langewiesche's awesome Stick and Rudder , stil…

That's a little different I think. What are the potential repercussions of not intimately understanding monads and the monad laws in Haskell? Much lesser than not understanding ruddering into a turn I'd guess, though I don't know what it is. What do you think?

Some pilots are just drivers - I'd certainly rather ride with the former, given the choice!

While it's tempting to characterize some programmers as just coders, that sounds pejorative and wouldn't be very charitable of me. So instead I'll distinguish programmers as tool makers and tool users. I know which one of those I'd put my faith in too, all things equal.

No offense intended... at all! I don't grok monads either, but in my world (mainframe stuff) Haskell doesn't register. If I used monads though I'd surely be driven to understand what's going on under the hood.

Forgive me another tangential OT story, an anecdote I read in a magazine many years ago. A man was spending a Saturday afternoon puttering around in his back yard while the family's hound slept on the back porch. The man called the dog, who then roused and put his nose to the ground, retracing all the steps his master had taken that afternoon until he finally reached the man. "The dog didn't give a damn about coming to me" the man growled, "He just wanted to know how I got here."

Hee! That's me.

Re: Reflecting on Haskell in 2015

#76

Post by tangled_zans »

mbrock wrote: post #69
PopsiclePete wrote: post #20

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…

"Monad" is an abstraction. What kind of abstraction? An algebraic abstraction. That means really understanding the concept is much like understanding other algebraic abstractions. The most basic concept in classic 19th century abstract algebra is "group." Just like the monad concept, this concept involves a set of values that can be combined with a few carefully chosen operations. Just like with the monad concept, th…

What an excellent linking of groups to monads, I really enjoyed reading this! Thanks for writing it up.

Re: Reflecting on Haskell in 2015

#77

Post by imakesnowflakes »

LukeHoersten wrote: post #3
armitron wrote: 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.

Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desira…

> Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks.

What is an example of an extremely complex problem that you have solved that would be vastly more harder to implement in another language.

The most powerful thing that I have noticed is the type system. When you have a complex problem, you end up breaking it up by writing a lot of functions. In case of a language with a less powerful type system, it is hard for you to string them all together to build the complete program.

But with Haskell, if you have cared to actually annotate the types, this becomes a really trivial task. It also detects flaws in your reasoning (because the result of the previous step is incompatible with the input of the current step).

So, doing this would be vastly more difficult in a language like Python or even a language with less powerful type system like C.

Re: Reflecting on Haskell in 2015

#78

Post by meowface »

bonobo3000 wrote: post #67
PopsiclePete wrote: post #20

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…

Heres what finally got me to understand monads, including some of the context around them: 1. Why is it important that a List is a monad? A. Its not particularly important. Its really just pointing out that monad is a very general abstraction - it wont tell you anything you don't already know about Lists. On the other side, lists as kind of trivial examples of monads - they didnt really help me understand monads eith…

What helped me grok monads was to understand that monads are just a subset of functors. Then I did what I could to fully understand what functors were, since at that point they were still a kind of cargo-cult black box for me.

    let liftF = fmap
    liftF negate (Just 1)
    liftA negate (Just 1)
    liftM negate (Just 1)
Realizing these all performed the same operation (if operating on a monadic value), and that `fmap` is just a `liftF` ("lift a regular function to work on a functor"), cleared some things up for me.

This also helped: https://en.wikibooks.org/wiki/Haskell/Applicative_functors#A...

So all these abstractions really just let you do different things with functions that normally don't take functor arguments. They make the function basically allow functor arguments (kind of), to save writing a lot of boilerplate within your functions; typically boilerplate that would be put at the start of every function.

Once someone really gets the idea of what a functor is and why they can be useful, I think the rest is easy to understand once you read the definition of monads and applicatives.

Re: Reflecting on Haskell in 2015

#79

Post by startling »

AnimalMuppet wrote: post #29
xixixao wrote: post #14

Earlier quoted context omitted.

Talking about security: https://code.facebook.com/posts/745068642270222/fighting-spa...

I don't think "fighting spam" is really what the GP was talking about. A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language pa…

This is just wrong. You can totally use managed mutable buffers that you overwrite once you're done. It's probably easier than in Java.

Re: Reflecting on Haskell in 2015

#80

Post by vu3rdd »

sotojuan wrote: post #28
baldfat wrote: 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.

Racket is really underrated for some reason. I rarely see it mentioned even though not only is it friendly to beginners (both programming beginners and FP beginners) but has a decent ecosystem.

I played with Racket and used to lurk on their mailing lists for many years! I haven't seen a friendlier community than the Racket community anywhere else.

DrRacket is a great environment to learn programming and play with various concepts, both for beginners and advanced users alike.

Post reply on HN