School of Haskell Goes Beta(fpcomplete.com)
fpcomplete.com
School of Haskell Goes Beta
http://fpcomplete.com/school-of-haskell-goes-beta
70 comments
Everybody has a different list of a dozen intermed/advanced topics ;-}
http://www.reddit.com/r/haskell/comments/17gavl/what_you_con...
http://stackoverflow.com/questions/5778436/what-haskell-topi...
And most of those are fast moving topics these days but they're well covered in blogs, the Cafe list, stackoverflow, they just need to be collated/cataloged. At a minimum some wiki farming would address a lot of those. Unfortunately, I emailed the wiki contact a couple times about pitching in and never got response.
___________________
There's a few books you could look at, tho they're more building out what's in RWH, not up:
draft by Snoyman https://github.com/mezzohaskell/mezzohaskell
Bird's Functional algorithm pearls http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...
http://haskell.cs.yale.edu/wp-content/uploads/2013/01/HSoM3....
JA Alonso has another book of exercises (in Spanish http://www.cs.us.es/~jalonso/publicaciones/Piensa_en_Haskell...
also the FP in Scala (Morris, Chiusano, Bjarnason) may include some haskell code, I haven't read yet, but definitely covers a lot of these hot topics
http://manning.com/bjarnason/
http://www.reddit.com/r/haskell/comments/17gavl/what_you_con...
http://stackoverflow.com/questions/5778436/what-haskell-topi...
And most of those are fast moving topics these days but they're well covered in blogs, the Cafe list, stackoverflow, they just need to be collated/cataloged. At a minimum some wiki farming would address a lot of those. Unfortunately, I emailed the wiki contact a couple times about pitching in and never got response.
___________________
There's a few books you could look at, tho they're more building out what's in RWH, not up:
draft by Snoyman https://github.com/mezzohaskell/mezzohaskell
Bird's Functional algorithm pearls http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...
http://haskell.cs.yale.edu/wp-content/uploads/2013/01/HSoM3....
JA Alonso has another book of exercises (in Spanish http://www.cs.us.es/~jalonso/publicaciones/Piensa_en_Haskell...
also the FP in Scala (Morris, Chiusano, Bjarnason) may include some haskell code, I haven't read yet, but definitely covers a lot of these hot topics
http://manning.com/bjarnason/
> 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.
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!
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!
If you're reading this and understand those areas well, then consider donating some time towards improving the advanced track on the Haskell wikibook (http://en.wikibooks.org/wiki/Haskell).
I'd say you should take a look at research papers for those topics: But it's true, we are lacking advanced Haskell books.
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/
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/
There's definitely a big gap, but I'd still suggest diving in. Reading a few of the major Functional Pearls is tough going at first, but they're generally designed to be free-standing and practical.
About the top of your list: don't worry about Monads. Learn Applicatives first and foremost.
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.
Using Haskell in Production at Standard Chartered, we are seeing Applicatives crop up everywhere. For example, almost all of the time, our parsers (and even IO) need to be used only as Applicative, or at most as Alternative.
Applicatives also compose in interesting ways as opposed to Monads.
Applicatives also compose in interesting ways as opposed to Monads.
Any Haskell web-application framework is awesome - Yesod in particular as it has the most active community and written material for it.
I've lately been working on an (unpublished) project using Haskell+Yesod+Fay+Clay and it's remarkable how productive I am; in that most of my time is spent figuring out my types, writing the code, then...it's done? In Python I run into a lot of programmer related bugs that Haskell's rigid type system prevents. It can't prevent logic/flow "bugs" but it does keep a lot of other bugs out that would normally have me spending potential future hours fixing/debugging.
It's also not just the type safety that increases my productivity, it's also...Haskell. Abstraction in Haskell can make for very concise and correct programs.
Fay and Clay are particularly awesome too.
Haskell definitely has a learning curve, there was a steep curve for me and I already had significant functional programming experience (Erlang & Scheme). I'm really happy to see these guys taking that on!
I've lately been working on an (unpublished) project using Haskell+Yesod+Fay+Clay and it's remarkable how productive I am; in that most of my time is spent figuring out my types, writing the code, then...it's done? In Python I run into a lot of programmer related bugs that Haskell's rigid type system prevents. It can't prevent logic/flow "bugs" but it does keep a lot of other bugs out that would normally have me spending potential future hours fixing/debugging.
It's also not just the type safety that increases my productivity, it's also...Haskell. Abstraction in Haskell can make for very concise and correct programs.
Fay and Clay are particularly awesome too.
Haskell definitely has a learning curve, there was a steep curve for me and I already had significant functional programming experience (Erlang & Scheme). I'm really happy to see these guys taking that on!
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).
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.. :)
Kickstarter project? Chris Coyier did a great set for his site redesign, for example.
http://www.kickstarter.com/projects/150422311/screencasting-...
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.
If you decide to do so, you are welcome to post tutorials on the School of Haskell.
> 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? 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.
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'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.
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 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.
but to me Haskell is a different league.. Haskell-typing actually helps /me/, where i feel C++/Java-typing merely help the compiler.
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.
[deleted]
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.
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.
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.
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.
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.
With a little extra learning curve; it beats the pants off of Python + Pyramid + unit tests and lots of extra debugging time.
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.
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.
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.
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.
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.
HN never fails, just as I was browsing the web after reading pg assay about programming languages and the story of how he built what is now yahoo shop using lisp and deciding that instead of lisp I will learn Haskell this comes along. Looks very good and hope that it won’t be /too/ easy start without any challenges...
I don't think it will be too easy. For a taste, you could take a look at my "Haskell Fast & Hard" tutorial. If you signed for the beta you can get try it here:
https://haskell.fpcomplete.com/user/yogsototh/haskell-fast-h...
If you don't already have a beta account. You can try the original non interactive version here:
http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
I had the chance to be an alpha user of School of Haskell and I copied the tutorial to it. Clearly the interactivity provide a clear benefit.
Concerning the difficulty of my tutorial, it goes like this:
1 - very easy 2 - easy 3 - medium 4 - hard 5 - very hard 6 - annex is kind of brutal difficulty
And actually, there is at least five more level of difficulty if you want to "master" some advanced feature of Haskell.
But one thing that no tutorial is able to give, is the feeling of joy when writing Haskell. It is something you experience only when doing your firsts non trivial programs.
https://haskell.fpcomplete.com/user/yogsototh/haskell-fast-h...
If you don't already have a beta account. You can try the original non interactive version here:
http://yannesposito.com/Scratch/en/blog/Haskell-the-Hard-Way...
I had the chance to be an alpha user of School of Haskell and I copied the tutorial to it. Clearly the interactivity provide a clear benefit.
Concerning the difficulty of my tutorial, it goes like this:
1 - very easy 2 - easy 3 - medium 4 - hard 5 - very hard 6 - annex is kind of brutal difficulty
And actually, there is at least five more level of difficulty if you want to "master" some advanced feature of Haskell.
But one thing that no tutorial is able to give, is the feeling of joy when writing Haskell. It is something you experience only when doing your firsts non trivial programs.
You should still learn Lisp unless you are certain that Haskell is already in the perfect form for what you want to do. Lisp gives you unprecedented freedom to transform the language into the form that suits you best.
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.
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.
Haskell introduces restrictions with its non-homoiconic syntax, static type system, and pure effects system. I am not yet convinced that these restrictions are necessary.
- I am not convinced that it is worth it to throw out the benefits of homiconicity in order to create a distinction between code and data. I find that Haskell's heteroiconic syntax is actually harder to read and write then S-expressions.
- In mathematics all sets of the same cardinality are isomorphic. In assembly language there isn't really any notion of types besides cardinalities counted in bits. I am not convinced that we need to introduce a system of static typing besides an optional system of cardinalities. I am skeptical of the claims that we need static typing to eliminate errors and bugs.
- I am not convinced that we should have purely functional programming based upon monadic IO rather then other alternatives like uniqueness types. Perhaps a better option is to have a term rewriting and macro expansion phase that is purely functional and to encapsulate all side effects in a seperate evaluation phase.
If you are certain that Haskell's non-homoiconic syntax, static type system, and pure effects system exist in the right form for what you want to do then by all means use them. Otherwise, consider that Lisp doesn't distinguish between code and data so it gives you unprecendented freedom to shape the language into the form that suits you best.
- I am not convinced that it is worth it to throw out the benefits of homiconicity in order to create a distinction between code and data. I find that Haskell's heteroiconic syntax is actually harder to read and write then S-expressions.
- In mathematics all sets of the same cardinality are isomorphic. In assembly language there isn't really any notion of types besides cardinalities counted in bits. I am not convinced that we need to introduce a system of static typing besides an optional system of cardinalities. I am skeptical of the claims that we need static typing to eliminate errors and bugs.
- I am not convinced that we should have purely functional programming based upon monadic IO rather then other alternatives like uniqueness types. Perhaps a better option is to have a term rewriting and macro expansion phase that is purely functional and to encapsulate all side effects in a seperate evaluation phase.
If you are certain that Haskell's non-homoiconic syntax, static type system, and pure effects system exist in the right form for what you want to do then by all means use them. Otherwise, consider that Lisp doesn't distinguish between code and data so it gives you unprecendented freedom to shape the language into the form that suits you best.
> (laziness, do notation and a very spartan syntax)
I do not know whether spartan is the right adjective. The Haskell syntax is rather bendable, but that's because you can do almost everything with the basic tools of operators and function calls. On the other hand, the Haskell syntax space is rather crowded already, and it's not trivial to add without hitting something that's already there.
I do not know whether spartan is the right adjective. The Haskell syntax is rather bendable, but that's because you can do almost everything with the basic tools of operators and function calls. On the other hand, the Haskell syntax space is rather crowded already, and it's not trivial to add without hitting something that's already there.
Lisp (and especially Racket) is fun. But Haskell also allows preprocessing your code.
I learned Haskell in my first algorithm course in the University, mine was the last class ever to do it in that university, the following semester they switched completely to Pascal and later to Java.
These are good news, I just can't wait to see that IDE.
These are good news, I just can't wait to see that IDE.
Isn't switching from Haskell to Pascal or Java a huge switch? That's a change in thinking style, even!
As excited as this makes me, I am way more excited to hear about the "full blown Haskell IDE" they mention. Is this a cloud service?
It may be leksah, which is currently available on hackage, though I've never been able to get it to compile (I haven't tried that hard)...
Not likely leksah http://fpcomplete.com/designing-the-haskell-ide/
FP Complete is currently developing a Haskell IDE which will be exposed as a cloud service.
Gregg Lebovitz talks about it here: http://www.youtube.com/watch?v=IM_OSykXKxM
Gregg Lebovitz talks about it here: http://www.youtube.com/watch?v=IM_OSykXKxM
Lady's Illustrated Primer, ha!
I've been working my way through "Learn You a Haskell For Great Good". I worked my way up around functors and monads. Then I stopped for a while. This new School will be interesting :-)
I've been working my way through "Learn You a Haskell For Great Good". I worked my way up around functors and monads. Then I stopped for a while. This new School will be interesting :-)
Yeah, this will be interesting. I've also been going through Learn You A Haskell, making an Anki deck as I go. Slow work, but Anki will help me retain everything I'm learning.
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.
Good question, I think about that a lot. So far it seems that it's better to break down too much rather than not enough. Because at worst you'll have easy cards. In other decks I have some puzzles that require more steps than I can do in my head, and I always feel annoyed when those cards come up.
For programming languages, it seems like a good fit to use it for rules and syntax, and the principles behind why the language works the way it does. I don't think I'll use it to ask me how to write scripts, though.
For programming languages, it seems like a good fit to use it for rules and syntax, and the principles behind why the language works the way it does. I don't think I'll use it to ask me how to write scripts, though.
This is a very promising approach. I was blown away when they actually executed a web application and the working web page was shown inside an IFRAME. This means that I could learn programming from any device, even a tablet, without needing to install anything.
Thanks. One of our design points in fact is that you can use the School from a tablet. We're still a bit concerned about Safari performance on the iPad, but we're on the case!
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!
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!
Signed up. :)
This is my nth attempt at learning Haskell, but I have a fairly good handle on most of the basics.
How is this better than working through a book? If I can't download and install Haskell, then learning the language is the least of my problems.
The important part is to engage newcomers. This is easiest to do if there is no barrier to playing with Haskell. They can always install Haskell once they're a bit more familiar with it and see why it's awesome.
If you're already planning to learn Haskell and have a book about it, this is useful because it lets the author of the tutorial integrate the material more closely with the language environment. This makes things like little exercises to illustrate a particular point easier to do.
If you're already planning to learn Haskell and have a book about it, this is useful because it lets the author of the tutorial integrate the material more closely with the language environment. This makes things like little exercises to illustrate a particular point easier to do.
alas waiting list
doubt i'll switch from scheme but still interested
doubt i'll switch from scheme but still interested
just got my log in
My main issue with existing books and tutorials is that I'm left in the dark about the more interesting/advanced parts of Haskell.
Some of the areas I would like to have a better understanding:
- More advanced kinds of monads e.g. Logic, Continuation
- Monad Transformers
- Arrows
- Rank-N types
- GADTs
- Category theoretical ideas e.g. Bananas and Lenses
- Type derivatives and TypeClass abuse c.f. Conor McBride
- Control patterns like Iteratees, Generic Zippers c.f. Oleg Kiselyov, Chung-Chieh Shan
I have an intuitive grasp of the above, but to me Haskell is more about programming with types than anything functional.
On the practical side, it seems like Haskell excels as a language processor, and parsing/compilation would be a great way to explore how to structure certain kinds of applications (like web servers, graphics pipelines, etc).
Please don't make it too real-world, I already have bash ;)