School of Haskell Goes Beta

For me, there's a pretty big gap between the available educational materials and research papers. My understanding of the academic stuff is mostly intuitive. It isn't until I read a paper like Monadic Parser Combinators [1] or sigfpe's blog [2] that it really becomes concrete.

I find that for a lot of higher-level ideas much of the heavy lifting isn't necessarily through application of functional ideas per se, but through more sophisticated type gymnastics.

Because expressions are often written in short-hand (to expose structure), as well abbreviated and underspecified (to get the compiler to do the work), making sense of academic code can be a challenge.

In another life I'd have dedicated more time to learning the fundamentals (of Programming Language Theory and Category Theory), because I find the whole field insanely facinating. Maybe I'm looking for a short-cut but there isn't one?

[1] http://eprints.nottingham.ac.uk/237/1/monparsing.pdf [2] http://blog.sigfpe.com/

> Unfortunately, I emailed the wiki contact a couple times about pitching in and never got response.

Have you tried contacting the Haskell cafe instead? I am sure someone there will be able to get through.

We welcome people who have written (or plan to write) Haskell tutorials and exercises to post them on the School of Haskell, if they find its features useful. By now you've probably seen the Active Haskell demo in the beta screencast video? https://haskell.fpcomplete.com/beta

We also welcome good organizers (like yourself perhaps?) to write tutorials that consist partly or entirely of links to other materials. The role of editors and organizers is sometimes undervalued, but not by us!

Why do you say that? Applicatives are perhaps easier and open up Foldable/Traversable, but Monads are just everywhere. As the de facto default functor sequencing method, I'd recommend people start there.

Thank you for your time, enlightened one.

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.

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

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.

> 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.

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

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.

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.

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.

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

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

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.

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

That's not really unlike Haskell: in Haskell, you just have a different set of tools for transforming the language.

I just came off a largish project in Racket, and do appreciate that it's very flexible. However, I've found Haskell to be roughly as flexible in practice. Haskell has surprisingly flexible syntax and semantics, and I've found it very easy to have parts of my program with radically different semantics from normal Haskell.

You can very easily layer on things like non-determinism, logic programming, error-handling, asynchronous programming or even continuations onto Haskell code. And since it's lazy by default, you do not have to do anything special to add new control structures--you don't even need to use the macro system. (Which, of course, Racket does much better--template Haskell works, but it's a bit of a pain.)

I've also spent some time embedding DSLs in both Racket and Haskell, and have found that they are about roughly equally convenient. Racket is more flexible syntactically--it's very easy to do things like inspect variable names and the like. Haskell, on the other hand, has some very lightweight tools (laziness, do notation and a very spartan syntax) that make it very easy to change its semantics. The type system--especially things like GADTs--also makes life much easier for DSLs.

Lisp (and especially Racket) is fun. But Haskell also allows preprocessing your code.

Not likely leksah http://fpcomplete.com/designing-the-haskell-ide/

Slightly off-topic: How much do you break down concepts when using Anki to learn a programming language? I use Anki for tonnes of stuff, but haven't used it for learning programming languages/APIs.

I suspect that you are not running into safari's performance limits so much. I think it's more likely that your client-side code is doing something that interferes with the browser's event loop, and is thereby preventing the browser from processing ordinary operations like doubletap-to-zoom, scrolling, pinch-to-zoom, etc. If you have a lot of JavaScript operations to perform, sometimes you need to defer some of them until the next time the event loop comes around — so that the browser can "breathe", as it were.

GWT, for example, has a DeferredCommand and IncrementalCommand facility for this situation. I believe they are just wrapping the setTimeout(func, 0) trick. (See link below.) If Fay does not have such a facility, then you may need to do some upstream work to teach it how.

http://b.javascript.info/tutorial/events-and-timing-depth#as...

But I guarantee that even an iPad 2 should have enough oomph to tackle your modest needs. It does just just fine on more intensive things like Google docs, spreadsheets, reader, and plus. And Facebook.

If, for example, I have not yet asked the monads tutorial to compile and run a snippet, then the browser's JS thread should be entirely quiescent and the event loop should be responsive to my zoom, pan, and rotation requests. That it isn't implicates your code (and/or the code Fay emits) — not the browser. I hope the creators of Fay considered this while architecting it. If they didn't, it's unlikely that they would have arrived at the correct solution by accident, because ordinarily compilers never need to worry about being "a good citizen" to a browser's event loop.

Best of luck. I envy that you get to work on this!