Functionally Solving Problems With Haskell(learnyouahaskell.com)
learnyouahaskell.com
Functionally Solving Problems With Haskell
http://learnyouahaskell.com/functionally-solving-problems
61 comments
Heartily seconded.
The majority of this book is also highly portable. The techniques can be applied across languages very easily, although, the Haskell implementations are very elegant.
I would say that's true in so far as your language you're porting to has a preponderance of pure functionality and notions of real mathematical "variables". Without those it'll be hard to get any semblance of equational reasoning to work out.
Thanks, it looks great.
I read the book a while back and it is absolutely fantastic. What I understand about monads, I learnt it from this book (no other exposition of monads ever made sense to me), and I particularly like his progression functors -> applicative functors -> monads. I think it's the clearest way to proceed (certainly helped me a lot anyways)
When I teach Haskell, I like to take a diversion from Applicatives to Monoids before going to Monads.
Understanding join is pretty valuable for understanding Monads too.
Understanding join is pretty valuable for understanding Monads too.
You can do Applicative -> Alternative and study Alternatives as Monoids of Applicatives and then lay on the difference between (<*>) and (<>) as producing a seminearring!
And then go study Monads because why not. They're kind of cool, too.
And then go study Monads because why not. They're kind of cool, too.
Actually you just reminded me that I need to explain sums and products in terms of a seminearring.
As a side-note, if you want to get into functional programming but don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES" world of Haskell, F# is another excellent choice for a beginner functional lang. You can program in either OOP or functional style, letting you take your time with the transition.
I also toot F#'s horn because it has an amazing resource for learning how to use functional style in your programs: http://fsharpforfunandprofit.com/site-contents/
A few pages on that site did more for me regarding functional programming than the entirety of LYAH did, and it also has a very nice monad tutorial: http://fsharpforfunandprofit.com/posts/computation-expressio...
I also toot F#'s horn because it has an amazing resource for learning how to use functional style in your programs: http://fsharpforfunandprofit.com/site-contents/
A few pages on that site did more for me regarding functional programming than the entirety of LYAH did, and it also has a very nice monad tutorial: http://fsharpforfunandprofit.com/posts/computation-expressio...
Also, if you don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES" style code, try Haskell. Imperative programming in Haskell is great! The language evaluation rules may be purely function, but your code doesn't need to be.
To provide an example of why this is complete and utter nonsense, BEHOLD, an example of imperative AND mutable programming in Haskell:
http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions...
http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions...
> To provide an example of why this is complete and utter nonsense, BEHOLD, an example of imperative AND mutable programming in Haskell:
It seems that 'this' here must not refer to the parent post (https://news.ycombinator.com/item?id=7538461):
> Also, if you don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES" style code, try Haskell. Imperative programming in Haskell is great! The language evaluation rules may be purely function, but your code doesn't need to be.
with which you seem to be agreeing. Perhaps it refers to the grandparent post (https://news.ycombinator.com/item?id=7537877), specifically to its implicit claim that Haskell programming involves "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES"?
It seems that 'this' here must not refer to the parent post (https://news.ycombinator.com/item?id=7538461):
> Also, if you don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES" style code, try Haskell. Imperative programming in Haskell is great! The language evaluation rules may be purely function, but your code doesn't need to be.
with which you seem to be agreeing. Perhaps it refers to the grandparent post (https://news.ycombinator.com/item?id=7537877), specifically to its implicit claim that Haskell programming involves "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES"?
Correct, I agree with anon_b and it's very obvious bsamuels hasn't built anything in Haskell.
> don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES"
I really like Standard ML in that sense. Unfortunately, seems to be fading away in sense of popularity.
I really like Standard ML in that sense. Unfortunately, seems to be fading away in sense of popularity.
Do you know any good guides to getting started with SML, as LYAH and similar allow one to do with Haskell? Also, can you recommend any particular implementation?
Not everybody uses Windows.
F# is a .NET language.
F# is a .NET language.
Heard about Mono?
http://fsharp.org/use/mac/ http://fsharp.org/use/linux/
http://fsharp.org/use/mac/ http://fsharp.org/use/linux/
Are you serious?
Care to elaborate on that?
I suspect that levosmetalo (https://news.ycombinator.com/item?id=7538317) is referring to the common perception (on whose correctness I cannot comment) that Mono has considerable drawbacks, a perception to whose existence a quick Google search will attest (https://www.google.com/search?q=Mono+drawback).
Use OCaml, it is open source, free and unux friendly. In fact, F# is an adaptation of OCaml for .NET platform.
F#'s compiler is open source.
The language can compile into CIL, javascript, and a handful of other build targets.
The language can compile into CIL, javascript, and a handful of other build targets.
"can compile into ... javascript"
I don't believe this is true, at least not easily.
I don't believe this is true, at least not easily.
Pit and WebSharper are two examples that can turn F# into JS.
Have you ever noticed that in every post about fp languages there is always a mention about using f#. I've never seen any language-advertisements at this level.
Have you ever noticed that in every post about fp languages there is always a mention about using Haskell. I've never seen any language-advertisements at this level.
Since I learned Haskell and it became my first language years ago, I was used to not be surprised by other language features. The "Haskell does it better" syndrome.
Anyway, I needed to do a small .NET work two years ago. I choose to try F#. It was the first and only time I got highly please by another language features. Actually, I've to admit that I was pissed of : F# may well be a better language than Haskell.
Anyway, I needed to do a small .NET work two years ago. I choose to try F#. It was the first and only time I got highly please by another language features. Actually, I've to admit that I was pissed of : F# may well be a better language than Haskell.
So what features sets F# apart?
The ones I've been envious of (as a Haskell developer) include .Net library integration, type providers, and active patterns.
Type providers when using a remote API blown my mind.
I'm sorry for my ignorance, but there's something about type providers I just can't wrap my head around.
It seems like the primary purpose of using a typed provider is so that the types (classes) can dynamically change during runtime (for example, you get different table objects for the different connection strings you pass in). But how do you program a client against an API that can change at will? Is your client code just basically doing runtime reflection on the data the type provider returns?
It seems like the primary purpose of using a typed provider is so that the types (classes) can dynamically change during runtime (for example, you get different table objects for the different connection strings you pass in). But how do you program a client against an API that can change at will? Is your client code just basically doing runtime reflection on the data the type provider returns?
My understanding is that type providers define the types at compile time.
As far as I can tell, Type Providers are just a slicker way of having external codegen tools. So instead of "SoapToVBCode.exe" you have it wrapped up in a type provider and can just do "type MySoap = SoapProvider<http://wsdl>".
It seems like a useful feature but far from the power of having full macros.
It seems like a useful feature but far from the power of having full macros.
Also on F# and functional programming two introductory video series from microsoft:
http://channel9.msdn.com/Series/C9-Lectures-Dr-Don-Syme-Intr...
http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Func...
http://channel9.msdn.com/Series/C9-Lectures-Dr-Don-Syme-Intr...
http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Func...
Did anybody else notice what is written on the upside-down calculator about 1/8 down the page?
Stuff like this is all over LYAH, silly hidden unrelated jokes. Read the tree in the Zipper chapter :-) http://learnyouahaskell.com/zippers
Also, be sure to read the tree with a pre-order traversal. In-order and post-order traversals yield a nonsensical string.
If you just want to play around with RPN a bit, I made a simple (regex-based) RPN calculating Perl script a while back:
https://github.com/dbb/math-scripts/blob/master/rpn_calc.pl
https://github.com/dbb/math-scripts/blob/master/rpn_calc.pl
Confused why a random chapter from the wonderful LYAH is on the top of Hacker News....
Yeah. This is annoying. I mean, I can't give an objective measure as to why this is a tragedy, but I feel like it is, you know?
Let's just all go through our favorite 3 year old books and post HN articles about every chapter that strikes our fancy why don't we?
Let's just all go through our favorite 3 year old books and post HN articles about every chapter that strikes our fancy why don't we?
If it actually strikes your fancy, why not? But I also don't understand why this specific chapter and what poster wanted to show us really.
I guess that's it. It feels very arbitrary and unfocused, and I question the specific value. I'd feel awful yelling "karma whore" in a crowded theater without proper evidence, but if it looks and smells like one...
Oh, I remember. That's where I stopped reading the book.
The link is a chapter from "Learn You a Haskell for Great Good", which I recommend a lot if you want to learn Haskell. However, if you click through to the table of contents, you'll see immediately one of my problems with Haskell as a language: guess in what chapter you finally get to write hello world?
main = print "Hello, world!"
Your problem with Haskell as a language is the pedagogical approach taken by the author of one of the books about it?
Hello World is mostly the most primitive program you can write in order to check whether your compiler/interpreter is working properly, so you can get started.
In case of LYAH (or Haskell in general) you have GHCi at hand, an interactive interpreter. That's what LYAH sets up in the very first chapter, and uses throughout the rest of the book.
In case of LYAH (or Haskell in general) you have GHCi at hand, an interactive interpreter. That's what LYAH sets up in the very first chapter, and uses throughout the rest of the book.
Another Haskell SPAM.
How can anyone seriously code in a language which introduces new kind of bugs which cannot be detected by any test until running in production on real data when it is already too late?
How can anyone seriously code in a language which introduces new kind of bugs which cannot be detected by any test until running in production on real data when it is already too late?
I don't understand what you said, but it sounds like FUD.
- Haskell does not have "a new kind of bugs". It's an ordinary programming language with ordinary bugs.
- The bugs you put in your program are not any more or less undetectable before production compared to unstable than they are in other languages.
- Haskell does not have "a new kind of bugs". It's an ordinary programming language with ordinary bugs.
- The bugs you put in your program are not any more or less undetectable before production compared to unstable than they are in other languages.
You're mischaracterizing a problem that you can encounter in Haskell as being unique to Haskell and intractable. You can leak space in effectively any language and just like in other languages there are tools and conventions to detect and avoid it.
Of course you can leak space in every turing complete language even on purpose, but in case of languages with lazy evaluation (like Haskell) you are no longer able to trivially reason about your programs behavior until execution on real data in real environment.
I agree that Haskell has some good (old) ideas and it is pleasant to Sunday programmers.
I agree that Haskell has some good (old) ideas and it is pleasant to Sunday programmers.
And again, if you play fast and loose with allocations you always shoot yourself in the foot. Carelessly allocating thunks on the heap is no different from carelessly allocating data in that regard. Haskell won't save you from yourself.
Judging from the other comments, it's clear you have an axe to grind. I'm leaving this thread as well.
Judging from the other comments, it's clear you have an axe to grind. I'm leaving this thread as well.
[citation needed]. Seriously, which kind of bugs are you referring to?
I am sorry, I fail to see a bug there which "cannot be detected by any test until running in production on real data when it is already too late". It's mainly problems with lazy IO which should be detected by unit tests using test data, right? The first answer is actually a nasty bug, but you should probably not deploy code which sends your test suite into an endless loop no matter in which language it is written.
Yes, Haskell does not solve all programming problems, but I don't see anything which could not be found by testing here.
Unit test will not detect everything. You need real data under heavy load for Haskell. This is a _fact_.
Most of you here should stop writing BS about Haskell and how it is going to save the world.
> I never said that. Your argument was that this is specific to Haskell which is not.
It is specific to lazily evaluated languages, especially Haskell. To test Haskell program you will need a real environment under heavy load - maybe Google or Amazon could afford it. Tiny unit tests which are perfect for strictly evaluated languages won't detect these kid of bugs.
Most of you here should stop writing BS about Haskell and how it is going to save the world.
> I never said that. Your argument was that this is specific to Haskell which is not.
It is specific to lazily evaluated languages, especially Haskell. To test Haskell program you will need a real environment under heavy load - maybe Google or Amazon could afford it. Tiny unit tests which are perfect for strictly evaluated languages won't detect these kid of bugs.
> Unit test will not detect everything.
I never said that. Your argument was that this is specific to Haskell which is not.
> You need real data under heavy load for Haskell.
How is this different from other languages?
> This is a _fact_.
Using "_" does not replace an actual argument ;)
> Most of you here should stop writing BS about Haskell and how it is going to save the world.
I fact, I wrote the opposite in the parent of your post.
I never said that. Your argument was that this is specific to Haskell which is not.
> You need real data under heavy load for Haskell.
How is this different from other languages?
> This is a _fact_.
Using "_" does not replace an actual argument ;)
> Most of you here should stop writing BS about Haskell and how it is going to save the world.
I fact, I wrote the opposite in the parent of your post.
All of the "Functional Pearls" papers are worth a read, but Bird's book is such a compressed, convenient, powerful collection of advanced functional problem solving style that I think anyone interested in "thinking" functionally should strive to read it.
It's not exactly for the faint of heart, to be clear. Bird's idea is that we can establish certain mathematical rules which allow us to transform "the simplest thing which could possibly be correct" to an efficient program through a series of steps, each one maintaining correctness as an invariant.
[0] http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...