On Fri, 2008-10-10 at 22:49 +0100, Andrew Coppin wrote:
Jonathan Cast wrote:
Newcomers flounder because they expect to keep programming the same way they always have.
_Some_ newcommers flounder because they expect Haskell to be just another VB / C++ / Java / whatever. (Do we really want to encourage these people to be learning Haskell in the first place?)
Absolutely not. That's my point.
Others it seems flounder simply because Haskell completely changes almost all the rules about programming, and they end up not knowing which way is up.
Are you sure teaching I/O first (or starting with an ugly, unreadable heavily imperative straight translation of C++/Perl/Ruby) is the best way to help these people? The Haskell community *is* committed to teaching people good functional design. You can see it every day on this list. But I don't really see the relevance here.
I have far more sympathy with these latter people.
As I say, teaching the language syntax and the standard library functions it's going to help much on its own. You need to give these people some idea of what the high-level game plan is.
OK, here's the high-level game plan: 1) Figure out what your program's major types are --- just what the names are. 2) Decide what operations you need on them. 3) Pick a domain (or functor) corresponding to each type constant, together with implementations of your selected operations for them. 4) Derive a set of laws governing your operations, that you're going to expect to hold for your implementation. Now, you have an API, and (implicitly) a class of mathematical models of that API. This class comes with a notion of `isomorphism' (or, technically, logical relation), between models that is required to preserve your type constants and operations. You have one model already (step 3); now you need to create another one (step 5) which will be more efficient when translated to machine code or interpreted on the computer. 5) Design a Haskell data type for each type constant, and implement Haskell functions for each operation. These may or may not be similar to your domains and operations from step 3, but there should be an isomorphism or logical relation between them. Now, you have an implementation, and can start work on an interface. 6) Pick an environment to work in (direct X11 programming, wxHaskell, the console, .NET, HTML over HTTP, etc.) 7) Decide what user-level operations you want to provide. 8) Decide, for each operation, what the effect of that operation should be in terms of your underlying state (from steps 1 and 3). 9) Implement each step as a function from the old state to the new one, using your implemented API from step 5. 10) Combine the steps into a comprehensive UI, using whatever composition methods are available in your environment. At each step, feel quite free to go back and revise your work at previous ones (but be sure to continue making progress!) An ideal tutorial would probably guide the user through these steps, in turn; note that I/O *definitely* comes after most of the code has been written.
I think you need to show people that you can use Haskell to do normal, ordinary stuff
Ordinary in the sense that it's common in programming tutorials, of course. *Real* programming mostly doesn't use printf and fget for I/O, even in C.
before you start showing off the more exotic things. (Obviously, you need to choose your examples carefully. Anything moderately complex
Anything at all, really. You can paper this over by just not explaining what this `IO' type constant is doing in their programs, but I don't think that actually helps. jcc