On Fri, 26 Jan 2007 22:00:11 +0100, you wrote:

I agree, but I think it should be pointed out that primarily it is not Haskell which is hard, it is Programming which is. Haskell only reflects this better than the mainstream imperative languages.

That's very true. Writing good software is hard, regardless of the choice of language. Perhaps what sets Haskell apart is that, unlike most languages, it also makes writing _bad_ software hard. ;) Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/

On Wed, Jan 31, 2007 at 02:40:23 +0300, Bulat Ziganshin wrote:

Hello Benjamin,

Saturday, January 27, 2007, 12:00:11 AM, you wrote:

...

and support operational reasoning, i.e. creating and understanding programs by mentally modeling their execution on a machine. This form of reasoning appeals to 'common sense', it is familiar to almost all (even completely un-educated) people and is therefore easier acessible to them.

...

greatly simplifies denotional resp. equational reasoning(**), i.e. to understand a program as an abstract formula with certain logical properties; an abstract entity in its own right, independent of the possibility of execution on a machine. This way of thinking is less familiar to most people

i think you are completely wrong! FP way is to represent everything as function, imperative way is to represent everything as algorithm. there is no "natural thinking way", the only think that matters is *when* student learned the appropriate concept. let's look - in my college, the notion of algorithm was introduced at the 1st course *before* any other programming courses. we even studied Turing machine as an abstract algorithm executor

Nneither way may be "natural", but imperative thinking is extremely common in society, I'd say much more than "functional" thinking. Just think of cooking recipes, IKEA instructions, all the algorithms tought in math classes in grade school. I doubt that we'll ever see functional thinking tought alongside imperative thinking in lower grades in school. It could even be that the development of the human brain as we grow up reaches a state where it can handle imperative thinking before it can handle functional thinking (I bet there's a reason why astronauts have step-wise instructions rather than a set of "functions"). All I'm trying to say is that imperative thinking is so common outside of CS/math and we learn it so early on in life that we probably can consider it the "natural thinking way". /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus

On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote: . . .

foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]

Nice example. First, note that you can't get close with map -- you need accumulation across the dishes. Second, the correctness of this plan depends on the rather strong frame axiom that no entity in the environment is changed during a step of the fold, so no broken dishes. Finally, that doesn't work so well when there are constraints on the order that the dishes are washed, for example when washing the cruddiest dishes first while there are more suds. -- Bill Wood

On Jan 31, 2007, at 6:10 , Dougal Stanton wrote:

Quoth Bill Wood, nevermore,

...

...

foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]

Finally, that doesn't work so well when there are constraints on the order that the dishes are washed, for example when washing the cruddiest dishes first while there are more suds.

Alas, that still doesn't capture the notion of soapywater degenerating into murkywater.

Only because the definition of wash hasn't been provided; obviously, it returns a new value of water which is less soapy than the initializer soapywater. :) -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Kirsten Chevalier wrote:

...

On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote: . . .

...

foldl (\water dish -> wash water dish) soapywater dishes ::

[Dishes]

Nice example. First, note that you can't get close with map -- you need accumulation across the dishes. [...] It also assumes that there's necessarily a natural decomposition on

On 1/31/07, Bill Wood wrote: the dishes, and if you think there is, you haven't seen my kitchen!

Using a lazy fold may not be the best choice. Although it may sound enticing to delay washing until a clean dish is actually required (and having the dirty dishes removed by the garbage collector, hopefully before they start naturally decomposing), you will quickly run out of stack space. -k

On 1/31/07, Kirsten Chevalier wrote:

On 1/31/07, Bill Wood wrote:

...

On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote: . . .

...

foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes]

Nice example. First, note that you can't get close with map -- you need accumulation across the dishes. Second, the correctness of this plan depends on the rather strong frame axiom that no entity in the environment is changed during a step of the fold, so no broken dishes. Finally, that doesn't work so well when there are constraints on the order that the dishes are washed, for example when washing the cruddiest dishes first while there are more suds.

It also assumes that there's necessarily a natural decomposition on the dishes, and if you think there is, you haven't seen my kitchen!

In my kitchen, there is a natural decomposition on the dishes. Especially on the ones that have been at the bottom of the pile for the longest time. -Yitz

On Wed, 2007-01-31 at 08:45 +0000, Magnus Therning wrote: . . .

Nneither way may be "natural", but imperative thinking is extremely common in society, I'd say much more than "functional" thinking. Just think of cooking recipes, IKEA instructions, all the algorithms tought in math classes in grade school. I doubt that we'll ever see functional thinking tought alongside imperative thinking in lower grades in school.

It could even be that the development of the human brain as we grow up reaches a state where it can handle imperative thinking before it can handle functional thinking (I bet there's a reason why astronauts have step-wise instructions rather than a set of "functions").

All I'm trying to say is that imperative thinking is so common outside of CS/math and we learn it so early on in life that we probably can consider it the "natural thinking way".

I think you're quite right here. There's a reason that so much of Artificial Intelligence research dealt with Planning, Procedural Knowledge, and Temporal Reasoning. The so-called "Frame Problem" would not have been such a research topic if it weren't for the importance that many researchers placed on reasoning about state change. On the other hand work on declarative knowledge focused on taxonomic hierarchies and semantic nets, which dealt mostly with structural knowledge. A common view was that the two sorts of knowledge complemented each other, and corresponded in a natural way to intuitions (and some epistemological theory) about human reasoning. -- Bill Wood

Quoth Bulat Ziganshin, nevermore,

are you learned to write things in this way? in *my* school, we have studied

f=(a*b+d)*2

Also there's the issue of variable substitution. It gets taught very early on when algebra is introduced (at least in UK): f = x + 3y and y = sqrt(4 + n) => f = x + 3(sqrt(4 + n)) (I can't think of a real example at the moment, sorry!) Unless the calculation for y is extremely arduous you're always taught to just throw them all together. This really gets across the "equality by definition" thing that pure FP uses. There's no need to do things in any particular order. This is pretty close to how 'straight' function application works; I don't think we ever did anything like higher order functions in high-school algebra. Maybe that's the next step --- lambda calculus at age ten and up! :) Cheers, Dougal.

Bulat Ziganshin wrote:

...

FP way is to represent everything as function, imperative way is to represent everything as algorithm.

Magnus Therning wrote:

Neither way may be "natural", but imperative thinking is extremely common in society, I'd say much more than "functional" thinking. Just think of cooking recipes, IKEA instructions, all the algorithms taught in math classes in grade school.

Those are not imperative thinking - they are sequential thinking. There is nothing non-functional about describing an algorithm in sequential form. Imperative means requiring that the steps always be followed exactly. People do not follow the steps of a recipe exactly - they just use the recipe to understand what needs to be prepared. Same with your other examples. That's why I think that the oposite is true - declarative style is more natural. Just describe what you want to be computed. If that is best described as a sequence of steps, fine, if not, not. But in either case, you are not forcing a CPU to follow the steps blindly. -Yitz

Magnus Therning writes: (snip)

Sequential thinking would be related to procedural programming, that is ordering of statements are important but there's no state. Functional programming is declarative, no order and no state. So, to be strict I'd say that sequential form _is_ non-functional. At least if FOLDOC is correct and I read and understood things properly. (snip)

You've completely lost me here. Order is /very/ important in functional programming. Consider function composition: Prelude> ((+1) . (*2)) 5 11 Prelude> ((*2) . (+1)) 5 12 There we have sequencing, and the computation has intermediate state. There's nothing non-functional about the above. (snip)

The world has state! Just see what a "stink" that has created in the pure functional language camp! (snip)

Mmmm. Monads deal with that very nicely, I think, but there's a way to go yet. -- Mark

If you ask an "ordinary" programmer what is the effect of an assignment like: x := <expr> you will get an answer along the lines: the <expr> is evaluated and the result is stored in a box named "x". If you ask him/her whether something else has happened the answer will usually be "no"; and this is the wrong answer, since one tends to overlook the fact that one has, by mentioning the variable "x", also indicated that the old value of "x" is no longer needed. As such imperative programming is "functional programming with explicit garbage collection". This may have been a necessity in the old days, when memory was scarce and machines slow (in my first course on numeric algorithms we were taught to declare the variables x, y, z, n, m, i, and j, and the array a, and to solve our problems with those only; points would be deducted for making use of more variables, or not reusing whenever possible!). Nowadays I think everyone agrees that automatic garbage collection is a good thing; think about the amount of wasted programmer years of people figuring out where they have space leak, etc., and users of programs getting a disappointing feeling about computer science as a whole since apparently we keep delivering programs that stop to work at unpredictable moments. So, one might wonder whether assignments are always bad, bringing us back to the OO discussion. Of course if we have the following expression: digest.chew.eat.serve.cook.chop.pluck.kill $ chicken we all have a definite feeling that after applying the functions, the original object is no longer available, and the FP view does not feel entirely natural. Doaitse Swierstra

Reminds me of an HWN quote from a few weeks back. Jan 9, 2007 HWN "*Paul Johnson*: Mutable state is actually another form of manual memory management: every time you over-write a value you are making a decision that the old value is now garbage, regardless of what other part of the program might have been using it." On 1/31/07, Doaitse Swierstra wrote:

If you ask an "ordinary" programmer what is the effect of an assignment like:

x := <expr>

you will get an answer along the lines: the <expr> is evaluated and the result is stored in a box named "x".

If you ask him/her whether something else has happened the answer will usually be "no"; and this is the wrong answer, since one tends to overlook the fact that one has, by mentioning the variable "x", also indicated that the old value of "x" is no longer needed. As such imperative programming is "functional programming with explicit garbage collection".

This may have been a necessity in the old days, when memory was scarce and machines slow (in my first course on numeric algorithms we were taught to declare the variables x, y, z, n, m, i, and j, and the array a, and to solve our problems with those only; points would be deducted for making use of more variables, or not reusing whenever possible!). Nowadays I think everyone agrees that automatic garbage collection is a good thing; think about the amount of wasted programmer years of people figuring out where they have space leak, etc., and users of programs getting a disappointing feeling about computer science as a whole since apparently we keep delivering programs that stop to work at unpredictable moments.

So, one might wonder whether assignments are always bad, bringing us back to the OO discussion. Of course if we have the following expression:

digest.chew.eat.serve.cook.chop.pluck.kill $ chicken

we all have a definite feeling that after applying the functions, the original object is no longer available, and the FP view does not feel entirely natural.

Doaitse Swierstra

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

Magnus Therning writes:

Now, correct me if I'm wrong, but you see a "natural" ordering in your haskell expressions, right?

Right.

However the compiler/interpreter has to choose a sequence in order to arrive at a result, since that's how today's computers work. (Choosing well can be seen as optimisation :-)

Right. Ah, I may see my confusion then - I do see a natural ordering in my Haskell expressions, and indeed evaluation order could be different so long as the end result is the same, but I don't find that different to imperative languages - I would expect modern compilers to reorder statements if they can get better results out of it without affecting the answer. (E.g., if I specify a set of assignments where some reordering leaves the answers unchanged, but clusters uses of values better so that the dataflow is such that they can stay in registers, I'd expect the compiler to go ahead - so even where I do specify evaluation order in C or whatever, I don't particularly expect the compiler to respect that in cases where I won't notice that it didn't.) -- Mark

Imperative thinking is harder for humans than functional thinking. That is why astronauts need lists of instructions. When they use their natural intuition to solve problems, they are thinking functionally (and don't need a list to do it). Babies learn functional intuition immediately (pattern matching, lazy evaluation) to solve problems. Navigating around objects is hard for a robot but very basic for a baby. Following a prescribed path is basic for a robot but difficult for a child. Our brain is goal-oriented, not process-oriented. And BTW, a recipe book is a functional, not imperative, program. It is filled with recipes to be evaluated lazily. When it says, "make a white sauce, then chop onions and add to sauce", it means "you need a white sauce but I won't tell you how to make it. Look in the index if you need help (otherwise do it the way you already know how). And if you happen to have onions prechopped (or maybe onion flakes in the spice rack), don't ignore them and run to the store just because I told you to, just use what you have." The wording is imperative because schooling has distorted our natural functional/relational mode of thinking and devalued it. I for one think that turning the massively parallel, greedily optimizing, lazily evaluating, functional computer/relational database that is our brain into a von Neumann drone is a rather feeble accomplishment by any standard. Dan Weston Magnus Therning wrote:

Nneither way may be "natural", but imperative thinking is extremely common in society, I'd say much more than "functional" thinking. Just think of cooking recipes, IKEA instructions, all the algorithms tought in math classes in grade school. I doubt that we'll ever see functional thinking tought alongside imperative thinking in lower grades in school.

It could even be that the development of the human brain as we grow up reaches a state where it can handle imperative thinking before it can handle functional thinking (I bet there's a reason why astronauts have step-wise instructions rather than a set of "functions").

All I'm trying to say is that imperative thinking is so common outside of CS/math and we learn it so early on in life that we probably can consider it the "natural thinking way".

Quoth Magnus Therning, nevermore,

I'm not sure how a "functional" recipe would look, maybe something like this:

White_sauce is a combination of ... .

Chopped_onions is onions cut into small pieces.

White_sauce_with_chopped_onions is the combination of white_sauce and chopped_onions.

The functional approach

whitesauce = foldl stir base milks where base = flour + (heat butter)

compared with the imperative

whitesauce base = flour + heat(butter); while (milks > 0) stir(base, milk); milks--;

I'm going to go out on a limb here and suggest that, like Feynman's example of how people count in their heads, both of these explanations are accurate. If I were to explain the process to someone it would be in the imperative style: literally "giving commands", which is what a recipe is. But in my mind I imagine it as the gradual process of stirring milk into a base, which is far more adequately described in the functional style. The question is --- how would an expert describe such a process? Would a professional chef give instructions in the functional or imperative style? I think that is relevant, since the approach to the problem may change depending on proficiency. We may *learn* in the imperative style but *think* in the functional. Cheers, Dougal.

neil:

...

The question is --- how would an expert describe such a process? Would a professional chef give instructions in the functional or imperative style?

I think a sufficiently expert chef would not even need the functional style. Everything would be declarative.

Dave Thomas (of "Pragmatic Programmers" fame) tells of finding his late grandmother's recipe cards, which she accumulated over her entire life. He was able to track their evolution from an extremely pedantic, imperative style, through to the almost Zen-like cards that read:

"Spice cake: like chocolate cake. No chocolate, add spice".

Surely this is the arrow or monad transformer of recipe abstractions! Entirely new functionality, and such information density, on a single line. -- Don

[sorry, this was meant to go to the list] On Wednesday 31 January 2007 00:40, Bulat Ziganshin wrote:

Saturday, January 27, 2007, 12:00:11 AM, you wrote:

...

and support operational reasoning, i.e. creating and understanding programs by mentally modeling their execution on a machine. This form of reasoning appeals to 'common sense', it is familiar to almost all (even completely un-educated) people and is therefore easier acessible to them.

greatly simplifies denotional resp. equational reasoning(**), i.e. to understand a program as an abstract formula with certain logical properties; an abstract entity in its own right, independent of the possibility of execution on a machine. This way of thinking is less familiar to most people

i think you are completely wrong! FP way is to represent everything as function, imperative way is to represent everything as algorithm. there is no "natural thinking way", the only think that matters is *when* student learned the appropriate concept.

What I meant is that it is more similar to the way we use to think in our daily life. Noone thinks about day-to-day practical problems in a formal way -- in most cases this would be a completely inappropriate approach. Formal thinking comes naturally to only a gifted few of us, most find it exceptionally hard to learn. However, I didn't mean to say that formal reasoning is something that cannot be learned. I would even say that it is easier to learn if done right from the start as something completely new instead of appealing to intuition, thus trying to connect it to the more 'natural' ways of thinking -- because the latter have to be 'unlearned' to a certain extent before the new way of thinking can take hold.

all the problem of learning FP paradigm for college-finished programmers is just that their brains are filled with imperative paradigm and they can't imagine non-imperative programming. it was hard for me, too :)

we should change college programs to make FP programming available for the masses

Absolutely. Cheers Ben -- "Programming = Mathematics + Murphy's Law" (Dijkstra in EWD1008)

On 1/26/07, Collin Winter wrote:

You have a PhD in computer science from Princeton, so your measure of what's "hard" and what isn't in this regard is nearly worthless.

I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done.

I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps the people who think they need to taken graduate-level classes in category theory in order to use Haskell are barking up the wrong tree (or perhaps I'm not a very good Haskell implementor, which is always possible.)

Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard.

On the other hand, Meijer also has a PhD in computer science... is his judgment on Haskell's difficulty or lack thereof worthless, too? If not, then surely, judgments about whether Haskell is too hard can't have much to do with who has a PhD and who doesn't. Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope" -- Dom Leone

Hello Donald, Saturday, January 27, 2007, 10:18:44 AM, you wrote:

...

I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps

I haven't done any graduate level category theory either, and I hack Haskell 24/7! Let's form a union!!

yes! we hate category theory!!! :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Fri, 26 Jan 2007 22:01:09 -0600, you wrote:

You have a PhD in computer science from Princeton, so your measure of what's "hard" and what isn't in this regard is nearly worthless.

I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard.

I never said that people are lazy, only that they're not interested--they'd rather devote their time to other pursuits. That's not meant to be a criticism at all, it's an observation of The Way Things Work. And I certainly wasn't referring to the people who actually _complain_ about Haskell being too hard. After all, they're the ones who are in fact trying to learn, not the ones who simply don't care to. My comment was directed specifically at the notion that we can make Haskell more popular by somehow making it easier. _That's_ the argument that I believe is flawed, because the things that give value to Haskell are precisely the things that require effort to understand. To paraphrase Albert Einstein: make it as simple as possible, but no simpler. This is not just a progrmaming issue; I encounter the same phenomenon pretty much everywhere: I'm currently trying to build a house, and I've found that most of the people who are in the business of building houses don't want to try anything new, even if it might be a better way that has the potential to save them money and/or result in a better end product. They want to continue building houses the way they've always built houses. The fraction of house builders who do want to learn new and possibly better ways of building is, and always will be, a small one. Again, it's not a criticism, just an observation, something that one needs to be aware of when embarking on a house-building project. I'm reminded of when Java first appeared on the scene a little over ten years ago. There was a huge upswell in interest; all of the web developers out there were going to add Java applets to their web sites. Then the awful truth came out: Oops, you had to learn how to _program_ to create applets. Never mind; not worth it. And applets quickly and quietly faded away. By the way, to set the record straight, while I do have a Ph.D. from Princeton, it's in semiconductor physics, not computer science. And lest anyone were to misunderstand when I say Haskell is hard, while I do mean that it's hard for _me_, I think the evidence is pretty strong that I'm far from alone in my assessment. Whether or not it's hard for any particular person is up to that individual to judge, of course. I stick with Haskell because (a) I think it just might be worth it, and (b) I can't help myself--I have an insatiable craving for new knowledge. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/

On Sat, Jan 27, 2007 at 02:04:32PM -0500, Steve Schafer wrote:

This is not just a progrmaming issue; I encounter the same phenomenon pretty much everywhere: I'm currently trying to build a house, and I've found that most of the people who are in the business of building houses don't want to try anything new, even if it might be a better way that has the potential to save them money and/or result in a better end product. They want to continue building houses the way they've always built houses. The fraction of house builders who do want to learn new and possibly better ways of building is, and always will be, a small one.

This may change with the arrival of the first home building robots we've been reading about recently. They won't mind building in new ways, so the human builders will be forced to choose between becoming more flexible or changing their jobs. http://property.timesonline.co.uk/article/0,,14029-2546574,00.html Best regards Tomasz

On 1/26/07, Collin Winter wrote:

I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard.

I have an odd background in programming (never took a compsci class, did take a graduate computational physics course in my first year of undergrad, taught by an old nuclear physicist, who used nothing but Forth...beat that for bizarre), but since physicists represent an interesting conglomeration of snapshots of the mainstream of programming through the ages, I do have a bit of an archaeological perspective on how people think about "hard." In case the following seems far fetched, let me assure you that four years ago I worked in a high energy physics group on a codebase of a few hundred thousand lines of FORTRAN 77, with no documentation. It had GOTOs. The folks working on this regarded C as a newfangled, difficult language, and some of them were still writing FORTRAN IV or RATFOR. So here's my completely anecdotal view of the history of "hard" in programming: In the beginning there was GOTO. Well, actually there was machine language, then assembler, but we'll skip that. GOTO was king. And then there was this movement among the ivory tower computer scientists called "structured programming." It was considered difficult and complicated, with lots of hard concepts. And then the compsci departments made a concerted effort, taught a generation of students in the new style with no reference whatsoever to what came before. Structured programming suddenly became blasé. How else would you program? And then similar, though smaller and often partial repetitions of this break happened: designing nicer data structures when the Wirth languages came to their height; object oriented programming (which I regard as one of the great intellectual failures of programming). So when the kids are presented with exercises on functors, ADTs, and monads in intro compsci, and the professors pretend that it was always this way, there was never any other way, then they will grow up, they will go forth, and these will be the everyday things. Until then, I will continue to hear people say that map is a scary, unfamiliar object that makes the meaning of code obscure. -- Frederick Ross Graduate Fellow, (|Siggia> + |McKinney>)/sqrt(2) Lab The Rockefeller University

Haskell is _not_ inherently hard - any more than any other programming language. But it is different. So right now, Haskell is hard only because we need more documentation that is designed to make Haskell seem easy. Well, I think it's harder to get a program compiled in Haskell than in Java, for example. It's not too hard, although debugging might be a little difficult. I think this has to do with the type system. Althought it sounds bad, it's actually a good thing. Once you get a Haskell program compiled, chances are much higher that it's correct. You do a bit more work up front, but chances of a bug are way lower.

The way I see it, programming in Haskell is an investment. If you're from a OOP-background, some (trivial) things might take a lot more time. But in the end, it does make you more productive. You spend less time tracking bugs, and it's easier to refactor. Not everybody is willing to make an investment when they've got something that works. For example, if you know one imperative language, you can switch to another without taking too much risk. On the other hand, if you switch to a language that is completely different, you don't know if it will get your job done. It doesn't feel safe. -chris

On 29/01/07, Michael T. Richter wrote:

I started, given that I could actually have the free time now, looking at Haskell again about a year ago. (It's a major point in Haskell's favour that it always stuck around in my mind after first encountering and rejecting it, incidentally!) The documentation situation is better now, yes. Far better. But still not useful for people who are actively developing software in the C++/Java/C#/crap-"solution"-of-the-day daily grind. Now, at least, there actually *is* useful information. Finding it, however, takes up valuable time when you've got Yet Another Laughable Deadline ahead of you from your boss who is still unfamiliar with the Triangle of Quality (Fast <=> Cheap <=> Good : pick any two) and who has no patience for your strange ideas which you can't explain *because you yourself aren't sure of the ideas yet*. And I'm positive that this drives people off. I'm positive because it drove me off and I'm far more prone to experimentation with oddball technologies than most of the people I've ever worked with.

Agreed. I'm in the same boat. I can't realistically use Haskell at work until I can pull together the building blocks *fast*. That means, half an hour grabbing a reference and fiddling a bit to get a trivial database query working. Another half hour checking up on how I bolt together the boilerplate needed to add logging to a server. Etc. It *has* to be possible to do this - I can do it in Python, or Perl, or even Java. So if I can't do it in Haskell, then I'm back stuck with one of those languages. I may not like it, but it's a practical reality in my job. I can try to learn at home (and I do!) but I don't have the same sort of issues at home, or the resources to simulate them (100+ databases running over a WAN that I need to query simultaneously, in parallel, just to provide viable response times, for example :-)). So home problems end up being "toy" problems, and I'm only learning for the intellectual exercise (a good reason, but not helping with work). I'm very serious about the need for a "Haskell for the Working Programmer"

book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult.

Agreed. Something I can keep on my desk for reference, as well as browsing. ... and closing with a cookbook of Haskell solutions to real-world problems

(networking, database, general I/O, common algorithms, etc.) featuring Best Known Approaches (which remain, nonetheless approachable) to them.

Yes, a cookbook approach is an excellent resource. It doesn't have to cover everything, but it needs to focus on practical problems, and "just do this, and you're started" solutions. The other thing that is needed, IMHO - and this is visibly improving, but can still get better - is availability and ease of use of libraries. I'd like to be able to "just download" a Windows binary for libraries I need - logging, DB access, HTTP, client access to Windows COM objects, a GUI framework, sending emails, etc ... Again, it's the "I need it now" issue - I can spend time searching out or even developing such things, but when I don't even have the time to write the code I need for my job (hence wanting a high-level language like Haskell to speed up development :-)) what chance do I have if I have to spend time locating libraries as well? Python does well here with its "batteries included" approach, and the cheeseshop package index. Perl has CPAN, but quality and ease of installation issues have hit me there in the past. Haskell seems to be getting there, but it feels to me like there's a "critical mass" point it still has to get over. But there's clearly an interest in the community for this type of thing, so I suspect it's only a matter of time. I'll stop rambling now. Paul.

On Wed, 2007-31-01 at 03:25 +0300, Bulat Ziganshin wrote:

...

...

I'm very serious about the need for a "Haskell for the Working Programmer" book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult.

...

Agreed. Something I can keep on my desk for reference, as well as browsing.

how about developing a "contents" for this book and for cookbook? just a list of problems you want to learn how to solve. perhaps, then someone can fill some chapters. haskellwiki is a good place to start it

I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. What I've seen on the Wiki as regards idioms, standard practices, etc. -- and this is true of every language wiki I've ever seen -- is one proposed answer and then a chain of "but you could do it this way instead" with ever-increasingly-obscure ways of doing things. Which would be the precise opposite of what a "Haskell for the Working Programmer" book should be like. A book like this should be clear, straightforward and provide an introduction to Haskell for a working programmer, but an introduction that gets said programmer up and on the job quickly. After using the (possibly even less than ideal) solutions provided in the book, the reader can then comfortably hone the newfound skills provided. I do like the idea of developing a table of contents first and backfilling it, though. I would amend the process, however, to avoid the WikiBloat that seems to inevitably follow when documentation projects get too open. Instead of Wikifying it, I'd suggest instead that a "call for proposals" be put on the mailing list. "I'm working on a chapter dealing with database programming. I need to know how to do <insert whatever> in Haskell. Could anybody interested in helping please submit some commented, functioning code for possible inclusion?" Then the submissions could be made by email (and possibly even discussed on-list) and the editor/author of the book can take an executive decision and choose one if there are competing camps. -- Michael T. Richter Email: ttmrichter@gmail.com, mtr1966@hotpop.com MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn "I have never seen the poor people being so familiar with their heads of state as they were with [Michele Duvalier]. It was a beautiful lesson for me. I've learned something from it." --Mother Theresa

On 31/01/07, Joe Re wrote:

Instead of having someone work in solitude with occasional mailings back and forth on the list, I would rather have an open wiki for the collection of ideas from everyone. Then, if you really wanted, a single person can use those to create an 'editor edition' page that is only editable by them. Best of both worlds, or do you see it differently?

That's roughly how the O'Reilly "Python Cookbook" was done - open website for recipes, with the "best" taken and tidied up, filled out and published as a book by an editorial team. From my POV it worked well - the book is an excellent resource, and the website is still going strong as well. Paul.

On 31/01/07, Michael T. Richter wrote:

I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. What I've seen on the Wiki as regards idioms, standard practices, etc. -- and this is true of every language wiki I've ever seen -- is one proposed answer and then a chain of "but you could do it this way instead" with ever-increasingly-obscure ways of doing things. Which would be the precise *opposite* of what a "Haskell for the Working Programmer" book should be like.

I agree up to a point - there's a huge risk that increasingly "advanced" solutions will obscure the point. A reasonable amount of editorial control could keep this in check, though. A book like this should be clear, straightforward and provide an *

introduction* to Haskell for a working programmer, but an introduction that gets said programmer up and on the job quickly. After using the (possibly even less than ideal) solutions provided in the book, the reader can then comfortably hone the newfound skills provided.

I do like the idea of developing a table of contents first and backfilling it, though. I would amend the process, however, to avoid the WikiBloat that seems to inevitably follow when documentation projects get too open. Instead of Wikifying it, I'd suggest instead that a "call for proposals" be put on the mailing list. "I'm working on a chapter dealing with database programming. I need to know how to do <insert whatever> in Haskell. Could anybody interested in helping please submit some commented, functioning code for possible inclusion?" Then the submissions could be made by email (and possibly even discussed on-list) and the editor/author of the book can take an executive decision and choose one if there are competing camps.

Possibly. From my own point of view, though, I'm usually only after fairly simple snippets of code - certainly not enough for a book chapter (although they could be grouped into chapters by topic). Here's a slightly extended example: a key snippet for me would be "execute a query against a database and get the results". Naively, I see this as an IO action, much like reading a file. So I'd expect something like connect :: String -> String -> String -> IO dbHandle connect user password db = {- some magic to connect and give me a DB handle -} close :: dbHandle -> IO () close dbh = {- magic to close the handle -} query :: dbHandle -> String -> IO [String] query dbh sql = {- more magic to do the query and return results -} I'd use this as do dbh <- connect "system" "manager" "my_oracle_db" results <- query dbh "select * from all_users" close dbh return results (I'd see it as being in the IO monad, so that I can intersperse other IO actions. Maybe that's not necessary, but that's a different recipe - how do I intersperse actions in 2 different monads - that I'd class as quite advanced). It's not remotely functional, it's likely not to be "the best way" and it's probably making the advanced users squirm, but that's not the point. It fits my beginner's mental model - I'm new to Haskell, I've grasped the concept of IO and probably a little bit of how monads are great for structuring code (I'd probably write my own "auto-close" control structure for this - and soon after, find that it already exists!) but I'm not really worried. To me, Haskell is brilliant for slinging data around in clever ways. So this is just annoying boilerplate I need to get the data into my program - it doesn't even have to be efficient, because I'm only grabbing a few tens of rows here (getting data lazily would be a *separate* recipe, that I'd look at for the million-row query I'll try once I feel like getting more advanced). The point of this is that to me, pulling data out of databases is *boring*. The interesting bit is manipulating that data - and that's the bit that drew me to Haskell because other languages make the data manipulation tedious and boring as well. So I want easily tailorable snippets of code to get me past the boring stuff - I'm busy learning interesting things elsewhere in Haskell at the moment. Of course, in the above you could easily substitute any number of tasks for "querying a database". Grabbing web pages, displaying a GUI, etc. The point is the same - they aren't (yet) the interesting bit. Sorry, that went on a bit - I hope it was useful nevertheless. Paul.

On Fri, 2007-26-01 at 22:01 -0600, Collin Winter wrote:

I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done.

That would be a good way to think, yes. I look for practical solutions to real problems in my work. Haskell looks like it has these solutions, but extracting them from the noise level of ivory tower debates is a real problem. I think many of the users of Haskell forget that there are a lot of people out there who are not career academics working with pure mathematics day-in and day-out. My last math class? Was over fifteen years ago. And in, you know, the real world of programming you don't face mathematical problems as your bread and butter. You face problems in a messy world of too-short deadlines, too-few resources, too-poorly-communicated requirements and too-many-hours work. I would like to see a guide to Haskell that shows Haskell's place in those problems, not in Yet Another Elegant Mathematical Proof of the utterly useless in real life. Now given my privileged position of having escaped that ghetto of "toos" five years ago, I actually have the time and the energy to work this stuff out on my own. But your average working programmer? Just doesn't have the damned time to decode the arcane and obtuse wording and mathematics to get to what in the end turns out to be concepts verging on the trivial. (I'm looking at monads here....) Maybe I'm the one that has to write the book "Haskell for the Working Programmer" sometime. You know. When I understand the language enough to write it. -- Michael T. Richter Email: ttmrichter@gmail.com, mtr1966@hotpop.com MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn "I have never seen the poor people being so familiar with their heads of state as they were with [Michele Duvalier]. It was a beautiful lesson for me. I've learned something from it." --Mother Theresa

On 1/28/07, Chris Kuklewicz wrote:

...

I think many of the users of Haskell forget that there are a lot of people out there who are not career academics working with pure mathematics day-in and day-out.

GHC seems to be developed by several people at Microsoft Research. They are not career academics. I am less familiar with the other compilers.

There's no need for the "seems to be". The excellent "History of Haskell" paper: http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm discusses the history of every extant Haskell compiler, in section 9. If I'm reading correctly, every one of these compilers (except possibly for jhc, it's not clear) began as an academic research project at a university -- that includes GHC, which was developed by academics at the University of Glasgow (hence the "G" in "GHC"), and it was only later that some of them moved to MSR. Be careful about conflating "academic" with "not practical". It's true that academics haven't always had time to explain the useful, practical techniques they discover in ways that are understandable by programmers who don't have formal mathematical backgrounds (and be careful about conflating "having a PhD" with "having mathematical background or experience", too). In the same way that programmers have jobs to do and thus have limited time to puzzle out new languages, academics have jobs that don't tend to reward them for spending time making those puzzles clearer to practitioners. As a challenge to everyone posting on this thread: rather than excoriating academia for its sins, why not start creating the documentation (or tutorials or libraries or applications) you wish to see? Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "No one's actually said 'O great America, thank you for saving us from the evil communist bug-eyed aliens, and, can we have fries with that?' yet have they?" -- Debra Boyask

Chris Kuklewicz wrote:

Aside on utterly useful proofs: When you write concurrent programs you want an API with strong and useful guarantees so you can avoid deadlocks and starvation and conflicting data read/writes.  Designing an using such an API is a reasoning exercise identical to creating proofs.  Some systems makes this possible and even easy (such as using STM).

I have to -- partly -- disagree with your last statement. It is possible that I missed something important but as I see it, STM has by construction the disadvantage that absence of starvation is quite hard (if not impossible) to prove. A memory transaction must be re-started from the beginning if it finds (when trying to commit) another task has modified one of the TVars it depends on. This might mean that a long transaction may in fact /never/ commit if it gets interrupted often enough by short transactions which modify one of the TVars the longer transaction depends upon. IIRC this problem is mentioned in the original STM paper only in passing ("Starvation is surely a possibility" or some such comment). I would be very interested to hear if there has been any investigation of the consequences with regard to proving progress guarantees for programs that use STM. My current take on this is that there might be possibilities avoid this kind of starvation by appropriate scheduling. One idea is to assign time slices dynamically, e.g. to double it whenever a task must do a rollback instead of a commit (due to externally modified TVars), and to reset the time slice to the default on (successful) commit or exception. Another possibility is to introduce dynamic task priorities and to increase priority on each unsuccessful commit. (Unfortunately I have no proof that such measures would remove the danger of starvation, they merely seem plausible avenues for further research. I also don't know whether the current GHC runtime system already implements such heuristics.) Cheers Ben

On Sun, 2007-28-01 at 15:39 +0000, Chris Kuklewicz wrote:

Right. If it had been called the "Binding Chain Design Pattern" then no one would have gone nuts over the fact it had anything to do with advanced math.

But this design pattern was not trivial: it took years to standardize on using a Monad for IO in Haskell. This may have been a result of too small a community of users.

No design pattern worth using (under any paradigm!) was trivial to create. But you're right on the head with the naming. Calling it a "Monad" and referring to an "obscure branch of mathematics" every time you talk about it is just not the way to sell the pattern. My 2001-or-so rejection of Haskell had a lot to do with running into that "obscure branch" phrase far too often for my own mental health.

...

Maybe I'm the one that has to write the book "Haskell for the Working Programmer" sometime. You know. When I understand the language enough to write it.

You could start small by adding sections to the learning and tutorial pages at the wiki...

I could, yes. Except the stuff that I can document there is already documented. Actually much of what I think Haskell needs documented is already documented. It just needs to be put together into a coherent whole so prospective users aren't left sifting through a myriad of sources to find the few understandable (to them) gems. And having a cookbook of practical solutions wouldn't hurt either along the lines of the Ruby Cookbook or Python Cookbook or, hell, even the MySQL Cookbook. -- Michael T. Richter Email: ttmrichter@gmail.com, mtr1966@hotpop.com MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn "Sexual organs were created for reproduction between the male element and the female element -- and everything that deviates from that is not acceptable from a Buddhist point of view. Between a man and man, a woman and another woman, in the mouth, the anus, or even using a hand." --The Dalai Lama