7 ms·

Functional Programming in Haskell by Examples

128 points by bontoJR 11y ago

christianbryant 11y ago
I'm curious how you feel Haskell has helped you. Do you actually use Haskell for a great percentage of your deliverable code or do you simply use it for ideas, experimentation and so forth?
- embwbam 11y ago
  I've made 2-3 toy REST APIs, and now I'm working on a product using a Haskell backend that's bigger. https://github.com/seanhess/serials https://github.com/seanhess/serials I love it. I mean I could have done the same thing in node. But there's something about the workflow in Haskell. I need to add a new feature I didn't think of. But I don't have to refactor as aggressively because all my code is made up of little functions. I start hacking, my editor has a list of errors I still need to clean up. I clean them up, and it usually works the first try. Or this morning I wanted to add a connection pool to my rethinkdb driver code. The resource-pool package gives you an awesome way to do it for anything. Without knowing about rethinkdb at all. Also this morning I wanted to do some IO in parallel. I found several nice concurrency packages and threw one in without any refactoring. It has its difficulties (deployment?) but I'm really enjoying it.
  - creichert 11y ago
    It has its difficulties (deployment?) but I'm really enjoying it. Anything specific? What kind of environments are you deploying in?
    - embwbam 11y ago
      Just compared to dynamic languages. Cross compiling and such. I went with docker (see the repo) and it works. Deploys via docker push are a little slower than I'd like but nothing I can't improve later.
      - creichert 11y ago
        I see, it really depends on your goal. The Dockerfile in the repo looks like it's built primarily for Haskell development. When I'm working with production environments, I build the Haskell executable locally and add that (statically linked) program to the Dockerfile. That should tremendously speed things up. The caveat is that your local and production architecture are the same. I find deploying the static executable much quicker and more simple. You aren't doing it wrong, just thought I would my own preferences. Some environments like Elastic Beanstalk have timeouts that will kill the build if it doesn't build quickly enough (a problem on smaller VMs). Another issue is potential RAM needed by GHC. Keep in mind that Haskell executables statically link Haskell libraries and dynamically link system libs (by default). You can find your system library dependencies by running: $ ldd dist/build/serials/serials [...]
        embwbam 11y ago
        That sounds way nicer than my 30 minute deploy process. I develop on a mac and deploy to ubuntu. How would you recommend I build? Vagrant? (I almost finished getting the vagrant stuff working).
    - Ericson2314 11y ago
      I highly recommend https://github.com/NixOS/nixops https://github.com/NixOS/nixops, which is good for deployment in general, but especially good for Haskell since the Haskell infrastructure was rewritten this year.
      - codygman 11y ago
        I found myself using cabbage[0] so I could have exact version dependencies. Nix was awesome when mostly using latest versions of a package, but for much of my code I needed specific versions and cabbage allowed me to have them. 0: https://github.com/acowley/cabbage https://github.com/acowley/cabbage
        Ericson2314 11y ago
        For the sake of a single manager for my whole system I'll stick with nix. But yes, it would be nice if it knew more about versions. In a future where upstream projects can maintain their own nix packages, I think this will be unavoidable.
      - embwbam 11y ago
        I've heard it mentioned several times, but I don't really understand how to use it to deploy haskell code. Do you know of a tutorial link somewhere?
        Ericson2314 11y ago
        So recently the haskell package infrastructure was overhauled. This is great! But, it means that many resources are out of date. I really recommend you first read about nix with http://lethalman.blogspot.com/feeds/posts/default/-/nixpills http://lethalman.blogspot.com/feeds/posts/default/-/nixpills . Once you've done that, the simple instructions at http://wiki.ocharles.org.uk/Nix http://wiki.ocharles.org.uk/Nix should get you going. You can try to skip to the wiki page, but in the likely case something doesn't go quite right, it will be hard to debug without a broader knowledge of Nix. I'll admit Nix's has quite the learning curve, and I was more tempted to sneak around its uncompromising rigidity than when learning Haskell. But the bitter pill is worth it.
  - qubitcoder 11y ago
    Similar story here. I find I'm able to accomplish tasks which would otherwise be beyond my skill and intelligence. For example, even though C was the first language I learned, I can't imagine writing a parser in C after discovering the simplicity & readability of monadic parsing in Haskell. [1] Just compare that page with the parser/lexer for the Jq tool on the HN homepage (written in C). A few months ago, I needed to retrieve JSON data from a list containing dozens of URLs. Fortunately, the "async" package handles this beautifully: [2] pages <- mapConcurrently getURL ["url1", "url2", "url3",...] Once you learn the basic concepts of Haskell and get over the hump, you’re able do things with ease that would otherwise take many years to master in C++ [3]. Even the most advanced features of the language follow the same underlying principles & syntax. My advice to those wanting to learn Haskell is simply not to give up. Keep coming back to it. Practice. Read other’s code. Over time, things will begin to click. And once they do, you’ll wonder why you struggled so much in the first place. [1] https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-frameworks/text-manipulation/attoparsec https://www.fpcomplete.com/school/starting-with-haskell/libr... [2] https://hackage.haskell.org/package/async-2.0.2/docs/Control-Concurrent-Async.html https://hackage.haskell.org/package/async-2.0.2/docs/Control... [3] http://chimera.labs.oreilly.com/books/1230000000929/index.html http://chimera.labs.oreilly.com/books/1230000000929/index.ht...
- the_af 11y ago
  I use it for my own experiments and never -- sadly -- for work, where my boss thinks Scala is just syntax sugar over Java, which is in turn merely syntax sugar over C. I don't think he has ever heard of Haskell, and I don't have the energy to have that conversation with him, when he is already so dismissive of Scala. But I still have ghci installed at work, and I find it surprisingly useful to use Haskell to prototype (pure) functions for Scala! This is something I truly didn't see coming, but now I often find myself starting ghci when I want to see if some combination of folds or maps works the way I think it should, and for some reason it feels way more convenient than trying it in Scala.
  - sls 11y ago
    C is just portable assembler, ask him why he's got people wasting company time and cpu cycles on such a thing. I'm sure you're targeting x86, time to put on your big boy pants.
fiveoak 11y ago
Nice reference. It's interesting how intuitive the examples are even though I've never learned a functional programming language before.
- Ericson2314 11y ago
  Learning functional programming is arguably more about unlearning all the terrible hoops other languages make one jump through.
M00n_Sl47r 11y ago
The grammar in this is a bit off. I'll probably submit a pull request with some edits, if that's something people do? I'm not sure about the etiquette surrounding grammar mistakes in a github repo.
- creichert 11y ago
  I think it's a nice gesture as long as you are polite about it. I would be happy that someone read the content and wanted to help improve it.
- jonreem 11y ago
  Personally I am always thrilled to get grammar/typo fix pull requests to my projects. It means someone cared enough about the project to go through the effort of making a PR just to alleviate a small aesthetic problem!
- bontoJR 11y ago
  Definitely a good habit, I think more than the 50% of Github users are not English as mother tongues, so it's good to polish documentations, or like in this case, long texts. I always accept pull-requests for grammar improvements.
- codezero 11y ago
  Since I can't code for shit, I submit pull requests to fix grammar and spelling a lot. The reactions are overwhelmingly positive. Just make sure to leave a nice comment.
titanomachy 11y ago
The GHCi command to enable multiline mode is `:set +m`, not `:set +s`. `set +s` enables profiling.
bbcbasic 11y ago
Great resource. I am learning Haskell. When I get more experienced at Parsec I'll consider a write up and send you a pull request. Your monad section looks solid, although now I undestand them I can no longer tell if a tutorial is good or not :-)

128 points by bontoJR 11y ago

I'm curious how you feel Haskell has helped you. Do you actually use Haskell for a great percentage of your deliverable code or do you simply use it for ideas, experimentation and so forth?

embwbam 11y ago
I've made 2-3 toy REST APIs, and now I'm working on a product using a Haskell backend that's bigger. https://github.com/seanhess/serials https://github.com/seanhess/serials I love it. I mean I could have done the same thing in node. But there's something about the workflow in Haskell. I need to add a new feature I didn't think of. But I don't have to refactor as aggressively because all my code is made up of little functions. I start hacking, my editor has a list of errors I still need to clean up. I clean them up, and it usually works the first try. Or this morning I wanted to add a connection pool to my rethinkdb driver code. The resource-pool package gives you an awesome way to do it for anything. Without knowing about rethinkdb at all. Also this morning I wanted to do some IO in parallel. I found several nice concurrency packages and threw one in without any refactoring. It has its difficulties (deployment?) but I'm really enjoying it.
- creichert 11y ago
  It has its difficulties (deployment?) but I'm really enjoying it. Anything specific? What kind of environments are you deploying in?
  - embwbam 11y ago
    Just compared to dynamic languages. Cross compiling and such. I went with docker (see the repo) and it works. Deploys via docker push are a little slower than I'd like but nothing I can't improve later.
    - creichert 11y ago
      I see, it really depends on your goal. The Dockerfile in the repo looks like it's built primarily for Haskell development. When I'm working with production environments, I build the Haskell executable locally and add that (statically linked) program to the Dockerfile. That should tremendously speed things up. The caveat is that your local and production architecture are the same. I find deploying the static executable much quicker and more simple. You aren't doing it wrong, just thought I would my own preferences. Some environments like Elastic Beanstalk have timeouts that will kill the build if it doesn't build quickly enough (a problem on smaller VMs). Another issue is potential RAM needed by GHC. Keep in mind that Haskell executables statically link Haskell libraries and dynamically link system libs (by default). You can find your system library dependencies by running: $ ldd dist/build/serials/serials [...]
      - embwbam 11y ago
        That sounds way nicer than my 30 minute deploy process. I develop on a mac and deploy to ubuntu. How would you recommend I build? Vagrant? (I almost finished getting the vagrant stuff working).
  - Ericson2314 11y ago
    I highly recommend https://github.com/NixOS/nixops https://github.com/NixOS/nixops, which is good for deployment in general, but especially good for Haskell since the Haskell infrastructure was rewritten this year.
    - codygman 11y ago
      I found myself using cabbage[0] so I could have exact version dependencies. Nix was awesome when mostly using latest versions of a package, but for much of my code I needed specific versions and cabbage allowed me to have them. 0: https://github.com/acowley/cabbage https://github.com/acowley/cabbage
      - Ericson2314 11y ago
        For the sake of a single manager for my whole system I'll stick with nix. But yes, it would be nice if it knew more about versions. In a future where upstream projects can maintain their own nix packages, I think this will be unavoidable.
    - embwbam 11y ago
      I've heard it mentioned several times, but I don't really understand how to use it to deploy haskell code. Do you know of a tutorial link somewhere?
      - Ericson2314 11y ago
        So recently the haskell package infrastructure was overhauled. This is great! But, it means that many resources are out of date. I really recommend you first read about nix with http://lethalman.blogspot.com/feeds/posts/default/-/nixpills http://lethalman.blogspot.com/feeds/posts/default/-/nixpills . Once you've done that, the simple instructions at http://wiki.ocharles.org.uk/Nix http://wiki.ocharles.org.uk/Nix should get you going. You can try to skip to the wiki page, but in the likely case something doesn't go quite right, it will be hard to debug without a broader knowledge of Nix. I'll admit Nix's has quite the learning curve, and I was more tempted to sneak around its uncompromising rigidity than when learning Haskell. But the bitter pill is worth it.
- qubitcoder 11y ago
  Similar story here. I find I'm able to accomplish tasks which would otherwise be beyond my skill and intelligence. For example, even though C was the first language I learned, I can't imagine writing a parser in C after discovering the simplicity & readability of monadic parsing in Haskell. [1] Just compare that page with the parser/lexer for the Jq tool on the HN homepage (written in C). A few months ago, I needed to retrieve JSON data from a list containing dozens of URLs. Fortunately, the "async" package handles this beautifully: [2] pages <- mapConcurrently getURL ["url1", "url2", "url3",...] Once you learn the basic concepts of Haskell and get over the hump, you’re able do things with ease that would otherwise take many years to master in C++ [3]. Even the most advanced features of the language follow the same underlying principles & syntax. My advice to those wanting to learn Haskell is simply not to give up. Keep coming back to it. Practice. Read other’s code. Over time, things will begin to click. And once they do, you’ll wonder why you struggled so much in the first place. [1] https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-frameworks/text-manipulation/attoparsec https://www.fpcomplete.com/school/starting-with-haskell/libr... [2] https://hackage.haskell.org/package/async-2.0.2/docs/Control-Concurrent-Async.html https://hackage.haskell.org/package/async-2.0.2/docs/Control... [3] http://chimera.labs.oreilly.com/books/1230000000929/index.html http://chimera.labs.oreilly.com/books/1230000000929/index.ht...
the_af 11y ago
I use it for my own experiments and never -- sadly -- for work, where my boss thinks Scala is just syntax sugar over Java, which is in turn merely syntax sugar over C. I don't think he has ever heard of Haskell, and I don't have the energy to have that conversation with him, when he is already so dismissive of Scala. But I still have ghci installed at work, and I find it surprisingly useful to use Haskell to prototype (pure) functions for Scala! This is something I truly didn't see coming, but now I often find myself starting ghci when I want to see if some combination of folds or maps works the way I think it should, and for some reason it feels way more convenient than trying it in Scala.
- sls 11y ago
  C is just portable assembler, ask him why he's got people wasting company time and cpu cycles on such a thing. I'm sure you're targeting x86, time to put on your big boy pants.

fiveoak 11y ago

Nice reference. It's interesting how intuitive the examples are even though I've never learned a functional programming language before.

Ericson2314 11y ago
Learning functional programming is arguably more about unlearning all the terrible hoops other languages make one jump through.

M00n_Sl47r 11y ago

The grammar in this is a bit off. I'll probably submit a pull request with some edits, if that's something people do? I'm not sure about the etiquette surrounding grammar mistakes in a github repo.

creichert 11y ago
I think it's a nice gesture as long as you are polite about it. I would be happy that someone read the content and wanted to help improve it.
jonreem 11y ago
Personally I am always thrilled to get grammar/typo fix pull requests to my projects. It means someone cared enough about the project to go through the effort of making a PR just to alleviate a small aesthetic problem!
bontoJR 11y ago
Definitely a good habit, I think more than the 50% of Github users are not English as mother tongues, so it's good to polish documentations, or like in this case, long texts. I always accept pull-requests for grammar improvements.
codezero 11y ago
Since I can't code for shit, I submit pull requests to fix grammar and spelling a lot. The reactions are overwhelmingly positive. Just make sure to leave a nice comment.

titanomachy 11y ago

The GHCi command to enable multiline mode is `:set +m`, not `:set +s`. `set +s` enables profiling.

bbcbasic 11y ago

Great resource. I am learning Haskell. When I get more experienced at Parsec I'll consider a write up and send you a pull request. Your monad section looks solid, although now I undestand them I can no longer tell if a tutorial is good or not :-)