Snap for Beginners: Haskell Web Development
snapforbeginners.com
snapforbeginners.com
Clojure has "Web Development with Clojure" which is basically what I listed above, except for Clojure rather than Haskell.
Although it uses virthualenv instead of a cabal sandbox.
end result here, which I think should serve as a good starter point for developing with Scotty:
https://github.com/chrissrogers/chrissrogers.com
For Heroku builds I used the following excellent buildpack
but it seems well written if you can get past that point. Most beginners won't though.
I may write up a blogpost on getting this far. It's mostly based on this: https://www.fpcomplete.com/school/starting-with-haskell/libr... . I didn't do much beyond figure out explictly using L.fromStrict to deal with conflicting interpretations of overloaded-strings and figuring out how where to put my fillDB and getComments functions in main. I initially tried to call these within the scotty monad, but I think doing it that way would have required learning about monad transformers.
I'm hoping to eventually turn this into a simple disqus alternative that should be lightweight and easy to distribute as a binary.
I personally don't understand the draw of scotty because as soon as you want to start doing more substantial web development, you're going to want higher level abstractions. The Snap Framework adds to this in a pretty flexible and not-too-opinionated way with snaplets which are implemented in the snap package. The snap package also contains a few core snaplets that almost every application will want out of the box like sessions, auth, and a snaplet for Heist templating. The Heist part is the only place where the snap package gets opinionated. But you are definitely not locked into using Heist. You could very easily use Yesod's Hamlet, HStringTemplate, hastache, or anything else. Heist just happens to be the direction that the core Snap developers seem to prefer.
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.
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.
To be fair, that is not an uncommon situation.
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.)
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 :-)
newtype Sum = Sum { getSum :: Int }
instance Monoid Sum where
mempty = Sum 0
mappend (Sum a) (Sum b) = Sum (a + b)http://hackage.haskell.org/package/generic-deriving-1.6.2/do...
Then you can think of it as concatenating two unary numbers.
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 :-)
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.
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.
[1] http://snapframework.com/faq#is-anyone-using-snap-in-product...
I used it for a personal project of mine, which is creating an rss reader resembling the now dead iGoogle (which I loved), and although I had to read a lot of source code to get it to work, I really enjoyed how I worked with it, after figuring out the patterns on how to use it.
It definitely isn't finished, it could use some love by some eager developers, but in my opinion it has the potential to be the best framework out there.
- It extends scotty, so defining routes and control logic is fast and simple - It does not cage you in with a template language, or libraries that you don't want thrown in your face.
For example, I used Scotty with my own templating language I made for fun (hemplate), as well as a validation library I made, which I hope to finish in the near future, (after I get a job).
https://github.com/yesodweb/yesod-scaffold/tree/postgres-fay
It's not quite Meteor (then I dont believe it is so great), but works today and gives you Haskell from front-to-back.
The Haskell Center IDE of FPComplete is build with Yesod and Fay -- and that is a serious application.