7 ms·

Currently heading up a team of awesomely smart people building our back end in Haskell on snap. AMA!

bwilliams 13y ago
"the development SPEED of ruby with the SAFETY of STATIC TYPING" sounds kind of sketchy. Would you say that title is true?
- ixmatus 13y ago
  Not only true but faster because less time spent debugging.
  - joehillen 13y ago
    And it's faster and easier to add new features because you can refactor without fear.
    - bwilliams 13y ago
      I don't refactor with fear in my Rails apps since they have pretty good test coverage. I'm not saying it's perfect, but I've never had slow development because I wanted to refactor in this context.
      - ixmatus 13y ago
        It's been slower for me, personally. I write half the tests in Haskell than I had to in Python which means less updating of tests as requirements change. It won't feel slow to you until you've written productive (beyond beginner) software in Haskell.
  - pekk 13y ago
    Only if you don't count debugging whatever the fancy type system is doing vs. what you need the behavior to be
    - chc 13y ago
      What does this mean? I don't think most Haskell users spend a lot of time debugging the type system.
      - dllthomas 13y ago
        New Haskell developers spend a bit of time figuring out why the types of an expression aren't what they think they are, especially when wading into using some of the libraries with more sophisticated use of types.
        hamidr 13y ago
        Now, It's "New Haskell developers" vs "New Ruby/RoR developers". Isn't it?
        dllthomas 13y ago
        I'm not certain what you're asking. If you mean it's unfair to compare experienced Ruby developers to new Haskell developers I agree, I was just explaining where the sentiment was coming from (insofar as it was legitimate).
        coldtea 13y ago
        Well, New Ruby developers doesn't have the same problem. They can move much faster than the initial uphill struggle that is Haskell. Essentially, there are three sitations: a) Everything is of the same difficulty. b) Haskell is more difficult than Ruby. c) Ruby is more difficult than Haskell. I'd say (b) is a much saner conclusion.
        hamidr 13y ago
        I think You are assuming that the learner here is already a (imperative or OOP categorized) programmer who is willing to learn these two languages. For ruby still there would be some topics you need to know about before trying to learn language itself, if you are just starting out.
- boothead 13y ago
  What you find if you're doing it right is not only that you get the safety of static typing, but also that the types often lead you towards to solution. Abstractions in Haskell are smaller, more universal and composable than those of say ruby or python. For example the very simple idea of a Monoid (essentially concatenation) can be found in most places either explicitly or if you squint a bit, and once you recognise it a whole set of properties and behaviours can be reused. Also once the structure is in place, they types make for very safe re-factoring and assurance that you haven't broken anything. The only thing that's probably slower than ruby in Haskell is, unfortunately, learning it in the first place :-)
  - fractalsea 13y ago
    As someone who is quite familiar with abstract algebra, but who has not used much Haskell, I'm curious about why you think of monoids as simply concatenation? Is this the only, or primary, way they are used in Haskell? A monoid could also be the natural numbers combined with addition for example. Would this not be as useful?
    - tel 13y ago
      Haskellers just call them Monoid and happily include anything that's associative+identity. When talking to people not yet familiar with Haskell or abstract algebra, it's commonly a good idea to simplify the notion and call Monoid the same as concatenation. That's all. newtype Sum = Sum { getSum :: Int } instance Monoid Sum where mempty = Sum 0 mappend (Sum a) (Sum b) = Sum (a + b)
    - deleted 13y ago
      [deleted]
    - carterschonwald 13y ago
      yes, thats a commutative monoid. Thinking of a monoid as "concatenation" is much more general concept that includes that one
      - judk 13y ago
msluyter 13y ago
How long do you think it'd take for a reasonably decent developer with no prior experience to pick up and become competent with Haskell and Snap?
- deleted 13y ago
  [deleted]
- copergi 13y ago
  I don't have a lot of data points, but for the one PHP developer I had learn haskell by writing a webapp in it, 6 months from "never seen haskell before" to "feels comfortable working solo and doesn't need help". The first 80% comes pretty quick, but not needing someone to answer questions takes a while.
  - IanCal 13y ago
    This is helped by the fantastic haskell community. The IRC channels are great.
nnutter 13y ago
How do you plan to deploy your backend? Are there tools to do it? Is it just rsyncing a cabal sandbox to another machine? What about compiling and stuff? (I've barely made my way through LYHGG.)
- copergi 13y ago
  I used to just scp the binary up to the servers. They don't need any haskell stuff installed or anything like that. Recently I made it so they grab the latest binary off of S3 on bootup and when I run an update script. So now I just upload the binary to S3 instead.
- begriffs 13y ago
  You can deploy Snap apps to Heroku pretty easily. https://github.com/begriffs/heroku-buildpack-ghc https://github.com/begriffs/heroku-buildpack-ghc
- boothead 13y ago
  So we started with a git subtree merge of all the dependent projects and then a script to build a docker container, with physical infrastructure managed by ansible. It now looks more like we're going to use NixOs and NixOps - which are awesome!
nnutter 13y ago
Are there (good) tools to help with refactoring Haskell? To me this seems like one of the benefits of a statically typed language (I've almost entirely worked in Perl).
- tinco 13y ago
  Not as good as for example for C#, but not as bad as for example Ruby. I have a plugin for Sublime that complains when something is broken, or a dependency is missing. The typesystem is so strong that usually when it compiles, it works. So my process for refactoring is basically changing typesystems, and having the compiler check my changes until it works again. Note that this thinks of Ruby as bad only in IDE aspect. Refactoring Ruby is actually quite enjoyable as Ruby is so friendly to unit testing. You just move your code and run your tests again.
- judk 13y ago
  Look up [HaRe the Haskell refactorer]
jcampbell1 13y ago
Are there any open source Snap projects that are good to learn from the code?
- biscarch 13y ago
  There is a list of some people using Snap here[1] and some of them are open source. The book also has approximately 8 pre-coded projects that come with it and correlate to the chapters. [1] http://snapframework.com/faq#is-anyone-using-snap-in-production http://snapframework.com/faq#is-anyone-using-snap-in-product...

"the development SPEED of ruby with the SAFETY of STATIC TYPING" sounds kind of sketchy. Would you say that title is true?

ixmatus 13y ago
Not only true but faster because less time spent debugging.
- joehillen 13y ago
  And it's faster and easier to add new features because you can refactor without fear.
  - bwilliams 13y ago
    I don't refactor with fear in my Rails apps since they have pretty good test coverage. I'm not saying it's perfect, but I've never had slow development because I wanted to refactor in this context.
    - ixmatus 13y ago
      It's been slower for me, personally. I write half the tests in Haskell than I had to in Python which means less updating of tests as requirements change. It won't feel slow to you until you've written productive (beyond beginner) software in Haskell.
- pekk 13y ago
  Only if you don't count debugging whatever the fancy type system is doing vs. what you need the behavior to be
  - chc 13y ago
    What does this mean? I don't think most Haskell users spend a lot of time debugging the type system.
    - dllthomas 13y ago
      New Haskell developers spend a bit of time figuring out why the types of an expression aren't what they think they are, especially when wading into using some of the libraries with more sophisticated use of types.
      - hamidr 13y ago
        Now, It's "New Haskell developers" vs "New Ruby/RoR developers". Isn't it?
        dllthomas 13y ago
        I'm not certain what you're asking. If you mean it's unfair to compare experienced Ruby developers to new Haskell developers I agree, I was just explaining where the sentiment was coming from (insofar as it was legitimate).
        coldtea 13y ago
        Well, New Ruby developers doesn't have the same problem. They can move much faster than the initial uphill struggle that is Haskell. Essentially, there are three sitations: a) Everything is of the same difficulty. b) Haskell is more difficult than Ruby. c) Ruby is more difficult than Haskell. I'd say (b) is a much saner conclusion.
        hamidr 13y ago
        I think You are assuming that the learner here is already a (imperative or OOP categorized) programmer who is willing to learn these two languages. For ruby still there would be some topics you need to know about before trying to learn language itself, if you are just starting out.
boothead 13y ago
What you find if you're doing it right is not only that you get the safety of static typing, but also that the types often lead you towards to solution. Abstractions in Haskell are smaller, more universal and composable than those of say ruby or python. For example the very simple idea of a Monoid (essentially concatenation) can be found in most places either explicitly or if you squint a bit, and once you recognise it a whole set of properties and behaviours can be reused. Also once the structure is in place, they types make for very safe re-factoring and assurance that you haven't broken anything. The only thing that's probably slower than ruby in Haskell is, unfortunately, learning it in the first place :-)
- fractalsea 13y ago
  As someone who is quite familiar with abstract algebra, but who has not used much Haskell, I'm curious about why you think of monoids as simply concatenation? Is this the only, or primary, way they are used in Haskell? A monoid could also be the natural numbers combined with addition for example. Would this not be as useful?
  - tel 13y ago
    Haskellers just call them Monoid and happily include anything that's associative+identity. When talking to people not yet familiar with Haskell or abstract algebra, it's commonly a good idea to simplify the notion and call Monoid the same as concatenation. That's all. newtype Sum = Sum { getSum :: Int } instance Monoid Sum where mempty = Sum 0 mappend (Sum a) (Sum b) = Sum (a + b)
  - deleted 13y ago
    [deleted]
  - carterschonwald 13y ago
    yes, thats a commutative monoid. Thinking of a monoid as "concatenation" is much more general concept that includes that one
    - judk 13y ago

msluyter 13y ago

How long do you think it'd take for a reasonably decent developer with no prior experience to pick up and become competent with Haskell and Snap?

deleted 13y ago
[deleted]
copergi 13y ago
I don't have a lot of data points, but for the one PHP developer I had learn haskell by writing a webapp in it, 6 months from "never seen haskell before" to "feels comfortable working solo and doesn't need help". The first 80% comes pretty quick, but not needing someone to answer questions takes a while.
- IanCal 13y ago
  This is helped by the fantastic haskell community. The IRC channels are great.

nnutter 13y ago

How do you plan to deploy your backend? Are there tools to do it? Is it just rsyncing a cabal sandbox to another machine? What about compiling and stuff? (I've barely made my way through LYHGG.)

copergi 13y ago
I used to just scp the binary up to the servers. They don't need any haskell stuff installed or anything like that. Recently I made it so they grab the latest binary off of S3 on bootup and when I run an update script. So now I just upload the binary to S3 instead.
begriffs 13y ago
You can deploy Snap apps to Heroku pretty easily. https://github.com/begriffs/heroku-buildpack-ghc https://github.com/begriffs/heroku-buildpack-ghc
boothead 13y ago
So we started with a git subtree merge of all the dependent projects and then a script to build a docker container, with physical infrastructure managed by ansible. It now looks more like we're going to use NixOs and NixOps - which are awesome!

nnutter 13y ago

Are there (good) tools to help with refactoring Haskell? To me this seems like one of the benefits of a statically typed language (I've almost entirely worked in Perl).

tinco 13y ago
Not as good as for example for C#, but not as bad as for example Ruby. I have a plugin for Sublime that complains when something is broken, or a dependency is missing. The typesystem is so strong that usually when it compiles, it works. So my process for refactoring is basically changing typesystems, and having the compiler check my changes until it works again. Note that this thinks of Ruby as bad only in IDE aspect. Refactoring Ruby is actually quite enjoyable as Ruby is so friendly to unit testing. You just move your code and run your tests again.
judk 13y ago
Look up [HaRe the Haskell refactorer]

jcampbell1 13y ago

Are there any open source Snap projects that are good to learn from the code?

biscarch 13y ago
There is a list of some people using Snap here[1] and some of them are open source. The book also has approximately 8 pre-coded projects that come with it and correlate to the chapters. [1] http://snapframework.com/faq#is-anyone-using-snap-in-production http://snapframework.com/faq#is-anyone-using-snap-in-product...