Contrary to some of the other comments appearing, for me this kind of thing is excellent. The biggest mental hurdle I find myself facing when learning new languages and having got beyond the "hello world" stage is "how do I go from here to structuring an app?" An opinionated prescriptive guide is what I need then. When I know more later I can choose to go against the grain if I feel I understand the risks, but structuring projects varies a lot, and being helped to find the idiomatic way is great. It's a whole class of problem I now can ignore and concentrate on the design of my code.
It was a while before I understood how Erlang project structure worked. But I knew where to look. Ditto when I try things like Scala and Clojure (as I'm no longer familiar with Java, really). This is a good and useful step.
This is exactly my feeling. I'm always surprised that it seems like no books or tutorials ever cover this area, the only way to find out is to dive into github and look through actual projects. Especially when I was newer to software I would have really appreciated a chapter in most books saying "oh and here's how we lay all this stuff out in the real world", I still really appreciate this since each language has many of it's own idioms. I'd been hoping to make Haskell a more 'real world' language for me and this will be a great place to start
> An opinionated prescriptive guide is what I need then.
Indeed; it gives the default values for lots of things in the program / build environment / revision control, etc.
One might of course later decide to change some of these settings, but one can be sure that none of the default settings are outright insane or likely to lead you up the garden path.
I suspect one of the reasons Lisp hasn't broken out of being a niche language is that there is no default value to the question: Which Lisp shall I learn/use?
That assumes that Lisp is a (singular) language. Lisp, to my mind, is a family of languages of a certain type, much like the statically-typed functional languages are a family. Choosing one Lisp over another is not like choosing which C compiler to use, it's more like choosing whether to use Python or Ruby.
OK, let's say I decide to use Common Lisp. Then I have to decide what implementation to use. There isn't a default one like there is with Python or Ruby. Whichever one I choose, how can I know (and remember at this point I don't actually know CL) what libraries it has, what quality they are, whether there are libraries that work on other CLs but not this one, what debugging tools are available and what quaslity, whether it will work on the OS I use, whether it will work on the OS I will use in 5 years time (and I don't know what that will be), whether there are any other pitfalls with my choice, etc. For me to be sure I've made the right choice, I'd have to do weeks or months of research, including trying out the major varients.
Fuck that. If I do learn a Lisp it'll be Clojure, because there's only one implementation.
In case anybody is wondering, here's some information about Common Lisp that should make it easier to get started.
Use SBCL; it's the most common and well-supported implementation. It works fine on most OSes (and has done so for years, and will continue to do so for the foreseeable future), though it's a bit dodgy on Windows. If you're using a Unix (including OS X), you'll be fine:
The place to look for libraries is CLiki.net, and if you'd like to get started with minimum effort, then Quicklisp is exactly the library collection you're looking for:
Quicklisp has all the common libraries, with easy installation and dependency management.
For editing and debugging, it's hard to beat slime-mode in emacs. It's very slick and pleasant to work with. (Incidentally, this is also the most common way of editing Clojure, but it works more smoothly with Common Lisp. Much better stack traces, for example.)
I'm enjoying using Clojure right now, but please don't be scared away from Common Lisp. It's got a lot going for it.
I liked the article, but it's very much not about "How to write a Haskell program". It's about how to create and distribute a Haskell project.
"How to write a Haskell program" would be much higher level because the joy (and challenge) of Haskell is that composing a program is really a process of composing functions or monads and the interactions can quickly become non-trivial (though, unlike OO systems, the interactions are generally visible). Whereas writing "Hello World" in Java can actually get you started in Java, writing "Hello World" in Haskell gets you just about nowhere ("But it introduces you to the IO monad!" <giggle>).
I honestly think that the title of this article is a misnomer and probably the cause of most of the negative comments.
"writing a program" is probably mostly associated with the mental process whereas "creating a project" is about the mechanics and the article is clearly describing the latter.
Your question intrigued me, so I ran a quick script against the current Hackage database (the list of packages you download from Hackage when you run `cabal update`). Here are my results:
Two libraries didn't list their license in their .cabal file. One of these is (from looking at their license file) available under a simple permissive license; the other doesn't make it clear.
I've tidied it up and added some comments explaining what it does. The only dependency outside libraries which come with GHC is the 'text' package, which is included in the Haskell Platform.
I wonder how much this has to do with BSD3 being the default license when you use the "cabal init" command to generate a project skeleton. Most people probably don't care which open source license they're using; of those who do care, it's generally GPL versus everything else.
I don't think it has much to do with "cabal init". I've used Haskell and noticed that most libraries are BSD3, so I make my libraries BSD3 also. I did not know that there was such a thing as "cabal init" until just now :)
Over in the Perl world, most libraries are GPL2/Artistic, so I follow that convention. In the end, I would probably prefer the MIT license for libraries... but following convention seems better than setting my own.
(For applications, I go with the GPL3 because it's not going to inconvenience anyone and it provides the best protection of free software. But people are just going to skip your library if they have to relicense their project, so I find that the GPL is not particularly appropriate in that case.)
For me it's a conscious choice. On general principle, I think that open-sourced library code at least should almost always be BSD-licensed. Furthermore, there are many good libraries on Hackage which I might well want to use in a commercial product some day, and a BSD license will make that easy, no matter where my code ends up running. Releasing my own code under the BSD license is therefore also a small gesture towards maintaining this state of affairs.
I barely know the basics of Haskell and this is very easy to understand.
This is supposed to show you which tools you should use, how to organize and publish your project. This tutorials does this quite well.
If you want to learn Haskell read http://learnyouahaskell.com or something similar, it explains the language and how to build a simple program using GHC, if you do anything more advanced you should start reading the documentation of your compiler anyway.
I deleted my comment because I couldn't get the tone quite right.
The gist of it was that this article reflects a certain mentality... along the lines of starting to learn how to drive by reading about the physics of internal combustion engines. That's hyperbole and the article clearly doesn't go that far, but it seems to be a bit neither here nor there; it's not a tutorial like 'learnyouahaskell' nor is it simply a reference for useful haskell tools.
It's an overview of the process of writing a program, covering program and file system structure, build tools, libraries, testing, and revision control. It's not "simply a reference for useful haskell tools" because it has a normative aspect: it says, "This is the way things should be done." It's the document to read when you understand the language well enough to write something larger than a single file solving a Project Euler problem, and want to know what the best practices are in writing a library or executable that could be—for example—published on Hackage or used in production. And while it's not perfect in its presentation, it actually does a pretty good job of what it sets out to do; it was certainly helpful to me when I was in that situation.
The tutorial is valuable, I think, it's just that the title implies it's something else. The value in the tutorial is that it lays out the standard way to organize a Haskell project that you plan on sharing with other people in the Haskell community. It's not, as the title implies, a tutorial on writing in Haskell.
It's more like learning how to take care of your car based on common habits of owners of well-maintained cars.
The guide doesn't even sort of mention how to think/create using Haskell. It also doesn't even sort of dive into real Haskell magic like how Hindley-Milner type systems work. It's tangential to both.
I agree. I don't know Haskell but this guide sure turned me off of it. They seem to try and do their best at showing the most complicated and unappealing aspects of the language. Even the basic HelloWorld program demonstrated is weird and long and I get the feeling that Haskell is convoluted and not worth it.
You're missing the point. This is not meant to be an introductory tutorial explaining the language; it's a guide to best-practice Haskell development, giving the reader an overview of the basic toolchain and how to use it. Please see my response to davidw's comment for a more complete articulation of this point.
long? There's 1 import statement, 1 optional type declaration, and 2 lines of code. It could be just the import and 1 line of code, but that would violate 2 Haskell best practices: include explicit type declarations for your public interface, and separate pure and impure functionality.
Honestly, if the intent were to be pedagogical in this specific regard (which is isn't), I would say that the example is unnecessarily terse (which is why you describe it as "weird").
I wouldn't judge Haskell by this guide. It just made me smile a bit as it seemed to put the cart before the horse, as well as the guy who made the cart, and the people who made the road.
I'm a bit baffled by this response. If you go to the front page of haskell.org there is a 'Learn Haskell' section with six links. This is not one of them. Nowhere in the article does it claim to be a beginner's guide to Haskell. It doesn't make the mistake you attribute to it; this is entirely a projection on your and others' part.
Why do you think I'd make that projection from an article called "How to write a Haskell program"? The title has two meanings, and you are seeing "how a Haskell program ought to be written", whereas other people are seeing it as a tutorial that explains... well, "how to write a Haskell program". And there are definitely some steps in there, it's not merely a set of guidelines. So I think the second interpretation is not entirely unexpected, since the link goes directly to it with no explanation for those of us who are not familiar with Haskell, rather than, as you say, to the front page of Haskell's site.
That's where I'm getting the "neither here nor there" from. I have no axe to grind with Haskell, and indeed counseled the other poster to not be put off by what he (and I) mistakenly thought was a poorly done tutorial.
Titles invariably fail to capture the entire content of the article they introduce; if they succeeded, there would be no need to write the article. Perhaps this particular title is problematic because it is apparently confusing outside its original context of presentation, as part of a corpus of Haskell guides on the haskell.org wiki, linked to (for example) by other articles dealing with prerequisites to this one, such as learning the language. However, in its original context it makes perfect sense and the meaning is clear.
If I had submitted the article here I would probably have changed the title in an attempt to impart some of that context. The purpose of the article, though, is consistent, and the execution is reasonably thorough. My confusion about your reaction stems not from the assumption that the title perfectly encapsulates the intentions of the article—it doesn't—but from the fact that you apparently made no attempt to understand the original context of presentation, instead going on about it putting the cart before the horse and generally making all sorts of (incorrect) presumptions about the goals of the authors and its place in the community documentation generally.
I agree it's not merely a set of guidelines; I said it had a normative aspect, not that that captured the entirety of its purpose or content. It's a guide: the concept could be summarised as "Here's the way we write Haskell programs, we think these processes and tools are broadly speaking a good idea, and if you follow them you won't go too far wrong."
In other words, it's "How to write a maintainable Haskell program", not "How to write your first Haskell program", or "How to write a Haskell program simple enough not to need a build system or a test suite or revision control or be made publicly available to anyone". Yes, one can write a Haskell program in a single file and then compile it with `ghc --make myprogram`, but that's not a good idea if one's program is thousands of lines of code, depends on multiple libraries, exposes an API, and so on. It's not "neither here nor there"; it's definitely there, which is not where you expected it to be based on the title, but what do you expect from a totally decontextualised link on a news site?
If you are annoyed that I didn't "get it" after a cursory glance at the site, you have a couple of choices:
* Decide that I'm stupid or a troll and ignore what I have to say.
* Think about the presentation and framing of said content. For instance, what impact would it have to lead with a box "if you're looking for Haskell tutorials, go here, this is a guide to the best practices for creating and maintaining Haskell projects" ?
I don't really care one way or another.
I do, however, think that the defensive mentality (and the presumption of malice or stupidity) on display is not generally a good one for communities who wish to attract people to them.
Just FYI, I updated the site with a redirect at the start for those specifically expecting language tutorials. Thanks for your feedback, it was very helpful.
It was a while before I understood how Erlang project structure worked. But I knew where to look. Ditto when I try things like Scala and Clojure (as I'm no longer familiar with Java, really). This is a good and useful step.