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.
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 :-)
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?
My take on why monoids seem to be thought of as concatenation in the Haskell community is that the other simple examples run into some difficulty with the way the type class system is set up. Specifically, the example you used requires a newtype wrapper, because the nats (ints really, we don't use nats much) are a monoid under both addition and multiplication. We don't have any better way of dealing with multiple instances, so we create a Sum newtype and a Product newtype. This adds enough friction that those instances seem to not get used all that much. Other examples of this are the Boolean monoid under conjunction or disjunction, and the monoid of endomorphisms under composition. Those instances all exist, but I rarely (if ever) see them used.
There are definitely some more general uses of the Monoid type class than concatenation that don't require newtypes, but they are slightly harder to understand, so they don't tend to get trotted out as examples. The best example I can think of is Ordering (LT | EQ | GT), which is a monoid in the sense of lexicographical ordering. You also have Function (a -> b) and Maybe b, which are each monoids when b is a monoid, but if b is a monoid under concatenation then those just look like concatenation too.
One other reason I think they're thought of as concatenation is that monoids under concatenation are extremely useful. The most common case is when appending things that are like strings. Strings are not performant, so for anything significant you want to use Text or ByteString. However, it's not uncommon to use Strings when you're first figuring things out. If you want to then switch over to Text and you used String appending (++), you'll have to find and replace every instance of that. If you instead used Monoid appending (<>), you can switch the types and everything will still work. Quite nice.
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)
I was trying to simplify to get a cross the point that the Haskell ecosystem contains small and very well factored abstractions, without busting out the mathjax and technical terms. I find the key understanding of Monoids (which lets me use them and gives me a useful intuition upon seeing one) to be "Oh this is just combining these things together" - which I explain to newcomers as "basically concatenation".
It's always hard to pick the correct amount of correctness to use :-)
Probably too late for you to see this, but free objects are very common in Haskell-land. And free monoids are basically concatenation.
But you'll see all kind of monoids :)
Appending things is used as an example a lot of the time so people sort of get it into their heads that monoid = concatenation, which is obviously not true. I can't speak as to which monoids get used the most in Haskell but I have personally used it for appending string-like things, and also to unify data structures (combine the stuff in them basically). There is actually a library that will derive a Monoid instance for you if all of the types you're using are already instances.
Only by removing all meaning from the word "concatenation" and taking is to mean "associative with identity" , which is what a monoid is. Concatenation is a special case, not the whole of monoid.
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.
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.
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.
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).
You're assuming that difficulty is a single constant, which is definitely not the case. The real state of things is that Haskell is more difficult than Ruby to get really good at, but the actual work of developing things in Ruby is much more difficult than developing things in Haskell. This is because when you develop things in Ruby, you spend a lot of time debugging heisenbugs due to the total lack of referential transparency.
Accordingly, yes, newcomers to Haskell will probably have difficulty understanding what the type system is telling them, and this will slow them down a bit. But analogously, newcomers to Ruby (especially those using a heavyweight framework) will have difficulty figuring out why their application is doing what it is, and this will slow them down a lot.
(Source: I've worked professionally in both languages.)
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.)
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!
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.
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.
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).
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.
