How to write a Haskell program | Hacker News Reader

How to write a Haskell program

haskell.org

148 pointsfogus32 comments

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:

http://www.sbcl.org/platform-table.html

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:

http://www.quicklisp.org/beta/

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.

Remember guys, this is an introduction to the Haskell ecosystem, and expected coding practices. It's not a tutorial about Haskell.

Also, needs a couple of little updates (e.g. github didn't exist when we wrote this).

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.

Is the GPL "standard" for Haskell programs?

No, the majority (around 80% of Haskell programs) use the BSD3 license.

Thanks, I was just curious. I am not for or against either license but since that how-to referenced the GPL I was curious enough to ask the question.

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.

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:

    BSD3: 2159 (72.38%)
    GPL: 345 (11.57%)
    LGPL: 117 (3.92%)
    OtherLicense: 107 (3.59%)
    PublicDomain: 85 (2.85%)
    MIT: 67 (2.25%)
    GPL-3: 64 (2.15%)
    LGPL-2.1: 16 (0.54%)
    GPL-2: 12 (0.4%)
    LGPL-3: 8 (0.27%)
    BSD4: 3 (0.1%)

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.

Was it a Haskell script? :-)

https://gist.github.com/943054

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.

Reply on news.ycombinator.com