I would love to see a "from nothing to web app" style piece of writing on this. It sounds intriguing. Blog, paid videocast, book, set of tutorials.. If you're interested in doing one, perhaps as a noob I could provide some "that's hard to grasp" style feedback and collaboration (mail in profile hinthint).

I've been toying with the idea of writing a Yesod equivalent for the excellent Rails Tutorial by Michael Hartl. I need to get a bit more comfortable with Yesod first however, so it may take a while. I do think that is what the Yesod world is in most need of right now, a "get stuck in" tutorial that takes the reader from zero to a substantial web app.

If you decide to do so, you are welcome to post tutorials on the School of Haskell.

Kickstarter project? Chris Coyier did a great set for his site redesign, for example.

http://www.kickstarter.com/projects/150422311/screencasting-...

Great idea; if I find the time I'll think about putting something together. Good to know there is interest in this.

Great! Something along the lines of the angular.js videocasts which popped up a few days ago would be great. Small digestible pieces which fit together like legos in your mind.. :)

> In Python I run into a lot of programmer related bugs that Haskell's rigid type system prevents.

Isn't your productivity gain coming from using a statically typed language rather than Haskell specifically? It feels like any statically typed language is a leg up from Python :)

> Isn't your productivity gain coming from using a statically typed language rather than Haskell specifically

I think it's a bit more than that, Haskell has a much more sophisticated type system than quite a few of the popular statically typed langauges ( C, Java, C# ). Static typing is only the start, to be really useful we need modern type inference methods and a concise way of expressing generics. Both Scala and Haskell do this very well.

It depends on what you mean by statically typed language. If you mean other stuff like SML/Ocaml, I agree. If you include C/C++/Java/C# in your definition "statically typed", then I beg to differ. I have considerable experience in C, Java and, to a lesser extent, C++. And all in all I consider their type systems worthless for error prevention, the flexibility of python gains you more than their type systems do.

In this sense I suspect the OP would say the same about any ML-like static type system, but not many other static type systems.

Purity is a big factor too, and Haskell is the only pure language I know of that is mature enough for production use.

in though statically typed meant C++ or Java, and probably it does.. i never felt compelled to the way they do typing, so i gravitated towards Ruby and Python.

but to me Haskell is a different league.. Haskell-typing actually helps /me/, where i feel C++/Java-typing merely help the compiler.

Are we still spreading that canard where type errors are somehow some kind of bugbear in Python?

It's not a profound part of writing code in Python for anybody that's spent more than a few weeks with it.

A profound part? Maybe not. However, I noticed yesterday that a provisioning tool I wrote was blowing because I was assigning by mistake an empty string coming from a CSV instead of a None value to an integer field in an sqlalchemy model. That's a bug a static type system would have found.

Almost every exception a Python program ever throws is or can be made a type error (or otherwise statically caught) in Haskell and similar languages. A type error is not the same thing as a TypeError.

When someone dumps a large Python codebase on you, it is significantly harder to figure out how it works than with a statically typed program, since it is harder to figure out what types to use and are returned by any given function call.

Really hoping to see that application, I've been meaning to pick up Yesod, but school and all that are getting in the way.

Thanks. In fact we used Haskell + Yesod + Fay to build the School of Haskell itself.

The correct way to use Python is to write unit tests. Don't blame your tools when you don't know how to use them correctly.

What it comes down to is that Haskell's type system eliminates whole categories of bugs because of the language. Having the correct way to use the language outside of the language itself, as an addition, in the case of Python or Ruby or (insert interpreted language here) makes for lots of extra debugging time.

When you use a programming language, you use its ecosystem. Haskell has its own tools and norms outside "the language itself" which I am obligated to take advantage of. If I develop software in Haskell, but completely ignore these tools, and make complaints which have DIRECTLY to do with my non-use of available facilities, I do not then have the right to say that Haskell is broken and objectively worse than language X. It does not follow.

Writing unit tests is not hard. Nor is it rare or exceptional. Wrestling Haskell's type system is not necessarily easy. Overall, making programs do the right thing is a big problem in any language, including Haskell, and one hopes that any system of significant size is being tested properly whether it uses a static type system or not.

The use of a type system is not in itself an objective slam dunk for Haskell over Python or anything else.

Have you coded in haskell? Really, the great-grandfather post that provoked this wasn't an attack on python, it's pointing out a difference between the type systems in ML, haskell, scala, and maybe typed racket, of the non-dependently type languages vs. all others.

I use Python + Pyramid daily; and I love it. However, I love Haskell more. Yesod/Snap/Happstack have quite a ways to go before they are on-par community and feature wise with Pyramid/Django/Rails/etc... but it's mature enough for production use.

With a little extra learning curve; it beats the pants off of Python + Pyramid + unit tests and lots of extra debugging time.

In other words: do the job that the compiler would have done for you if you'd been using Haskell!

When you are spending a significant amount of time telling the type system which assertions to make about your program, the compiler is not doing that work for you.

I am concerned that it is forbidden even to question Haskell advocacy around here, even where it extends into pretty bald bashing of other languages.

Which is fine, because in Haskell you aren't spending all that much time telling the compiler which assertions to make. The compiler can infer essentially all the types in your program.

In fact, this is so useful that new versions of GHC are going to support "type holes". If you don't know what type you need in any particular part of the code, you can just write a _ there, and the compiler will tell you what type goes there! So really, you're not spending time telling the type system which assertions to make--the type system is telling you what you need.

This is going to enable a much more interactive development style that leverages the power of the compiler to help you write your program. I think a more interactive development system is the future, and this is a good (albeit fairly small) step in that direction.

Also, as an interesting aside, the type inference can actually make your code more expressive. In both Haskell and Python, you could write a function called toString that takes an argument and returns it as a string. However, the really cool thing is that in Haskell you can write the opposite function--fromString. This function takes a string and returns a value. The real beauty is that the compiler can infer what type you need and choose the appropriate parser; in Python (or, really, virtually any other language), you would have to specify whether you want an int or a double or a Foo or a Bar explicitly.

So: the types are inferred for you, you can use these inferred types to help you write your program and they actually make the code more expressive. I think it's a pretty good deal.

I am on the Haskell side of things here. But one small nitpick: You could write something somewhat like fromString in Python with some trickery. You would basically have to keep the string around and convert only on demand.

Could you clarify? I'm genuinely curious about how you would do that.

Give me some time to write something up. I will contact you via email, once I have it.

Types and tests give completely different assurances. Tests give you assurance that a particular code path works at least some of the time. Types give you assurance that an invariant is true all of the time.

Thank you for your time, enlightened one.