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

Learn You a Haskell for Great Good (2008)

learnyouahaskell.com

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Learn You a Haskell for Great Good (2008)

#101

Post by vertex-four »

wyager wrote: post #87
vertex-four wrote: post #68

Earlier quoted context omitted.

> A Monad is just something that has a bind (>>=) function and a return function. You realise that this is the most useless description ever? While I'm sure it's right, it doesn't actually mean anything. Why's it a good abstraction for doing , better than any other abstraction? If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the…

>You realise that this is the most useless description ever? Which is perhaps why many people have a hard time understanding it. That is, however, the true definition. >Why's it a good abstraction for doing That depends on . I can't answer that question unless you tell me what is. > If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably mak…

> That depends on . I can't answer that question unless you tell me what is.

Isn't that kind of the problem? I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. Is it a good abstraction for adding numbers together? God knows, nobody can explain it.

> Why would a special-purpose abstraction be easier to use?

Because it says what it does on the tin, rather than being buried under several abstraction layers. My for loop is a lot more obvious than your "lifting functions into the list monad" or whatever it is you do with them, and is quite obviously doing an entirely different thing from, say, dealing with the contents of a Maybe, or storing state, or executing IO operations.

We can play with abstractions upon abstractions all day, but unless they actually mean something solid, how are they useful in explaining or solving a problem?

Re: Learn You a Haskell for Great Good (2008)

#102

Post by leereeves »

AnimalMuppet wrote: post #95
leereeves wrote: post #86

I really like this book, but I think it may be teaching some bad habits by ignoring performance concerns.

It's not a problem until it's a problem. That is: At least 90% of code is not CPU-limited. It's fast enough. So, as an initial approach, ignoring performance is fine. The problem is that, if and when you run into real performance issues, you need to know some tools for dealing with them. If this book doesn't teach you those, well... it's a language introduction. It's not an advanced text. Maybe it would be the better…

Fair enough.

I guess I mean to say that I really like this book, and would enjoy more from the author teaching fast Haskell, to supplement this book about simple Haskell.

Re: Learn You a Haskell for Great Good (2008)

#103

Post by codygman »

rhizome31 wrote: post #53
nudpiedo wrote: post #49

I always have been interested on haskell.... but it doesn't look to be enough practical. For example there is almost no information about how to write a smartphone videogame in haskell, even if it possible to trasnpile it to C or to Javascript. It is possible to interoperate with the host language? Does it perform well for high performance activities? Is it possible to isolate some kind of events in a thread? Edit: T…

I enjoyed working through this book. Actually it helped me learn enough Haskell to realize that I wasn't that interested in it. I found that it wasn't as safe as it claimed to be and that the tooling was not very good. There are some refreshing and interesting ideas, but overall I'm not sure it was worth my time.

> I found that it wasn't as safe as it claimed to be and that the tooling was not very good.

How was Haskell not "as safe as it claimed to be"? What tooling was not very good? What tooling was missing for you?

Re: Learn You a Haskell for Great Good (2008)

#104

Post by wyager »

vertex-four wrote: post #101
wyager wrote: post #87

Earlier quoted context omitted.

>You realise that this is the most useless description ever? Which is perhaps why many people have a hard time understanding it. That is, however, the true definition. >Why's it a good abstraction for doing That depends on . I can't answer that question unless you tell me what is. > If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably mak…

> That depends on . I can't answer that question unless you tell me what is. Isn't that kind of the problem? I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for. Is it a good abstraction for adding numbers together? God knows, nobody can explain it. > Why would a special-purpose abstraction be easier to use? Because it says what it does on the tin, rather than b…

>Isn't that kind of the problem?

Maybe. Leaving things in the abstract can certainly be confusing sometimes.

>I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for.

I think once you understand Monads for what they are (i.e. accept that it's just something with bind and return), you start seeing where it makes sense to use Monads. Until then, you can just use whatever concrete Monad implementations you're aware of. It seems like you know perfectly well that there exist Monad implementations for Lists, for example.

> Because it says what it does on the tin, rather than being buried under several abstraction layers.

IO, List, and most other Monads do what they say on the tin, even if you're not aware that they're Monads.

You don't have to know if something is a Monad or not to use it. For example, I've been using Lists my entire programming career without it occurring to me that I could use them with bind to model nondeterminism or the ZipList Monad.

>but unless they actually mean something solid, how are they useful in explaining or solving a problem?

They are useful because they are examples of http://en.wikipedia.org/wiki/Algebraic_structure .

You can use the definition of an algebraic structure to prove things about all instances of that structure.

Monads are, in fact, quite useful even in their most general definition.

Re: Learn You a Haskell for Great Good (2008)

#105

Post by codygman »

microtonal wrote: post #59
merijnv wrote: post #54

Earlier quoted context omitted.

I would not say that Haskell is currently ideal for writing native smartphone apps. It's possible and people are working on making it easier, but it's rough territory still. Javascript is easier, ghcjs (while still a bit tricky to install) is 1.0 and lets you compile arbitrary GHC Haskell (including all extensions, lightweight threads and STM) to JS for both Node.js and the browser. Template Haskell support is on the…

Lots of people complain about performance reasoning in Haskell being hard, which is partially true. But mostly, IMO it is simply different from doing so in C, so you need to unlearn/relearn all your performance tweaking skills. I don't agree. First, of all, the naive solution in C is often pretty fast, while the naive solution in Haskell often has obnoxious runtime properties. Then, most C optimization performance re…

> In the end, even something as simple as reading a list integers in the IO monad can be an exercise in frustration

Only if you need it to do it in less than 164616 bytes, otherwise I'd just use:

    replicateM 1000 (return 42)

Re: Learn You a Haskell for Great Good (2008)

#106

Post by SamReidHughes »

tomjakubowski wrote: post #83
pjmlp wrote: post #44

Earlier quoted context omitted.

Nice post. I just don't get the 2005 date, given the history of ML derived languages.

Sounds to me like he was just giving the year he first learned Haskell for context. Today there are a lot more mainstream languages that similarly make static typing cheaper.

That's right, I didn't know about ML at the time, I heard of Haskell first because of some Slashdot articles.

Re: Learn You a Haskell for Great Good (2008)

#107

Post by Retra »

bstamour wrote: post #80
Retra wrote: post #16

Earlier quoted context omitted.

I recommend this to anybody who wants to learn about Haskell's important data types: https://wiki.haskell.org/Typeclassopedia

I found the typeclassopedia to be really helpful after I'd been programming in Haskell for a few years. It really helped tie all of the types together, but a part of me thinks that it might be a bit overkill for someone who's just dipping their toes in for the first time.

I like that it builds up to monads by introducing functor and applicative first, as those are far easier stones to leap to.

Re: Learn You a Haskell for Great Good (2008)

#108

Post by wyager »

the_af wrote: post #77
thedufer wrote: post #71

Earlier quoted context omitted.

The point, I think, is that the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc.

Fully agreed that those are the easiest monads, far easier than IO, state and side-effects. But the post is still unhelpful, because how do List and Maybe relate to this: > A Monad is just something that has a bind (>>=) function and a return function. ? ( I know how they relate, but the above assertion is not a particularly helpful description of List and Maybe)

>but the above assertion is not a particularly helpful description of List and Maybe

Good. If my description of a Monad was a good description of List or Maybe, then I described Monads wrong.

Your complaint is like saying "Your description of a shape was not a helpful description of a dodecahedron." Indeed, a dodecahedron is a very specific instance of a shape.

Re: Learn You a Haskell for Great Good (2008)

#109

Post by the_af »

wyager wrote: post #108
the_af wrote: post #77

Earlier quoted context omitted.

Fully agreed that those are the easiest monads, far easier than IO, state and side-effects. But the post is still unhelpful, because how do List and Maybe relate to this: > A Monad is just something that has a bind (>>=) function and a return function. ? ( I know how they relate, but the above assertion is not a particularly helpful description of List and Maybe)

>but the above assertion is not a particularly helpful description of List and Maybe Good. If my description of a Monad was a good description of List or Maybe, then I described Monads wrong. Your complaint is like saying "Your description of a shape was not a helpful description of a dodecahedron." Indeed, a dodecahedron is a very specific instance of a shape.

Exactly. However, note I wasn't disagreeing with you; I was disagreeing with user thedufer that "the point" was that "the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc." (That's why I replied to him and not to you)

List and Maybe are indeed the easiest monads, but thinking about them in terms of (>>=) and return doesn't give a good intuition about monads, Lists or Maybe. So I think that wasn't "the point".

"The point" was actually that state and IO aren't the only monads, and that the definition is way more general than that. List and Maybe being the easiest monads is irrelevant.

Re: Learn You a Haskell for Great Good (2008)

#110

Post by laex »

davexunit wrote: post #75
laex wrote: post #60

Should I learn oCaml instead ? Looks appealing because companies like Facebook are using it create tools like Flow ( https://github.com/facebook/flow ).

Why do people choose programming languages based upon which big companies are using them? Learn a programming language because it is interesting, not because Facebook uses it.

Facebook is huge influencer in the open-source world. I don't see anything wrong with learning the tools/languages that it adopts. There are far smarter people working there.

In context of this question, It seems that learning both Haskell and oCaml is what people recommend.

Post reply on HN