It's the same course/series, but with interactivity, so Haskell can coded/evaluated from the browser. In fact, one "dir" up, you will find a bunch of similar tutorials here : https://www.fpcomplete.com/school.
I think I'm ok with it as long as they have permission/cooperation from the author (a cursory glance looks like they do; could be wrong), especially since the introduction of inline code evaluation makes it so much easier to get into. I know the content probably would have gone into my bottomless "to read later" bookmarks folder if I couldn't knock some stuff out right then and there.
Thinking about it, I guess that's just a licensing issue. Give the author the tools they need to decide how their work can and can't be used.
School of Haskell is actually a website where people can create their own tutorials, so most likely the author added it themselves. (EDIT: I just checked, they were created by user Yann Esposito, which most likely belongs to the author.)
Furthermore, while FPComplete are commercial, I don't believe they're monetising SoH in any way, other than its being good marketing for the company and Haskell in general.
I thought it might be something along those lines. Just didn't have much time to look around.
I would say, though, that it should be (and really is) up to the author where their work can or can't be displayed.
I think it would be good for the community either way, but if an author doesn't want their work in any way tied to a commercial interest, then it's their right to apply licensing in such a way to ensure that, and for others to respect that (though I'm not saying you're implying otherwise; just clarifying).
The monetization here would be brand exposure and site traffic to the domain/website, using the works of others (which I'm not inherently against).
I think it is awesome. It makes the simple stuff dead simple (get a decent IDE with one-click web-deploy integrated up and running in <5mins, with an example app); while the hard stuff is still as easy as it was before (you can deploy to your own hardware, using your own desktop text editor and local compilation).
You say "serious", that's a strechable concept. But if serious could mean: doing some green-field web app consulting gigs (which can make serious money); then i think it is already-ready for "serious".
Then considering they are such a young company -- I'm really interested where they will head for :)
I think Haskell Center will turn out to be a game changer, a next-gen development environment (that graciously degrades back into old-skool native code producing DIY deployed stuff).
The latter author decided to write the book based on his experience in learning Haskell. It's definitely one of the simplest and clearest programming books I've read.
The amazing thing is that Miran is writing in his second language -- yet his command of idioms and obscure US cultural history is unequaled in any other programming book I've ever read.
Yeah, I got bogged down in monads, but I've promised myself I'll finish it this year. Learn Yourself a Haskell[...] is extremely well-written and entertaining, so it deserves completion.
All the resources I've seen for Haskell start the same
They are insanely easy to follow at the start, so simple that even first time programmers won't have much trouble following. Then the type algebra hits and everything goes out the window.
I've made 3 attempts to get through it. I can even see situations in my work where monads and monoids may very well be applicable. I still can't work with Haskell, nor get through any resource that discusses them.
It's possible I'm an idiot, but I suspect my co-workers would fare worse, and it damns the language in my book.
It's possible I'm an idiot, but I suspect my co-workers would fare worse, and it damns the language in my book.
No, you're definitely not an idiot. Haskell's type system is a completely different language, semantically speaking, from its language of terms. This type language is much more like a logic programming language than a functional one. Type variables are unified by the type inference engine, a concept with which most people are unfamiliar. Type constructors are easily mistaken for data constructors (they often use the same name). A lot of Haskell tutorials gloss over these details which is unfortunate.
Please don't get discouraged. Once you start to grok the type system you'll be amazed at how powerful it is. It's pretty incredible how well it works at inferring all the types and catching countless errors. The oft-cited claim that Haskell programs "just work" once they pass the type-checker is true in the vast majority of cases. The amount of work it saves you by not having to write (and maintain) unit tests is staggering.
I'm familiar with the argument that strict typing catches bugs, but some bugs are trivial and a few are very tricky. Based on my experience with languages besides Haskell (which I don't know), I suspect that the kinds of bugs computers catch automatically aren't likely to be bad ones. The bad ones are runtime errors and logic errors, and I guess there are two kinds of these: ones that come from sloppy coding, and ones where you made an error in thinking. The type-checker might help with the sloppy ones. But I think the best language defense against those is to be concise and readable, so the logic is easy to see and you don't lose the forest for the trees.
That's just the thing: Haskell's type system catches many, many bugs that would be runtime errors in most other languages. It can even provide static guarantees against extremely tricky bugs such as race conditions!
sloppy coding
Everybody is guilty of sloppy coding some of the time. Having a powerful sanity check against it is extremely helpful.
ones where you made an error in thinking
Haskell can actually help here, too. Its rigid purity forces you to think more carefully before you act and its powerful expressiveness enables you to build highly composable abstractions that are simply not possible in other languages.
Edit: Check out this talk on someone's personal experience with static typing in real projects at work:
I very rarely have much trouble finding bugs that I made myself. The hardest bugs are the ones somebody else had a hand in. I'm sure everyone wishes they could force their coworkers to be more careful. :)
In college I was required to take a course using SML (which has a type system that is sort of like Haskell's I think; Haskell's may have been based on it). I was not all that academically driven that semester, and I was kind of taken by surprise by how hard the language was, once I started doing the later projects, and I barely got through the course. That was my only exposure to functional programming until after college, when I wanted to make up for that and I undertook to learn Scheme. I didn't have much trouble with Scheme, and the functional concepts I'd heard about in the course finally made sense. If you're trying to learn the functional style, I don't see the point in learning at the same time a complex type system. The type system isn't a natural consequence of functional programming, it's something that's not really related but adds a lot of difficulty.
I don't want to start a flame war, but I view types as being sort of peripheral to the task of getting the computer to do things. If type systems are getting in the way of programming, priorities are getting mixed up.
Type systems aren't supposed to "get in the way of programming". Instead, they are supposed to assist you, and they do. This is why there is the perception that, for instance, code written in languages like OCaml commonly turns out to be correct once it compiles correctly. It's certainly not the case that language designers deploy a complex type system to make your work harder.
I don't question that they're created with the best intentions, but the most important thing is the end result, not the programming language. And well-intentioned language features don't always work out like they're supposed to.
That's why I love Typed Racket - it's powerful and expressive, yet completely optional and integrates seamlessly with untyped code. It helps that Racket has the best support for contracts I've seen though.
A lot of aspects of programming seem very very difficult until they click. Recursion and pointers are the canonical examples for basic programming. Although I'm still on the same side of learning Haskell as you, I think these things can be grokked by non-geniuses given enough practice and determination.
All of it makes much more sense if you use Haskell more. For example, when you're trying to write some program that works in an inherently stateful fashion, as a beginner you usually pass state as an additional argument to your function, and return it as additional result. Then, when you learn about State monad, everything clicks into place.
Ok so here's the problem I'm having with trying to get into Haskell, and it's a problem Carmack identified: there's way too many "toy examples" out there.
I've always learned languages because I need them for something. C/C++ because I wanted to write a game. Python because it's the complex scripting language of choice in Ubuntu. JavaScript for obvious reasons.
What I really really need is something which walks me through doing something significant with Haskell - like, a GUI app on Linux or something (my current focus: I've never really done it, but if I'm learning something new I'd like there to be a practical product at the end).
A bunch of language constructs, while technically interesting, don't help me to grok the language at all.
I am not sure what you mean. Tutorials can only deal with toy examples. Once you understand them, then you can (and you should) write bigger projects. About Carmack, that's exactly what he did, he implemented Wolf3D in Haskell to have a real impression about Haskell. (Assuming you're talking about this video where he discuss functional programming for games)
I guess he's just as tired as I am of seeing (yet another) quicksort implementation in Haskell!
99% of the time I spend coding does not deal with data structures or algorithms, but basic business logic.
How does Haskell perform there? I don't know, but I know Haskell's quicksort oneliners are pretty (and pretty meaningless too).
I know my way around monads, I'm fluent in functional programming and grasped typeclasses... but I still can't see what's so great about Haskell beyond algorithmic beauty. I'd really like to be taught real-world-Haskell just like I was taught real-world-Lisp.
Well, I would argue that this article really is an introduction to functional programming using Haskell.
Most of the concepts he/she introduce are not specific to Haskell but are more or less specific to functional programming languages.
But the author doesn't seem to be very well aware of that.
Quoting the article: "Haskell is very different. The language uses a lot of concepts I had never heard about before."
All that to say that if you already know some functional programming this probably isn't for you.
Don't get me wrong, I don't think that most Haskell tutorials are inherently bad, I just couldn't find a good introduction to Haskell targeted at programmers which are already familiar with functional programming concepts.
GUIs in haskell are currently a hot topic. Some of the older libraries like wxHaskell are a bit behind the times and need updating and the newer ones are very new and need vetting. If you're interested I'd check out threepenny-gui or learn opengl and use GLFW-b with the opengl bindings and write your own. #haskell and #haskell-game on irc.freenode.net are great hubs for gui related talk.
Paul Hudak's "The Haskell School of Expression" (http://www.amazon.com/The-Haskell-School-Expression-Programm...), while it doesn't lead to a finished desktop application, does go deeply into its motivating example of building an animation library and a GUI for displaying and interacting with animations. (It also applies the techniques developed in the animation library to music.) It's not a "practical product" but it is "doing something significant," and much more than "a bunch of language constructs."
Not a tutorial but a video, but here's Anthony Cowley talking about using Haskell for machine vision, hardware, and robotics. In the first 5 minutes he writes Haskell code, proves it bug-free using a few tests via a Satisfiability Modulo Theorems prover, cross-compiles it to C, starts up a web server for debugging, then throws it on an Arduino.
Then he proceeds to run some basic vision filters in realtime using OpenGL, OpenCL, and OpenCV all together just to show off all in under 150 lines.
Then after that he talks about how his team built a robot doing realtime grasping and lifting of non-uniform, unpredictable, difficult to grasp, random dollar store objects that are coming at it on a conveyor belt moving at 33cm/sec. The visual processing all in Haskell from the noisy sensor of a Kinect.
The examples aren't immediately there to follow as it's not a tutorial, but it's a good look into the space of some real, complex hacking going on.
Real World Haskell is the go-to resource for beginners
http://book.realworldhaskell.org/read/
By well known Haskellers bos, dons, goerzen.
Free online. Once LYAH whets your appetite exercises and real programs are needed.
Spoiler alert: you can't really get anything signifant+useful done with that book, because Haskell is a language where only experts can get anything significant done.
I have to strongly disagree on that point. I'm certainly not an expert (I hadn't done any meaningful programming in 10 years prior to reading it), and I found Real World Haskell immensely helpful in building a production system that receives and processes security events.
In fact, the chapter on building a Syslog server was incredibly useful, as the first piece of the system I'm building processes events which look a lot like Syslog (with some JSON embedded in the messages).
I will say that I had a hard time getting through the book as my only Haskell book. I ended up using Hutton's "Programming in Haskell" as a supplemental resource (selected mostly because it's a very small book).
How much interest would there be in a 0 to full Haskell development environment set of ansible scripts (and or Vagrantfile)? I'm working on a start up using Haskell at the moment and I've been capturing all of my set up in this way. If folks are interested I can make some of this stuff available.
Yes, but I'd be more interested in how you put it together than the end product. A good blog post breaking your process and components down would be fantastic.
Emacs config. Latest versions of cabal cabal-install. A work around for the brokenness of the Haskell platform on ubuntu 13.04. Threadscope. Proper cabal setup for testing. Jenkins setup for CI from the start.
Also investigation dockerizing Haskell services too.
I'd be more than interested to see what you got. I want to introduce Haskell to our production soon, but am still not sure about the whole process of managing it at scale. This would definitely help as an info if nothing else.
Yes, this would be very interesting. I'm trying to put together something similar for a Haskell environment for NixOS. It should be easy, but less versatile.
"Instead of being in your way like in C, C++ or Java, the type system is here to help you."
I'd still say the type system is there to help you in C, C++, and Java, it just doesn't do nearly as good a job of it, and winds up in your way more often because it's less expressive.
I'd still say the type system is there to help you in C, C++, and Java, it just doesn't do nearly as good a job of it,
Are you sure? :)
Couldn't match type `b0' with `Step Builder IO a'
because type variable `a' would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context: Enumerator Builder IO a
The following variables have types that mention b0
[...]
I do love Haskell :) and usually the type system is there to help you.
I'd go as far as to say it doesn't get in your way at all except for verbosity, I just wish it were better and could do more. I'd love for the type system to prevent null pointers.
Learning a functional language is a great idea especially if you never intend to use one after you've learned it. It's like speaking a second language. Has a great effect on the understanding of your own language.
At university the first thing everyone had to (in programming) do was a Haskell course. Felt weird at the time, but in hindsight it was fantastic. It meant everyone had to throw their preconceptions about programming out the window.
It didn't occur to me until recently (10-15 years later), that functional concepts are actually a good thing to apply in any language; that it makes code parallelizable, modular, maintainable, testable, and so on. I just thought functional was functional (i.e. elegant but hard) whereas imperative was imperative (inelegant but easy). Much like the difference between algebra and arithmetic.
So go learn a second language, or even a third. Even if you intend to speak english and Java for the rest of your life. I'd choose Haskell and Spanish.
Pretty awesome, I've steered clear of Haskell preferring Scala instead (easier syntax for me to grok), but this tutorial makes Haskell far more accessible.
Off topic but does anyone know of a Rails/Play + Linq to SQL/ScalaQuery equivalent in Haskell?
Beyond that just being able to generate PDF invoices, send out emails and have access to a decent date/time library (like JodaTime) would cover the essentials for web development.
We have a fairly decent date time library in time (http://hackage.haskell.org/package/time) but I don't know if that matches JodaTime (because I don't JVM libraries). For PDF generation I'm actually not sure at all - but have a search on http://hackage.haskell.org and there may be something.
Thanks, I did check out Yesod and HaskellDB a while back when I was researching ways to escape from Grails hell (i.e. pre grails 2.0). Yesod looked promising, HaskellDB, not so much (IIRC was developed in early 2000s and not actively maintained).
Definitely not interested in going back to string based SQL after working with ScalaQuery for the past couple of years.
Anyway, the thrust of the question was, can you do full stack web dev with Haskell. The answer seems to be yes, but you have to dig around a bit.
Would be a fun side project to hack together a site in Haskell, definitely a fan of the type system
For anything other than trivial queries ScalaQuery/Slick generates very bad SQL. I'd like to use it but generating deeply nested sub-queries when simple joins would suffice is totally unacceptable.
The PostgreSQL query optimizer can fix them in the simple cases but the MySQL and Oracle optimizers can't and it causes performance to drop off a cliff. HaskellDB suffers from a similar problem.
> For anything other than trivial queries ScalaQuery/Slick generates very bad SQL
For Slick, yes, but for ScalaQuery 0.10, absolutely not.
All of my ScalaQuery generated SQL is semantically _exactly_ what I would have written by hand, and completely typesafe, with generated prepared statements to boot. This includes outer join based queries, subselects, and other operations that cause Slick to generate nightmare SQL (why I'm avoiding Slick until the library is stable on the performance front).
I love ScalaQuery, but Slick, TBD, they have a ways to go yet, the new Scala collections syntax with groupBy and sortBy is particularly hideous compared to ScalaQuery's SQL based groupBy and sortBy.
The Slick team will sort things out, hopefully sooner rather than later (for example, I'd love to have Slick 2.0's composable parameterized query snippet functionality, that alone is a huge boilerplate WIN).
That's one of the reasons why being on the JVM with Scala, Clojure, etc. makes one's coding life simpler: huge ecosystem to draw on with minimal effort (i.e. rarely need to roll your own).
Generally immutable (supports mutable state for some edge cases) along incredibly rich functionality covering everything you could imagine needing time-wise, and does so concisely.
It's a godsend given the built-in Java alternative.
In Haskell, Yesod felt Rails-like to me; take a look at the scaffolded site example according to the instructions at http://www.yesodweb.com/page/quickstart - it takes just a few minutes and if you take a look at the sample site and the code for the root page, it should give you an impression on what's its style.
ocharles covered pretty much everything else but for PDF generation I would look into pandoc, the Swiss Army knife of document conversion. It can be used as a standalone program or as a Haskell library.
I find Haskell's to be relatively simple, while Scala's seem to be all over the place. Probably not weird since Scala tries to straddle 2-3 different worlds/paradigms.
For the general case I'd argue that Scala's syntax is far easier to sort out for anyone coming from C-based langs.
However, yes, for complex type hierarchies, heavily curried functions, and other higher level approaches, Haskell obviously wins, equivalent Scala code is a mess in comparison.
Odersky recently tweeted an EPFL paper addressing simplification of the type system (that got Scala FP devotees up in arms); i.e. in the not too distant future we may have fewer ways to do the same-ish thing (a good thing, IMO, if the language can be trimmed down, at a minimum that bodes well for current portability issues).
> For the general case I'd argue that Scala's syntax is far easier to sort out for anyone coming from C-based langs.
Before I learned about either, I had most experience with Java. Though I'm biased since I learned Haskell first (and I wouldn't say that I 'know' Scala).
ASIDE: I've been using learn you a haskell for great good!http://learnyouahaskell.com/, and found it helpful, insightful and the examples nicely paced so you can treat them as exercises as you go.... up until the module chapter, which is more like a reference, very long, detailed, tedious. I got up to here
http://learnyouahaskell.com/modules#data-char (check out how small the scroll bar slider is on the right - this is a big chapter).
yeah, it's definitely more of a reference. Personally, I just skimmed through it and moved on. The purpose of a chapter like that is to give you a rough idea of what's out there. When you'll actually need something, you'll be looking it up anyway.
Just move on to the next chapter if you find it tedious. The book goes back to the original style in the subsequent chapters.
Word of warning, though. While this article looks pretty decent it's skipping over lots of tiny details that are covered in LYAH, which may lead to annoying gaps in your knowledge/understanding later.
PERFECT. Relaxed but intense. Perfect! ... for me. This is exactly the kind of tutorial that works best for me. (I'm sure many people will find it unusuable. But that's OK - we have as many ways to learn as we have learners.)
NB: if you're trying out haskell and you're on a mac with xcode 5, you'll be hitting some weird CPP related errors due to GHC 7.6 and older not playing nice with Clang's CPP.
I shared a number of work arounds with the general haskell community a few weeks ago here: http://www.haskell.org/pipermail/haskell-cafe/2013-September...
(there are alternative work arounds, but I only listed the ones which are simple and easy to communicate with other people and be able to expect them to follow the steps correctly.)
I have been wanting to look into Haskell for a long time now. Never really got the time. Also the syntax was a bit off putting.
Just skimmed through. I see that there is a bit of Javascript and C in the code too as reference matertial. Most people dont like such a way of teaching but it looks like the tutorial isnt really trying to teach Haskell in terms of Javascript or C. Really makes me want to look into this. Thanks for putting the efforts.
I'm a bit surprised that you say the syntax if offputting, most people I've met say otherwise. Could you point to something you specifically don't like?
I didnt mean in a sense that it sucks. Its way different from the traditional C style or Lisp style syntax that I've used. Regardless of whether it is good or bad, it would have taken me some time to adjust to it and I never had that kind of time.
Also as someone who doesn't know Haskell at all, I have great difficulty reading Haskell. I dont think I would have that kind of problem reading a language with a more traditional syntax.
Thank you. That is some good way to look at it. I think people here assumed that I hated haskell or something. This breakdown actually makes it a lot clear to me. Thanks :)
I think some folks are misreading your comments a bit as an indictment of the language. I read it as saying, "Haskell doesn't have syntax that's similar to any language I know and that means I have to learn something I don't know, which takes time, and I don't have a lot of time."
Personally, I'm with you. I've used other functional languages (F#, clojure, erlang), I'd say I'm pretty familiar with a lot of the ideas Haskell uses (comprehensions, partial application, anonymous functions, pure functions, pattern matching) and I actually really want to learn Haskell, but I have a hard time intuiting the meaning of a lot of Haskell syntax just based on other syntax that I know.
I also realize that the syntax probably fits the language very well, which makes sense, and that it's a good thing. I wouldn't want it to compromise it's purity for familiarity. Just makes it more work to learn.
I'm with you, but you do get used to it. Basically if you just get your feet wet writing a few semi-significant programs in Haskell (e.g. a parser, which is a very common and pleasant task in Haskell), then you'll get familiar with it. The biggest hurdle for me came from being able to understand do-syntax (which is a bunch of applications of monadic bind).
Hah! yes. Maybe I should have put it the way you did.
My view of Haskell is the same as a non-Lispers view of Lisp. Cry about too much parens and it making things difficult to understand. Doesn't mean the language needs to be changed. I am all in for learning Haskell although most introductions to haskell are really time consuming and dense, so I never just did it. Which is where I was really glad that this tutorial was put up.
Hating any language which actually does serve its purpose is pretty stupid. If anyone actually has some issues understanding a sightly different but very well respected language, then the fault is mostly with that person and not the language.
I think lisp is a really good example for how I feel with haskell, and one I'm more familiar with.
When I first started learning lisp, the syntax was foreign, and while lisp syntax is arguably really really simple, composition with that syntax is a little weird if you're not used to it. Yet, at the same time, the syntax is a fundamental part of the language, especially with respect to homoiconicity, simplicity and macros. It was a time-sink to get used to it, but totally worth it.
Also as someone who doesn't know Haskell at all, I have great difficulty reading Haskell. I dont think I would have that kind of problem reading a language with a more traditional syntax.
Right, but then you'd lose the benefit of Haskell being a very different language. To implement Haskell using C-style syntax would make it extremely awkward to make liberal use of Haskell's powerful features. In particular, Haskell's syntax is optimized to make fully/partially applying functions as quiet as possible. This really shines in conjunction with the ability to define your own operators -- including their fixity -- so you can wage an all-out assault on parentheses!
Oh dear lord, you misunderstand me. I dont want to implement Haskell in C-style. Haskell is good being haskell, I just had difficulty understanding it and never had enough time to dive deep into it. But now I may.
That's good of you. This problem (familiarity) plagues many upstart technologies. Taking the generality even further, it could be argued that the status quo bias is one of the most difficult-to-overcome aspects of human nature and that its effects on society are extremely widespread.
Do you know any other functional language? If not, it's a problem not with syntax (Haskell syntax perfectly fits its semantics), but with what is actually going on in the program. Without firm grasp of FP concepts (recursion, currying, partial application, abstract data types, etc) almost any Haskell code seems to be alien.
I find a lot of people complaining about Haskell syntax without understanding how deeply different this language is from "usual" languages.
I think the problem might be also things that look like syntax to somebody who is not used to Haskell, but are just usual functions like ($) (<*>) ($!) and whatnot.
I really wish Haskell syntax was extended to allow special forms ("case", "do", etc) to be ordinary function arguments and not just infix function arguments.
This would remove a significant portion of the $ signs in Haskell programs, as so many of them are just padding for "do", "case", etc.
Yes I do know FPs a great deal. I DO NOT harbor any kind of hate towards Haskell, just never found it easy to understand(or read, to be more specific). Also this link makes me want to learn it more than ever now.
The syntax has more in common with Python than anything else I know of--it seems pretty readable to me.
Now the structure of Haskell is going to be very alien if you're used to imperative languages (C, Python, what have you). You mention Lisp, so that should give you as good a background as anything else in terms of reading Haskell code.
The syntax is much closer to Lisp than C, really. The main differences from Lisp are lack of macros (so slightly more actual syntax) and function application (in particular infix functions). Most things you see are functions.
There's a lot more syntax to learn than in Lisp, but it is IMO the best designed syntax of all languages I've used prior to Haskell. It is much less noisy and less painful than the C-family syntax.
I do remember it being so different was an obstacle for the first couple of weeks of learning Haskell, and even being grumpy about "why did they have to choose a syntax so foreign" at that point :)
Minor nitpick: Using pattern matching instead of `if xs == []` is not just to make code prettier and cleaner.
First of all, you should be using the `null` function instead of `== xs` because the `==` operator only works if your list contents are Eq-able.
But the most important thing is that pattern matching is more type safe. If you use `head` and `tail` you, as a programmer, need to make sure that you only call them on a non-empty lists or else you get an error. On the other hand, if you use pattern matching the compiler helps you make sure that you always covered all the possible cases (empty vs non-empty) and you never need to worry about calling the unsafe head and tail functions.
I really like the art images in the tutorial. Nice touch.
Although I am not sure about the premise - I doubt Haskell, as a language close to mathematics, can be learned fast. This tutorial seems quite shallow on some things, like monads.
It does sort of bail on you instead of explaining what monads are. A couple of examples of monads is not the same as understanding what the underlying abstraction is. That said, it isn't hard or long to learn monads. A monad is something that can be mapped over and concatenated.
> That said, it isn't hard or long to learn monads.
I am not sure any definition does that justice. It's similar with concept of recursion - it's easy to define (function calls itself), but to put it into programming practice (writing all loops as recursion), that's a lot harder.
Then I started reading http://www.haskell.org/haskellwiki/All_About_Monads but didn't finish it yet (I was playing with Haskell, just figuring out how to structure the application). IMHO, unless you understand all that, how to put monad concept into practice, you don't really know monads.
I'd like one of these beginner tutorials to have a chapter named, "learning cabal and using a library". That was a pain point for me (especially developing on windows). Well, not so much a pain point as a mortal wound.
Okay so i completed this tutorial in about 5 hours , gave everything due , but still i only understand like 30 % of it and that too of the starting part.
How is that weird, it's just uses the increment from the first to second value as step and repeat as long as it's smaller than the end value. Python does the exact same thing:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> range(1, 10, 2)
[1, 3, 5, 7, 9]
> Someone needs to make a 'Haskell: the good parts' or at least a lint.
Someone needs to write a book about the good parts because you haven't learned the language? It's documented right in the Prelude[1] what this desugars into.
Are you implying it's complex? Because a lot of languages have list comprehensions[1] (list comprehensions are awesome!). Haskells is very close to the mathmatical set-builder notation[2].
It's the same course/series, but with interactivity, so Haskell can coded/evaluated from the browser. In fact, one "dir" up, you will find a bunch of similar tutorials here : https://www.fpcomplete.com/school.