Re: [Haskell-cafe] Tutorial on Haskell: Use closures
Closures look like magic to those who don't know them. So you might try
something like this (which I have not compiled BTW):
-- Haskell version
data Train = Train {departs :: Time, platform :: Int }
departsBefore :: Time - Train - Bool
departsBefore t train = t departs train
beforeAfter :: Time - [Train] - ([Train], [Train])
beforeAfter t = partition (departsBefore t) departures
The crucial point is that partition takes a function argument, but
that function has to carry the 't' argument with it.
The only way you could write partition as a generic function in Java
would be to define an interface class discriminator which is passed to
partition. discriminator is then specialised for every closure you
want to create. This is a lot of code for something that can be done
in-line in Haskell. The fact that all functions are curried by default
also saves having lots of lambdas.
You might also show how deforestation optimises functional pipelines.
Lots of Haskell code contains lines of the form
foo = bar x $ foldr1 boz $ map baz ls
In other FP languages (like Erlang) you can use this style, but it tends
to be inefficient because of all the intermediate lists. Haskell is
free to arrange the functions how it likes because of purity. Hence it
can optimise this pipeline into a single loop. Obviously you know much
more about this than I do, but to me its one of the biggest arguments in
favour of purity.
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Yep - I've seen it in course work I've set in the past - random walk through the arrangement of symbols in the language (it was a process algebra work and proof system to check deadlock freedom). ... but ... Haskell even helps those people - if you've created something that works (and you are at least sensible to create a test suite be it regression or property based) - then there is more confidence that they've coded a solution (if not a good one). Haskell raises the value of formality (both ecomomically and in terms of its caché) - changin the mindset of the masses - creating the meme - that's tricky. Especialy if they're really off the B Ark! (http://www.bbc.co.uk/cult/hitchhikers/guide/golgafrincham.shtml) Neil On 18/04/07, Michael Vanier [EMAIL PROTECTED] wrote: R Hayes wrote: On Apr 17, 2007, at 4:46 PM, David Brown wrote: R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. I've seen this too, but I would not use the word debugging to describe it. I don't think I agree that enjoying debugging is a sufficient symptom for diagnosing this condition. There are many people that love the puzzle-box aspect of debugging. Some of them are very talented developers. R Hayes rfhayes@/reillyhayes.com Dave I agree with the latter sentiment. I call the thwacking at it approach random programming or shotgun programming, the latter suggesting that it's like shooting at the problem randomly until it dies. I prefer not having to debug, but when I do have to I find it fun (up to a point). Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On 18/04/07, R Hayes [EMAIL PROTECTED] wrote: One of the truly powerful things about Haskell is the short distance between theory and practicality. The problem is how to demonstrate this convincingly. The ability to prove a program's correctness is regularly trotted out for show in this arena (or at least the lighter-weight claim that programs that compile usually work). I don't think that most developers (and certainly not the OSCON crowd) are ready to drink that kool-aid. They *enjoy* debugging and are tired of the static vs. dynamic debate. But the ability to reason about programs has borne fruit that I *do* think they will appreciate. Because many of them care about performance. I completely agree with you there. Someone earlier in the thread mentioned that QuickCheck almost in passing, but I think it should be emphasised: *QuickCheck is a really powerful way to work.* The real pain in the butt with unit tests is having to write the damn things. Especially for corner cases - if they were easy to reason about they wouldn't really be corner cases, would they? QC allows you to sidestep that neatly by generating a set of unit tests from a specification. And often generating cases you *wouldn't* have thought of yourself. Genius! It does rely on a functional mindset, however. No state-fiddling going on behind our backs. But maybe if you sell the idea first - create hundreds of unit tests on demand without lifting a finger - then people will make the leap of their own accord. Because let's face it, selling referential transparency is a pretty dead loss ;-) Salesmanship is about pointing out problems people have [1]. The problem R Hayes identifies here is that theory is great in theory, but in practise it's *too much work*. And short of creating a system where even your QC properties are auto-generated (I live in eternal hope...), this is a really important advances which people should learn more about. [1]: http://weblog.raganwald.com/2007/01/what-ive-learned-from-sales-part-i.html Cheers, Dougal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Dougal Stanton wrote: *QuickCheck is a really powerful way to work.* The real pain in the butt with unit tests is having to write the damn things. Especially for corner cases - if they were easy to reason about they wouldn't really be corner cases, would they? QC allows you to sidestep that neatly by generating a set of unit tests from a specification. And often generating cases you *wouldn't* have thought of yourself. Genius! For the regex-tdfa project, the unit tests from the ATT site defined important semantic corners that some implementations got wrong. Once I had code that worked with *all* those examples, the QuickCheck generated strings and regular expressions made for some quite weird random tests that still found holes in my code. And holes in the TRE c-library code. And holes in the standard c-library regex.h of OS X 10.4.x. So I am quite impressed by Quickcheck. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Dougal Stanton wrote: On 18/04/07, R Hayes [EMAIL PROTECTED] wrote: One of the truly powerful things about Haskell is the short distance between theory and practicality. The problem is how to demonstrate this convincingly. The ability to prove a program's correctness is regularly trotted out for show in this arena (or at least the lighter-weight claim that programs that compile usually work). I don't think that most developers (and certainly not the OSCON crowd) are ready to drink that kool-aid. They *enjoy* debugging and are tired of the static vs. dynamic debate. But the ability to reason about programs has borne fruit that I *do* think they will appreciate. Because many of them care about performance. I completely agree with you there. Someone earlier in the thread mentioned that QuickCheck almost in passing, but I think it should be emphasised: *QuickCheck is a really powerful way to work.* Recently Neil Mitchell made an interesting blog post on this (http://neilmitchell.blogspot.com/2007/04/coding-nirvana.html). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Tutorial on Haskell
I guess it is time to give my two cents on this topic I am definitely not an expert Haskell programmer I am a mere hobbyist I make my bread coding Java/C++/C. I think the two things I like most about Haskell are 1. Its methods of combination Lazy Eval, Function composition and Higher order functions aka the glue. Showing these off and how they compare and are better than many other languages would be a nice selling point. 2. Its type system and the kind of errors it eliminates, and the way it allows you to structure programs. Things I like least about Haskell (These are Haskell show stoppers for me) are 1. The tooling no good IDE for it. 2. The Libraries/Available Code Examples (Missing Functionality, Sparse availability, maturity, documentation, ability to understand them because many of them use Monads and Arrows, Functors etc). I have to strongly disagree with the statement that developers like to debug. Debugging is necessary because you can't reason about any sizeable piece of code just is not tractable even in Haskell. Now automated tools for reasoning about programs are very cool but lets face it no real world developer will sit down start to manually formally reason about large pieces of code. Picking Very Mathematical examples for the tutorial will also alienate typical developers. I am personal very interested in Category theory as it pertains to software engineering but it is not very accessible for someone who is trying to learn about it (aka me) never mind someone who could care less. Troy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On 4/18/07, Taillefer, Troy (EXP) [EMAIL PROTECTED] wrote: I have to strongly disagree with the statement that developers like to debug. Debugging is necessary because you can't reason about any sizeable piece of code just is not tractable even in Haskell. Now automated tools for reasoning about programs are very cool but lets face it no real world developer will sit down start to manually formally reason about large pieces of code. I think the emphasis when mentioning reasoning really shouldn't be you can reason formally about your programs and prove that they don't go wrong, nor when it has gone wrong, you can reason about the program to figure out why, it should be since the language doesn't do batshit insane things behind your back, your programs will mostly work the first time. The reasoning isn't an active task that you schedule time for, at least for a casual user like me, it's part of the actual programming. You do reasoning when writing in C++ as well, but you often get it wrong (because the language is, shall we say, unreasonable?) and that causes bugs. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Here here. This reminds me of a recent discussion on the cafe. Thee OP amounted to: What are the monad laws good for?. The answer was: It means the monad doesn't do surprising things and its behavior is congruent with the basic intuitions of sequenced computation. In my eyes, proving nice properties about programs and moreover calculating the programs themselves are pillars of computer science. However, I think it's helpful (for this sort of presentation crafting) to be aware of the disparity between computer science and most programming in the trenches. That said, Sylvan points out that the disparity isn't a unbridgeable schism--it's just that the concepts don't yet map as directly as we'd like. On 4/18/07, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 4/18/07, Taillefer, Troy (EXP) [EMAIL PROTECTED] wrote: I have to strongly disagree with the statement that developers like to debug. Debugging is necessary because you can't reason about any sizeable piece of code just is not tractable even in Haskell. Now automated tools for reasoning about programs are very cool but lets face it no real world developer will sit down start to manually formally reason about large pieces of code. I think the emphasis when mentioning reasoning really shouldn't be you can reason formally about your programs and prove that they don't go wrong, nor when it has gone wrong, you can reason about the program to figure out why, it should be since the language doesn't do batshit insane things behind your back, your programs will mostly work the first time. The reasoning isn't an active task that you schedule time for, at least for a casual user like me, it's part of the actual programming. You do reasoning when writing in C++ as well, but you often get it wrong (because the language is, shall we say, unreasonable?) and that causes bugs. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
I still love Haskell, but... since the language doesn't do batshit insane things behind your back - Hmmm... I'd contend that the Haskell language is the one language that does the most batshit insane things behind your back, for instance list fusion. This is probably because there are many more batshit insane things that can be done without playing russian-roulette games with your semantics. I believe that the problem is with the semantics: if all the relevant semantics of your program are clear to you, then you understand it. Otherwise, you don't. Regardless of language. C++ semantics are hard to understand due to the existence of side effects, which explode the dependencies between parts of the code to nuclear proportions. The optional semantic notation const is the only tool available to help diminish the problem. Haskell semantics are typically hard to understand wherever strictness matters, which can also be very hard to figure out. Optional strictness annotations are the tool there. Polymorphism problems also come to mind, in which case type signatures are the tool. And performance I always find hard to reason about in Haskell, and there is no tool available besides the strictness annotations (or inline pragmas and such). If it performs very well, because fusion happened or whatever, then great. Otherwise, IO-izing is the only tool I know to apply to your code to make it tractable for performance (so you can lay out your data in a performant manner and such). So Haskell semantics, in my experience, are sometimes just as obscure and hard to understand as those of C++. Fortunately, that's a situation that maybe changes to the language, or maybe more literature, can improve. One example of a polymorphism semantic problem I encountered recently: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem Nice article. Relevant and informative. My first thought was... how silly. He's pairing up a type class with an abstract datatype (Language and SafeString). That's a waste. He could have just used a type class everywhere, and that would have worked fine. I hope you see that. Wherever he uses SafeString he must, by necessity, add the Language context to its parameter. So.. you can make SafeString a type class, with members empty, frag=litfrag, text=littext, render=natrep and lang=language, and the basic code turns much, much more concise. Users of the library need to define empty, whereas they didn't need to previously, but that's a relatively small price to pay. I tried that. Then, when I saw the compiler errors, it downed on me. The whole thing was done in this manner just so that he can instance Show (SafeString l). Instancing Show l is not an option due to the way class instantiation contexts are not part of the instance itself. Also, so that he could define showsPrec. Therefore, with the new and improved SafeString I was trying to make, there's more of a burden on the individual implementations of safe strings. And all that was kinda hidden in the semantics, undocumented, and there was no way for a strong novice like myself to figure it out without trying the alternative, even though it is a small and simple example. Maybe someone should properly document the class-record combo pattern or something. Or maybe it is documented and I haven't seen it. :-) JCAB On Wed, 18 Apr 2007 10:50:04 -0700, Sebastian Sylvan [EMAIL PROTECTED] wrote: I think the emphasis when mentioning reasoning really shouldn't be you can reason formally about your programs and prove that they don't go wrong, nor when it has gone wrong, you can reason about the program to figure out why, it should be since the language doesn't do batshit insane things behind your back, your programs will mostly work the first time. The reasoning isn't an active task that you schedule time for, at least for a casual user like me, it's part of the actual programming. You do reasoning when writing in C++ as well, but you often get it wrong (because the language is, shall we say, unreasonable?) and that causes bugs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FW: [Haskell-cafe] Tutorial on Haskell
===LONG WINDED RANT WARNING == I am not try to hate on Haskell obviously I am a fan otherwise I wouldn't be on this list but criticizing other languages is not only a pointless waste of time it is logically flawed on many levels. A lot of the best software is written and still being written in C++ so I will have to disagree with you that C++ is unreasonable. C++ is dangerous and has its flaws especially in the hands of a noob but it is also has some merits as well. People have very logical reasons for choosing a programming language including 1. Familiarity 2. Available people to work with 3. Tools 4. Libraries 5. Legacy 6. Political 7. Personal Preference etc... In terms of reasoning it is easier to reason in a language/Paradigm that you are familiar with than one that might be better but you are totally unfamiliar with and must learn from scratch. Go on IRC #HASKELL and see how many people are struggling conceptual ideas like Monads, Arrows and Functors I don't go there a lot but every time I am there are a couple of people who are asking questions like just what is a Monad. For myself I want to learn Category Theory because it seems powerful just like Set Theory (which I have found extremely useful). I find manipulating pointers and mutable variables much easier to understand and saner. Maybe if I was a mathematician instead of an Engineer/Computer Scientist I would feel different. Saying Haskell is better and everyone should use it because it is better is about as futile as saying we should all be speaking Esperanto because it is better then English. You would be an awfully lonely person with almost nobody to talk to if all you spoke was Esperanto or Haskell for that matter. I have yet to meet face to face another person who has even written toy code in Haskell let alone any real significant app. I can't use Haskell at work because no one could maintain it. I can't use Haskell in my graduate studies since my supervisor can't read Haskell. So I am stuck writing toy code as a hobby and an educational experience. Programs are mostly for humans to read and modify and lets face it there isn't a lot of people fluent in Haskell. So if I want to work and interact with other Software professionals I better be able to speak the lingua franca which is a derivative of C aka C/C++/C#/Java ect. Obviously C++ isn't that bad because people can write good cool software in it. I like Haskell but I haven't seen a ton of Killer Haskell apps yet ( Or even one for that matter). DARCS is coming close if they fix their conflict problems then Haskell will have its first killer app that I know off. I heard they are working on it this summer looking forward to it DARCS is really cool. Sorry for the long rant but I get tired of people with their juvenile and unconstructive statements like C++ sucks Or Language X is better then Language Y even if it could ever be objectively true (which I am sorry it can't be) who cares. END RANT=== From: Sebastian Sylvan [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 1:50 PM To: Taillefer, Troy (EXP) Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Tutorial on Haskell On 4/18/07, Taillefer, Troy (EXP) [EMAIL PROTECTED] wrote: I have to strongly disagree with the statement that developers like to debug. Debugging is necessary because you can't reason about any sizeable piece of code just is not tractable even in Haskell. Now automated tools for reasoning about programs are very cool but lets face it no real world developer will sit down start to manually formally reason about large pieces of code. I think the emphasis when mentioning reasoning really shouldn't be you can reason formally about your programs and prove that they don't go wrong, nor when it has gone wrong, you can reason about the program to figure out why, it should be since the language doesn't do batshit insane things behind your back, your programs will mostly work the first time. The reasoning isn't an active task that you schedule time for, at least for a casual user like me, it's part of the actual programming. You do reasoning when writing in C++ as well, but you often get it wrong (because the language is, shall we say, unreasonable?) and that causes bugs. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FW: [Haskell-cafe] Tutorial on Haskell
On 4/18/07, Taillefer, Troy (EXP) [EMAIL PROTECTED] wrote: Sorry for the long rant but I get tired of people with their juvenile and unconstructive statements like C++ sucks Or Language X is better then Language Y even if it could ever be objectively true (which I am sorry it can't be) who cares. That's not really what I said, I simply said that Haskell is easier to reason about, and I find it is. And C++ is very difficult to reason about, so it's a good comparison (and an easy target :-)). This is getting a bit OT, the thread was about promoting the benefits of Haskell, not a language flame-war. The use of C++ was just a tongue-in-cheek example of a language where you have to spend more effort making sure your programs are correct because it's not as easy to reason about. End of message. Beginning of counter-rant: I write C/C++ every day, and a recent example of what I'm talking about is this: We have a tool which does some very complex and full-of-special-cases processing. I'll abstract it a bit. It essentially does the tasks A, B, and C. Now, I need information in B, which is only available after C is computed. First off, in Haskell that wouldn't be a problem 'cause you'd just set up the relationships between your data and go home early. In C++ not only is this more or less impossible to sort out nicely (while keeping separate concerns separate), but even the work-around (which in my case means moving parts of C down below B) is way too fragile to be practical when you risk disrupting production. I mean in my case I can see no obvious reason for why I shouldn't just move that code around by looking at it, it LOOKS like it should work, but because it's C++ such an operation is like remodelling a house of cards. There's not telling how many cases that will break in subtle ways because of all the side effects and invisible dependencies. The end result? We just avoid the problem by not doing the Right Thing in certain circumstances. It sucks, but it beats the alternative of trying to reason about a complex C++ program and ending up with some obscure error or crash six months later. There's a bit of a turing tarpit like danger here. Where you fall into the habit of being the good guy, defending languages and insisting that they aren't that bad, the end result is that progress is slowed down. Languages are just tools. Would you defend a BlackDecker power drill? Comparing and criticizing them in order to end up with better tools (and a better knowledge about which tool is better when) is useful and should be done more often by more people. C++ really is quite bad when it comes to being able to reason about your program. Really. In Haskell, if you change a few function calls you know exactly what will happen because it's localized, in C++ it's not so simple because you have to worry about the side effects (not to mention all the caveats in the language itself -- see the Effective C++ books for the short list of why C++ will stab you in the back at the first chance if you're not careful). There are reasons for using C++, but there is no denying that there are many good reasons for why you should choose something else instead if you can, and since this thread was about promoting the good stuff about Haskell, the ease-of-reasoning argument is certainly relevant (and I don't think it's all that controversial to use C++ as an example of a language which is difficult to reason about). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
As one who teaches programming in a lot of different languages, I can state unequivocally that strong static typing of the Haskell or Ocaml variety is (in addition to all its other benefits) a godsend to the instructor. So many incorrect ways of writing programs are simply ruled out right at the start that it makes it easier to concentrate on what really matters. The downside is that sometimes you get programmers from an imperative languages background who cannot figure out why some simple code is giving them a type error (for instance, by not putting in an else clause in an if statement). Mike Neil Davies wrote: Yep - I've seen it in course work I've set in the past - random walk through the arrangement of symbols in the language (it was a process algebra work and proof system to check deadlock freedom). ... but ... Haskell even helps those people - if you've created something that works (and you are at least sensible to create a test suite be it regression or property based) - then there is more confidence that they've coded a solution (if not a good one). Haskell raises the value of formality (both ecomomically and in terms of its caché) - changin the mindset of the masses - creating the meme - that's tricky. Especialy if they're really off the B Ark! (http://www.bbc.co.uk/cult/hitchhikers/guide/golgafrincham.shtml) Neil On 18/04/07, Michael Vanier [EMAIL PROTECTED] wrote: R Hayes wrote: On Apr 17, 2007, at 4:46 PM, David Brown wrote: R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. I've seen this too, but I would not use the word debugging to describe it. I don't think I agree that enjoying debugging is a sufficient symptom for diagnosing this condition. There are many people that love the puzzle-box aspect of debugging. Some of them are very talented developers. R Hayes rfhayes@/reillyhayes.com Dave I agree with the latter sentiment. I call the thwacking at it approach random programming or shotgun programming, the latter suggesting that it's like shooting at the problem randomly until it dies. I prefer not having to debug, but when I do have to I find it fun (up to a point). Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
G'day all. I wrote: I think you could. What you need to convince a strict programmer of is that laziness gives you modularity. The Graham Hutton Sudoku solver is a nice example, but it'd be cool if we had a similar example that was less cheesy than Sudoku. OK, it's not pretty, but this is diff(1) in 120 lines: http://andrew.bromage.org/darcs/diff/ It illustrates: - Lazy evaluation (dynamic programming, lazy I/O, infinite lists) - Function pipelining with (.) and ($) - Monads - Immutable arrays - List comprehensions - Algebraic data types - Type-safe type synonyms (newtype) - Fancy newtype deriving (Num) - Smart constructors - Pattern matching with at-patterns - Lambda expressions - Operator sections - More besides Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
In my opinion, one of the things that makes Haskell difficult to learn is the value system. I'm not referring to pure vs. impure. Instead, I am referring to the beliefs and principles held by the Haskell community that are not shared with most of the programming world. Principles like It is valuable to be able to reason about programs rigorously. This is foreign to most developers. When they get to the section of a Haskell book that starts talking about this, their eyes glaze over and they skip over to the more practical stuff. By the time they get to Monads they're ready to rip their eyes out because the book is too theoretical or too academic. One of the truly powerful things about Haskell is the short distance between theory and practicality. The problem is how to demonstrate this convincingly. The ability to prove a program's correctness is regularly trotted out for show in this arena (or at least the lighter- weight claim that programs that compile usually work). I don't think that most developers (and certainly not the OSCON crowd) are ready to drink that kool-aid. They *enjoy* debugging and are tired of the static vs. dynamic debate. But the ability to reason about programs has borne fruit that I *do* think they will appreciate. Because many of them care about performance. I don't need to tell the subscribers to this list that the shockingly good performance of code written using Data.ByteString.Lazy is a direct result of being able to reason about programs. Obviously, the details of the fusion techniques are outside the scope of any introductory tutorial. But I think it would be useful to quickly implement a wc -l equivalent and explain why it's faster than the simple C equivalent. Nothing overly deep, just draw the line from reasoning about programs to fusion and on to amazing performance (capping it off with the fact the the fusion optimization is in the *Library*, not baked in to the compiler). At a minimum, it shows that being able to reason about programs rigorously can have a payoff in a currency that they value. R Hayes rfhayes@/reillyhayes.com On Apr 16, 2007, at 1:34 AM, Simon Peyton-Jones wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tutorial on Haskell
What would be really useful is a Haskell Cookbook that shows how to do in Haskell things that are so easily done in imperative languages. How to solve simultaneous equations using Gaussian elimination comes to mind. Lots of examples would be great. Dave Feustel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On Apr 17, 2007, at 4:46 PM, David Brown wrote: R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. I've seen this too, but I would not use the word debugging to describe it. I don't think I agree that enjoying debugging is a sufficient symptom for diagnosing this condition. There are many people that love the puzzle-box aspect of debugging. Some of them are very talented developers. R Hayes rfhayes@/reillyhayes.com Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
R Hayes wrote: On Apr 17, 2007, at 4:46 PM, David Brown wrote: R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. I've seen this too, but I would not use the word debugging to describe it. I don't think I agree that enjoying debugging is a sufficient symptom for diagnosing this condition. There are many people that love the puzzle-box aspect of debugging. Some of them are very talented developers. R Hayes rfhayes@/reillyhayes.com Dave I agree with the latter sentiment. I call the thwacking at it approach random programming or shotgun programming, the latter suggesting that it's like shooting at the problem randomly until it dies. I prefer not having to debug, but when I do have to I find it fun (up to a point). Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tutorial on Haskell
Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
What about demonstrating the use of an Haskell interpreter as a pimped up calculator? multTable = putStr $ unlines [unlines [show x ++ ' ':show y ++ ' ':show (x*y)|y-[1..10]] | x-[1..10]] 2007/4/16, Simon Peyton-Jones [EMAIL PROTECTED]: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Dipl.-Inform. Steffen Mazanek Institut für Softwaretechnologie Fakultät Informatik Universität der Bundeswehr München 85577 Neubiberg Tel: +49 (0)89 6004-2505 Fax: +49 (0)89 6004-4447 E-Mail: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Give them a program that selects a bunch of files based on some filtering criteria, and then does something to each file. Kind of like find + xargs, but using haskell instead. Good recipe for sysadmins. There was a recent example involving parsing raw emails into a thread here http://groups.google.de/group/fa.haskell/browse_thread/thread/b80dc2836f63f270/4a020e087e5b2060?lnk=stq=%22haskell+cafe%22+email+rnum=3hl=en#4a020e087e5b2060 Maybe that could be simplified and something could be based on that. A one-liner using PCRE regex might also be of use. 2007/4/16, Simon Peyton-Jones [EMAIL PROTECTED]: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On 16/04/07, Thomas Hartman [EMAIL PROTECTED] wrote: Maybe that could be simplified and something could be based on that. A one-liner using PCRE regex might also be of use. Unless it can be performed with astounding dexterity, I don't think try to beat, for example, Perl at its own game will produce worthwhile results. What, instead, is Haskell's unique selling point? Non-strictness? Purity? Optional, composable, computation styles (ie, drop-in monads for non-determinism, continuations, state etc)? Succinct and elegant syntax? Something else? Cheers, D. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
There may be something to this point of view. On the other hand, it is easier for me to see examples that can connect back to something I am already familiar with. That said, I will mention something where perl *seemed* to be a fit, but later proved frustrating. To whit -- Doing something at the shell level, in parallel. Ideally, in such a way that it could scale to, for example, multiple processes on a multi processor box, or even distributed map-reduce using a botnet. I just couldn't figure out a good way to do this in perl, despite a recently published map-reduce module to the CPAN. It all just seemed to get icky. I couldn't plug in my bits of finished code in the way I would have liked to, forking and other fiddly bits just seemed to get in the way. Now, this is probably largely due to my inexperience with parallel thinking. However, I think part of it is also the limitations in the language. My simple task was to download a bunch of urls. This could be done with wget. What I got frustrated with was, speeding this up by doing things in parallel. There are a number of modules on the CPAN that purport to help with this... parallel fork manager... parallel web user agent... others... but things got messy fast, even through the core task (fetch a url) was extremely simple. That is something that got me thinking. So, an example to take a simple task (eg web fetch, but could be something else), and then scale it to work in parallel -- with threads, with map reduce, howsoever -- might be a good show of haskell's strehgths. I think there was even a post to haskell cafe about this today. To recap: transform a piece of simple code that works in serial, so it works in parallel. Maybe even a couple, or three ways: using forks, using threads, using map reduce. Compare and contrast this with doing the same transformation in perl. Perl should be messier. Hope this helps... 2007/4/16, Dougal Stanton [EMAIL PROTECTED]: On 16/04/07, Thomas Hartman [EMAIL PROTECTED] wrote: Maybe that could be simplified and something could be based on that. A one-liner using PCRE regex might also be of use. Unless it can be performed with astounding dexterity, I don't think try to beat, for example, Perl at its own game will produce worthwhile results. What, instead, is Haskell's unique selling point? Non-strictness? Purity? Optional, composable, computation styles (ie, drop-in monads for non-determinism, continuations, state etc)? Succinct and elegant syntax? Something else? Cheers, D. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Well, given that concurrency is a hot topic at the moment, how about something based on STM? E.g. perhaps some kind of instant messaging server? Or Twitter except scalable. By ruthlessly eliminating features, you could get the core of one of these down to something that could be built in three hours. But please, no Santa Clauses ;-) Neil Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On Mon, 2007-04-16 at 13:27 +0200, Thomas Hartman wrote: To recap: transform a piece of simple code that works in serial, so it works in parallel. Maybe even a couple, or three ways: using forks, using threads, using map reduce. This made me think of one of my favorite observations. You occasionally hear how the wonderful static type system just forces your program to be correct: if they compile, they work. We all know that this is an exaggeration, but there is one case when this seems to apply - when refactoring already working code. IME, it seems that whenever I tear my programs apart, as long as the type checker agrees the pieces all fit back together, the program works as i expect it to. (Perhaps not so easy to apply this to a tutorial setting?) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On Mon, 2007-04-16 at 11:06 +0100, Dougal Stanton wrote: A one-liner using PCRE regex might also be of use. Unless it can be performed with astounding dexterity, I don't think try to beat, for example, Perl at its own game will produce worthwhile results. One possibility is a task where the Perl hacker will pull out regular expressions, but where cleaner and more maintainable code can be written using Haskell. Possibly parsing a relatively simple, line based format with 'words', 'concat', 'split', et al.? Or a recursive format? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On 4/16/07, Ketil Malde [EMAIL PROTECTED] wrote: On Mon, 2007-04-16 at 13:27 +0200, Thomas Hartman wrote: To recap: transform a piece of simple code that works in serial, so it works in parallel. Maybe even a couple, or three ways: using forks, using threads, using map reduce. This made me think of one of my favorite observations. You occasionally hear how the wonderful static type system just forces your program to be correct: if they compile, they work. We all know that this is an exaggeration, No we don't! At least not anywhere near as much of an exaggeration as that statement would be about an strongly typed imperative language (sequencing can't be type checked*, imperative programs are mostly sequencing, thus imperative programs are mostly unchecked). Strong static typing + expression-based programming + rich support for custom data types = if the compiler doesn't beep, the program almost always works. I think this is a key selling point. Not sure how to convince people it's actually true in a 3 hour tutorial, though. * well, you can check scoping, but that's about it, right? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
On Mon, 2007-04-16 at 09:34 +0100, Simon Peyton-Jones wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon I'm really enthusiastic about parsec. Even though the principles are (still) far above my head, I've been able to use it on a .csv table produced by OO Calc (the spreadsheet). The tutorial is also very good, and maybe parsec is also an example of (possible) interaction of Haskell to 'modules' written in other programming languages. You can do something (simple but useful) with parsec after just an afternoon's reading. fwiw, summing up my own Haskell experience: I've been learning Haskell for a year now, and I find it very difficult. I miss a training in computer science and often I feel like the guy in that movie who's on a 500 mile trip driving an old lawn mower. Traffic zooms past, and often you depend on people who're willing to lend a hand. Having said that, it's also fun and I enjoy the pioneer spirit in the community. The major advantages of Haskell are, IMO, 1) the type system is a great aid to the programmer and programs are short. Therefore Haskell is very well suited for the independent developer who can't afford huge amounts of code. Open Source has many of those. 2) polymorphism is also a great advantage. You can write your program in the most general types using e.g. only equality and order, and fine tune them later to more specific types which perform better. 3) the difficulty of Haskell is not necessarily a bad thing, it also makes it interesting, and there are many good libraries to use. But Haskell is also pretty scaleable, in the sense that you can do a lot of things just with recursion, then do them better with maps, folds, list comprehensions, then do them better with some monadic replacements, and so on. 4) there is a very helpful and knowledgeable community. A major disadvantage of Haskell is the lack of books, especially with regard to intermediate level programming and the libraries. Documentation that is available varies in quality and is, in general, fragmented. Best Regards, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Hi I think its important to cover whats different about Haskell. Things like laziness are cool, but are harder to convince a strict programmer that they are useful. Types however are obviously very handy, if you can focus on why a Haskell program is so obviously correct easily. 1) the type system is a great aid to the programmer and programs are short. Therefore Haskell is very well suited for the independent developer who can't afford huge amounts of code. Open Source has many of those. I'd also at least demonstrate Hoogle, but perhaps I'm biased :-) 2) polymorphism is also a great advantage. You can write your program in the most general types using e.g. only equality and order, and fine tune them later to more specific types which perform better. I'd also focus on the fact that polymorphism can be inferred, in things like C++/Ada using polymorphism means littering the code with hints about the polymorphism. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Hans van Thiel wrote: On Mon, 2007-04-16 at 09:34 +0100, Simon Peyton-Jones wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon I'm really enthusiastic about parsec. Even though the principles are [cut] 4) there is a very helpful and knowledgeable community. It is significant that Parsec has been and continues to be a lure of Haskell. Also, the community, in my opinion, is one of the greatest boons of the language, but I'm not sure how to convey that. This blog article (http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem) was/is fairly popular and demonstrates many aspects of Haskell and the way Haskellers think. Some of the recent ByteString stuff that does interesting things faster and much cleaner than C may also be a good example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
One technique I find compelling is (ab)using the type class system for meta programming. Something from Lightweight Static Resources, Faking It, or Hinze's Full Circle slides might be really attractive. Perhaps Danvy's Haskell printf? The hook might be: Yeah, you've heard of strong static typing and polymorphism, but did you know you could do this? Also: generic programming is always a hot topic. On 4/16/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Tutorial on Haskell
Simon, Hopefully a video of this tutorial would be made available as a learning resource for those of use who can't make it to this Convention. Troy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Peyton-Jones Sent: Monday, April 16, 2007 4:34 AM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Tutorial on Haskell Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Tutorial on Haskell
Hopefully! Do suggest it to the OSCON organisers: the one I'm in touch with is Vee McMillen [EMAIL PROTECTED] Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Taillefer, Troy (EXP) | Sent: 16 April 2007 15:08 | To: Simon Peyton-Jones; haskell-cafe@haskell.org | Subject: RE: [Haskell-cafe] Tutorial on Haskell | | Simon, | | Hopefully a video of this tutorial would be made available as a learning | resource for those of use who can't make it to this Convention. | | Troy | | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Simon | Peyton-Jones | Sent: Monday, April 16, 2007 4:34 AM | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] Tutorial on Haskell | | Friends | | I have agreed to give a 3-hr tutorial on Haskell at the Open Source | Convention 2007 | http://conferences.oreillynet.com/os2007/ | | I'm quite excited about this: it is a great opportunity to expose | Haskell to a bunch of smart folk, many of whom won't know much about | Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll | be practitioners rather than pointy-headed academics. | | One possibility is to do a tutorial along the lines of here's how to | reverse a list, here's what a type is etc; you know the kind of | thing. But instead, I'd prefer to show them programs that they might | consider *useful* rather than cute, and introduce the language along the | way, as it were. | | So this message is to ask you for your advice. Many of you are exactly | the kind of folk that come to OSCON --- except that you know Haskell. | So help me out: | | Suggest concrete examples of programs that are | * small | * useful | * demonstrate Haskell's power | * preferably something that might be a bit | tricky in another language | | For example, a possible unifying theme would be this: | http://haskell.org/haskellwiki/Simple_unix_tools | | Another might be Don's cpu-scaling example | http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 | | But there must be lots of others. For example, there are lots in the | blog entries that Don collects for the Haskell Weekly Newsletter. But | I'd like to use you as a filter: tell me your favourites, the examples | you find compelling. (It doesn't have to be *your* program... a URL to | a great blog entry is just fine.) Of course I'll give credit to the | author. | | Remember, the goal is _not_ explain monads. It's Haskell is a great | way to Get The Job Done. | | Thanks! | | Simon | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Neil Mitchell [EMAIL PROTECTED] writes: (snip) I think its important to cover whats different about Haskell. Things like laziness are cool, but are harder to convince a strict programmer that they are useful. (snip) Mmmm, it took me a while to really find laziness useful, and that was normally to let me create complex things that were mutually dependent on each other, releasing me from some housekeeping - some calculation in one would help the other creep along, and vice versa. I'm afraid no examples come easily to mind, though. BTW, I wonder if it's too much difficulty to show off STM. -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
I found this blog post, which describes a way to protect against SQL injection attacks using the type system, to be really enlightening. http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Having just read Simon Marlow's paper on the Haskell Web Server, I think it might be interesting to at least mention it, and how simple it is, while still performing well. Also, I second the comment several have made so far that talking about concurrency is important. Haskell does it better than most languages, and people care about concurrency these days. Admittedly, these aren't very concrete suggestions. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Mark T.B. Carroll wrote: I'm afraid no examples come easily to mind, though. Here's a simple one: reading a flattened graph from disk. If your flattened representation contains forward references, you have to fix them up in a strict language. In a lazy language, you can refer to elements you haven't yet read, eliminating that book-keeping. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Bryan O'Sullivan [EMAIL PROTECTED] writes: Mark T.B. Carroll wrote: I'm afraid no examples come easily to mind, though. Here's a simple one: reading a flattened graph from disk. If your flattened representation contains forward references, you have to fix them up in a strict language. In a lazy language, you can refer to elements you haven't yet read, eliminating that book-keeping. That's a good point. Indeed, I had used laziness in a programme that read a file that contained a series of entity definitions that could include forward references, I just couldn't remember exactly how I'd used laziness. (-: (It's also useful in some memoising, I think.) -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Neil Bartlett wrote: E.g. perhaps some kind of instant messaging server? Or Twitter except scalable. A twitter-alike will quite probably get people's attention. And of course anything that breaks the it's good for compilers! stereotype is to be commended :-) Also on the subject of scaling, Ralf Lammel's paper on looking at MapReduce through a strongly typed functional lens has been quite a hit. A tutorial along the lines of dealing safely with lots of data, in a cluster of systems, would likely go down well. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Mark T.B. Carroll wrote: Bryan O'Sullivan [EMAIL PROTECTED] writes: Mark T.B. Carroll wrote: I'm afraid no examples come easily to mind, though. Here's a simple one: reading a flattened graph from disk. If your flattened representation contains forward references, you have to fix them up in a strict language. In a lazy language, you can refer to elements you haven't yet read, eliminating that book-keeping. That's a good point. Indeed, I had used laziness in a programme that read a file that contained a series of entity definitions that could include forward references, I just couldn't remember exactly how I'd used laziness. (-: (It's also useful in some memoising, I think.) -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Near the bottom of http://www.haskell.org/hawiki/TyingTheKnot is an example that uses lazy evaluation to do exactly this. The real kicker though, is that the change from backward references only (i.e. simplistic one-pass code that would work in a strict language) to forward and backward references is trivial (just pass in the output). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
Neil Mitchell wrote: Things like laziness are cool, but are harder to convince a strict programmer that they are useful. Strict programmers like the yield command too. The same behaviour can be obtained by laziness, with easier reasoning. That said, strict programmers may or may not like easier reasoning. Also, laziness in general (when not restricted to generators) is not easier to reason either. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Tutorial on Haskell
Blast.. i didn't hit reply all so here's a forward of my mail to the group... --ryan -- Forwarded message -- From: Ryan Dickie [EMAIL PROTECTED] Date: Apr 16, 2007 4:24 PM Subject: Re: [Haskell-cafe] Tutorial on Haskell To: Simon Peyton-Jones [EMAIL PROTECTED] I can tell you what me and my colleagues would be interested in (though none of us are actually going). We code a lot of math. You may call it scientific computing. Haskell seems like a natural fit for the task. In particular we are interested in: 1) the type system 2) concurrency (can these be set to run on a large system) 3) simple relation between what equations we write on paper, and what equations we write in haskell. I'm still a n00b to Haskell. For us languages like matlab, maple, etc. do not fit the job very well and run too slowly. C/C++ is usually what i use but it can be a pain. Python, etc... well its good for the glue i suppose. Haskell might fit that niche. On 4/16/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10http://cgi.cse.unsw.edu.au/%7Edons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial on Haskell
G'day all. Quoting Neil Mitchell [EMAIL PROTECTED]: I think its important to cover whats different about Haskell. Things like laziness are cool, but are harder to convince a strict programmer that they are useful. I think you could. What you need to convince a strict programmer of is that laziness gives you modularity. The Graham Hutton Sudoku solver is a nice example, but it'd be cool if we had a similar example that was less cheesy than Sudoku. A dynamic programming or memoing example might not hurt, either. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
