While LYAH is a lot of fun, if you've gotten your feet wet with Haskell for a while and want to see some really powerful examples of "functionally solving problems" I cannot recommend more highly Richard Bird's "Pearls of Functional Algorithm Design"[0].
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.
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.
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)
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.
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.
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.
> 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"?
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?
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.
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?
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.
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.
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...
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?
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.
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?
FUD is fear, uncertainty, doubt. I corrected your statement by saying there is no reason for that particular fear, uncertainty, or doubt. I don't see how that qualifies as FUD. (I'm leaving this thread now.)
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.
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.
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.
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...