I experimented with it at one point and tried to change a form field from required to optional. Boom! The whole application wouldn't compile...
The properties of the form are reflected in the type system and changing required to optional changed the type. That means I had to track the effect through the application and everywhere that just assumed the data was there had to be updated to handle both cases.
It was so restrictive and confusing I gave up for the time being (until I learn Haskell better), but it was an eye-opening glimpse of the power of types.
That's actually one of the reasons I like it. Instead of allowing your application to live in a half-working state, you're required to fix such things.
While it might not be as instantly gratifying and being able to refresh and see the page is still working, in the long run it saves a lot of headache.
I would strongly prefer to work in an environment that detected the error and gave me the power to trace through the app to resolve it while still letting the damn program run in the mostly-working state. The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.
The mental cost to review hundreds of lines of code to work out the implications of every change before you can see any results is a problem - it breaks the creative flow, it prevents experimentation.
Type errors don't require such a mental cost. Once you learn how to actually read the error messages it becomes almost brain-dead simple. Compile, jump to the error message (hopefully your editor can help here), fix, recompile.
it breaks the creative flow, it prevents experimentation.
I disagree. What prevents experimentation is the fear of the unknown regression. Strong types give you the reassurance you need to boldly refactor without worrying that you'll miss something.
Aren't the errors generated by nonconforming types a way to trace through the app? That's the point of a strong type system: code that by definition won't work isn't allowed to run.
I'm not using Haskell for things like this yet, but I must admit, this is one of the features that draws me to it as a language for web development. The idea of type safe HTML and requests is really interesting to me.
I really feel like Snap is a much more pragmatic approach to types. Where Yesod uses tons of metaprogramming and DSLs to make HTML and CSS type safe, Snap focuses on being a great Haskell system and HTML/CSS continue to be whatever they are. In practice this seems to be a good trade off because to get type safety in HTML/CSS the way Yesod does, you take on a lot of complexity and black magic.
The one place I wish I had better type safety in Snap is the SQL level. Yesod has Persistent which you can use with Snap but Persistent follows the same "black magic" design principles. I really wish there was a tool that handled PostgreSQL-specific query type checking and migration and that's it. No JSON/noSQL to SQL abstraction etc (which is cool if you want it but just a lot of if you don't). Once I pick a DB I don't want to constantly be generalizing away from it which is a conceptual overhead.
While I agree to some extent, I have to say the metaprogramming in Yesod does a good job at exposing solid information models for its abstractions, unlike, say reflection based metaprogramming in C# or Java. I find it pretty easy to bend it to my will, even if Yesod itself is quite opinionated.
I personally haven't tried the alternatives, but did research them when before I initially settled on Yesod.
Coming from a background of web dev'ing in Python and PHP, I've come to absolutely love Yesod. What I love most about it is that when it compiles, I'm 99% sure it works the way I intended it. This is a huuuuge plus, since I've been used to always having to test in runtime, which adds a lot of overhead and possibility for oversight.
This might just be me falling completely in love with Haskell and type inference (not just static typing, Java -.-..), but I'd wager that for any larger codebase/project, the gain from the time saved debugging, would make Haskell (and IMHO Yesod) the optimal choice.
A SO question about comparing Snap and Yesod where both maintainers chime in. The major point of talking here is the Yesod style "Template Haskell" configuration.
And finally my favorite summary of the whole thing: the Web Framework matrix which considers each as a web programming embedded DSL and talks about their relative merits in a 2x2 table.
If I jump ship from Scala + Play framework to Haskell, Yesod will be my first choice, batteries included and then some.
Anyone know if a Haskell IDE is in the works? Certainly would help to be able to mouse hover-view type, or mouse click-go to source declaration a la Eclipse/IntelliJ/Visual Studio, etc., particularly for beginners, imagine that's a pretty big time sink in learning the language...
Sorry for the hijack, but if anyone has any tips on Haskell debugging, please share. I loved Yesod, and get such satisfaction when it compiles because of the confidence it gives me that its working as intended. I love the type safe routes :) But I find debugging to be 99% what I do and I am terrible at it.
Also, any decent Haskell IDEs out yet? I'm using emacs purely for the syntax highlighting. I tried leksah but I gave up trying to configure it properly on my box.
Turn on -fdefer-type-errors or use the 7.8 beta with type holes. Write your types first. Write whole programs in the style of
lalala :: f g Int -> m q -> z ()
lalala = undefined
and then just check and see if your logic holds water. Then, slowly fill in the implementations and use -XImplicitParams and ?f or 7.8 type holes and _ as placeholders that GHC will tell you the goal types of.
Reflect as much information about side effects into your types as possible. Write new typeclasses to encapsulate smaller APIs like
class Teletype m where
writeLine :: String -> m ()
readLine :: m String
instance Teletype IO where
writeLine = putStrLn
readLine = getLine
echo :: Teletype m => m r
echo = forever $ readLine >>= writeLine
Then now we know what subset of IO `echo` actually uses.
Generally, the type system is your friend and used correctly it lets you write a shitty first draft of your program elegantly and quickly and then get to the hard part of typing it out later.
foo :: (the type you think it should have)
foo = undefined
If it compiles you at least know your type is right. Then, leaving the type annotation in place, replace undefined with a more useful expression. (Soon we will all be using Type Holes instead of this trick.)
I like hdevtools for mark-errors-on-save. I don't know if there's an emacs hook for it, but it's emacs so probably.
If you're talking about debugging after it compiles... I'm still working on that. I spent part of this past weekend digging into QuickCheck.
I can recommend VIM with Syntastic[0] and vim2hs[1]. You'd probably also want Vundle to manage plugins though.
What I get from that is my code is checked for style/compile errors everytime I save with ghc-mod and hlint. There's also commands to output the type of a function, run haskell code in VIM etc.
Note that you need ghc-mod installed for syntastic to take effect though.
You should study Haskell types. Debugging anything in Haskell without a basic understanding of the type system is daunting.
Additionally, Yesod relies heavily on quasiquoting and template haskell which can lead to some very cryptic code and errors. I generally prefer Snap for this reason and many others.
I find I spend most of my time on the engineering than in understanding types. (I recommend 'Types and Programming Languages by Pierce for general type stuff and Typeclassopedia for Haskell specific). Though I confess Yesod is the first real time I've seen quasiquoting and template haskell before. I haven't yet got a familiarity of what certain errors mean. 50% of the time when I get a compile error, the error message seems to be off on a complete tangent and is nowhere near where the actual error was.
Eg. I had some problem where a Data.Text was being passed into a function where Data.Text.Lazy was expected (Network.Mail.Mime.simpleMail for the record). The error message was deep in the internals of Data.Text.Lazy rather than in my code. I had to play a ridiculous pecking game of using undefine on each time I use Data.Text in turn in order to find which particular Data.Text was causing the error and then explicitly force one particular argument type to be a Data.Text.Lazy. I didn't feel like the compiler helped me at all.
Stepping through a program linearly doesn't seem possible (though not entirely sure why not) so I have no intermediate or step through capability. I also can't (normally) just stick in a println in the middle of a function or view the data structures at any particular point of the program. These are two tools I use all the time with Java and C#, but in Haskell I am rendered blind.
I've used Yesod for a small webapp. The type-safety is amazing.
For a simpler project, I've used a small subset of Snap. Well, the HTTP side was simpler: it was a game with the front-end completely in JS, and the server in Haskell; all Snap did was shunt JSON back and forth through a few routes for creating a new game, getting the updated game state, posting a move, etc.
Both are nice, depending on what you need, but for your average Django or RoR developer, Yesod gives the most bang for the buck in terms of learning a completely different paradigm.
`Applicative`'s `<|>` should be `Alternative`'s `<|>`. Alternative is to Applicative what MonadPlus is to Monad. Actually MonadPlus can be defined with just Applicative laws and no Monad laws, that's why MonadPlus will be replaced by Alternative in GHC 7.8.
This is a nice introduction but doesn't really cover much. As a primarily web dev who's just learning some haskell I'd be happy to hear more about data models, controllers, view, etc, whatever there is.
Happstack's tutorials [0][1] are probably the most complete and easy to read. Yesod's book [2] is nice too but I tend to find that it always seems a bit out of date.
That's why all the documentation to those projects is linked in this brief intro. Yesod has an entire book too http://www.yesodweb.com/book though I haven't read it, I assume it covers what you're looking for
I experimented with it at one point and tried to change a form field from required to optional. Boom! The whole application wouldn't compile...
The properties of the form are reflected in the type system and changing required to optional changed the type. That means I had to track the effect through the application and everywhere that just assumed the data was there had to be updated to handle both cases.
It was so restrictive and confusing I gave up for the time being (until I learn Haskell better), but it was an eye-opening glimpse of the power of types.