On 4/11/07, riccardo cagnasso wrote:

If you first language is LISP probably you find easy Haskell and difficult pearl.

I must say I agree here. I spent 10 years programming in prolog before I tried haskell. Most of my problems with haskell are because it has a rather opaque performance model (e.g. when should you use tail recursion, and when should you not). But I happily acknowledge that my experience is probably atypical. ;-) cheers, T. -- Dr Thomas Conway You are beautiful; but learn to work, drtomc@gmail.com for you cannot eat your beauty. -- Congo proverb

riccardo cagnasso wrote:

My opinion is that "learnin haskell is difficult" is just for the fact that when you learn programming, you probably begin with C / C++ or some other procedural/OO programming language...

Actually, my first language was Scheme; I loved it, and I aced the class, but that was many years ago, and I never had to code "real world" applications with Scheme. My problems with Haskell are not conceptual, but rather pragmatic. I have not been able to find enough support in Haskell for everyday tasks (e.g. read a stream from a socket; parse it into a simple data structure; process the data in the structure; print out the results to a socket; etc.), and unless I want to code large low-level libraries from scratch just to get conceptually simple tasks done, I can't afford to use Haskell (any more than I could afford to use barebones C, for that matter). And even though my interest in learning Haskell is not a "pragmatic" one (I'm quite productive with the tools I know; I just want to learn a new way to program, by way of intellectual curiosity), my life is such that, unless I can immediately make use of the language I'm attempting to learn, it just won't stick! The language needs it to be useful not because I need a tool, but because unless it is useful my brain just won't absorb it! kj -- View this message in context: http://www.nabble.com/Why-Perl-is-more-learnable-than-Haskell-tf3559193.html... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Hello kynn, Thursday, April 12, 2007, 7:10:56 AM, you wrote:

rather pragmatic. I have not been able to find enough support in Haskell for everyday tasks (e.g. read a stream from a socket; parse it into a simple data structure; process the data in the structure; print out the results to a socket;

look here: http://haskell.org/haskellwiki/Library/AltBinary -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Wed, Apr 11, 2007 at 02:21:41PM +0100, Will Newton wrote:

On 4/11/07, kynn wrote:

...

Perl is a large, ugly, messy language filled with quirks and eccentricities, while Haskell is an extremely elegant language whose design is guided by a few overriding ideas. (Or so I'm told.)

Based on this one would think that it would be much easier to learn Haskell than to learn Perl, but my experience is exactly the opposite.

I've been trying to learn Haskell for some time also, and I've learnt lots of various other languages in the past. I think one of the biggest problems is if there is a considerable learning curve, which Haskell undoubtedly has, there's a nagging question in the back of your head while you try and get a simple task accomplished in an unfamiliar language - "why am I bothering with this, I could do it in 5 minutes in Perl/Python/Ruby/...!".

And for many simple tasks Perl is a really good fit - it's best to find a task that plays to Haskell's strengths so you get a bit of positive reinforcement while you work. I have been working with Parsec to do some parsing recently and I can definitely recommend it. I don't think I've used such a capable and easy to use parsing framework in any language and it's really kept me going with Haskell where I might have "just done it in Python" in the past.

Writing interpreters is one task where Haskell is really nice. I suggest Unlambda, it makes a nice toy language. The syntax is easy to work with, and continuations make the semantics interesting enough that you can't just rely on the host language acting the same way, like you generally can with mutable state, sequential evaluation and so on (unless you're using something like scheme or ml, but then you probably wouldn't have trouble with Haskell). Brandon

The post on dons' blog about the cpu scaler is a great example on how haskell can easily used in the day-to-day hacking! 2007/4/11, brad clawsie :

i find that don's "haskell hacking blog" has been written with the daily hacker in mind:

http://cgi.cse.unsw.edu.au/~dons/bloghttp://cgi.cse.unsw.edu.au/%7Edons/blog _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. (Alan Kay)

Hi. I can't find that post. Could you point it to me please? Thanks! kj riccardo cagnasso wrote:

The post on dons' blog about the cpu scaler is a great example on how haskell can easily used in the day-to-day hacking!

2007/4/11, brad clawsie :

...

i find that don's "haskell hacking blog" has been written with the daily hacker in mind:

http://cgi.cse.unsw.edu.au/~dons/bloghttp://cgi.cse.unsw.edu.au/%7Edons/blog _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. (Alan Kay)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- View this message in context: http://www.nabble.com/Why-Perl-is-more-learnable-than-Haskell-tf3559193.html... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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=st&q=%22haskell+cafe%22+email+&rnum=3&hl=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 :

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

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 :

On 16/04/07, Thomas Hartman 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

On 4/16/07, Ketil Malde 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

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

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

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.

Mark T.B. Carroll wrote:

Bryan O'Sullivan 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).

G'day all. Quoting Neil Mitchell :

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

ajb@spamcop.net wrote:

OK, it's not pretty, but this is diff(1) in 120 lines:

http://andrew.bromage.org/darcs/diff/

(Btw, pairs (Int,Int) are members of the Ix class as well, so there is no need to generate an array of arrays. You can just pretend that one array is indexed by pair of Ints table = array ((0,0),(lxs-1,lys-1)) [((i,j), cell i j x y) | (i,x) <- zip [0..] xs, (j,y) <- zip [0..] ys] ) Regards, apfelmus

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

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: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] 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

Simon Peyton-Jones wrote:

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.

[...]

Remember, the goal is _not_ "explain monads". It's "Haskell is a great way to Get The Job Done".

While this it not a concrete suggestion for an example, I'd like to say why I can't help but program in Haskell: it gives me power. Programming in Haskell is like dual-wielding two light sabers whereas programming in imperative languages is like being equipped with a blunt kitchen knife. Sure, cleverly used, you can dissect problems with the knife but the light saber will disintegrate them instantly. If I were to give a tutorial, I would concentrate on showcasing such power. My current favorite example of power is the k-minima problem that has been discussed on this list: take k . quicksort Why is this program correct? Because it's almost the problem specification and because the type checker accepts it. But is it fast? Sure it is, because lazy evaluation does miracles (at least here ;). What else? The sugar on top is that this program is polymorphic. The above example is probably not considered "useful". To me, useful = asymptotically fast algorithm for a difficult problem, and I'm always astonished how incredibly easy it is to formulate or even derive a Haskell program that introduces the missing logarithm. But somehow, the word "performance" that people cry for doesn't seem to be related to that. At least, that's the impression I get when experiencing the sluggishness of certain programs. Anyway, maybe a showcase of power would be if the talk talks about how to create talks in Haskell, especially the talk being held. I mean that the showcased example could be to build a small type-setting/graphics/PS or PDF system in Haskell from scratch that is capable of producing the slides for the talk itself. This would include * a simple dynamic programming type-setting algorithm (performance) * a simple, preferably external (XMl, Parsec, ...) language for describing slides with some macro capabilities (like variables and substitution, perhaps even recursion or loops, slide numbers!) (expressiveness) * a small vector graphics library (for text and a few visual gimmicks) that can output to PDF (or PostScript for simplicity). (polymorphism: one API, different backends). The point is of course: "With Haskell, I'm not only able to create my slides from scratch, but I can even completely explain the code to you in only 3 hours!". Regards, apfelmus

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

pete-expires-20070615:

Simon Peyton-Jones writes:

...

My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics.

...

Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language

...

But there must be lots of others.

As one of those python/ruby types trying to learn Haskell for the past year, here are my suggestions for small examples:

- Tom Moertel's Haskell Port Scanner Why? Demonstrates concurrent haskell in a small amount of lines http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haske...

- A web-server example of some sort that interfaces with a database and uses some interesting HTML combinator library.

- Building a simple unit testing framework is always a good example (even though they already exist), and then introducing quickcheck perhaps.

It's interesting to note that QuickCheck generalises unit testing: zero-arity QC properties are exactly unit tests.

- A program to concurrently verify the links on an HTML page recursively. I'm sure there are lots of interesting idioms and techniques that could be used while keeping the code small and elegant.

Ah, there's a (parallel) program I wrote for this, urlcheck. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/urlcheck-0.1 I had meant to use this as a basis for a blog article, but didn't get around to it.

- Perhaps a Haskell version of Norvig's 20-line Python Spell Checker: Why? Maybe a Haskell version could be shorter and more elegant? http://norvig.com/spell-correct.html

- Tom Moertel's Directory Tree Printing in Haskell: Why? Demonstrates all sorts of introductory techniques http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haske...

Some thoughts on other topics suggested by others:

- Parsec is not that interesting for those coming from perl, ruby, or python as they rely on regular expressions for everything and just expect that they are part of the language. The thought of writing one's own parser is not as "cool" as most Haskellers believe it is, regardless of how interesting the parsec library is.

That's a useful insight.

- STM may be too complex of a subject for an intro to Haskell tutorial. There are just too many concepts in there that may overwhelm some beginners.

- Don's post on shell scripting was very interesting, but I'm still having a hard time understanding some parts of it, the error handling part, and I've been playing with Haskell on and off for the past year (I'm also a slow learner and not an academic).

Interesting! Thanks for the feedback.

- Don's post on simple UNIX utilities was also quite nice. I believe he also wrote a simple IRC bot example that would prove interesting, can't seem to find the link at the moment though.

http://haskell.org/haskellwiki/Roll_your_own_IRC_bot

Just my thoughts as a newbie desiring a book on how to use Haskell in a practical manner (such as Practical Common Lisp book).

Don't we all! :-) -- Don

joelr1:

On Apr 16, 2007, at 9:29 PM, Donald Bruce Stewart wrote:

...

It's interesting to note that QuickCheck generalises unit testing: zero-arity QC properties are exactly unit tests.

I don't think this works very well. I rely quite heavily on being able to compare expected output with test results and QC does not seem to provide for this feature when tests are zero arity.

Am I missing something?

That's just the default driver. Plenty of custom drivers exist which compare the output. The QC driver is just a function you implement, after all. -- Don

I usually roll a new driver for each project, for example: http://www.cse.unsw.edu.au/~dons/code/fps/tests/QuickCheckUtils.hs and a smp parallel driver, http://www.cse.unsw.edu.au/~dons/code/pqc/Test/QuickCheck/Parallel.hs There's a few examples in Test.QuickCheck too. joelr1:

Are there any examples of such custom drivers?

On Apr 16, 2007, at 10:09 PM, Donald Bruce Stewart wrote:

...

That's just the default driver. Plenty of custom drivers exist which compare the output. The QC driver is just a function you implement, after all.

-- http://wagerlabs.com/

That's what HUnit does but it's enticing to be able to standardize on QuickCheck for all of your testing. On Apr 16, 2007, at 10:11 PM, Lennart Augustsson wrote:

Why can't you just do 'f 1 2 3 == (4, 5, 6, 7)' to test f?

-- http://wagerlabs.com/

On Apr 17, 2007, at 9:31 AM, Ketil Malde wrote:

Prelude Test.QuickCheck> let prop0 = List.sort [3,2,1] == [1,2,3] in quickCheck prop0 OK, passed 100 tests.

My point is to be able to see that result generated was X and that it did not match expected Y, where both X and Y are printed out. -- http://wagerlabs.com/

"Evan Laforge" writes:

It illustrates a few nice things about haskell: laziness for the recursive defs and easy backtracking, low syntax overhead and custom operators for DSLs, composability, etc.

Although that is true, I somehow feel that showing a perl, ruby, or python programmer an alternate approach to regexps, a technique firmly ingrained into the roots of these languages, will not garner much interest in Haskell. I know this is the case for me. In fact, it was always a large negative for me that Haskell/GHC never had decent builtin support for regexps until recently (6.6). From a practical point of view, the tasks that I do frequently involve the use of regexps (for better or worse). Again, I'm not an academic, just an everyday python programmer trying to assist me in my day job. Upon thinking about this subject further, I think it would be very important that Simon somehow incorporates at least one use of the new regexp library. The target audience would by more likely to consider Haskell if it contains they're beloved tool of choice. Later, they can discover the elegance of parsec if needed. -Pete

On Tuesday 17 April 2007 14:48, Alexis Hazell wrote:

Likewise. It's true that when regexps are readily available, everything can look like a hammer; but sometimes a nail is just a nail. :-)

Er. i meant to say, when the regexp /hammer/ is readily available, everything can look like a /nail/. %-} A.

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

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

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

On 18/04/07, R Hayes 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.

Dougal Stanton wrote:

On 18/04/07, R Hayes 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).

On 4/18/07, Taillefer, Troy (EXP) 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

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

Tim Newsham wrote:

- What about program proofs? Are there any systems that tie directly into haskell and let you augment your haskell program with a proof that can be machine checked?

Programatica. http://www.csee.ogi.edu/PacSoft/projects/programatica/ You can write properties in the PLogic specification language (in comments within your program), and have them translated to the Alfa/Agda theorem prover. (However, I haven't seen much development activity on the Programatica project for a couple of years now.) Regards, Malcolm