2009/10/2 John A. De Goes :

On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote:

...

And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development.

A project manager's worst nightmare:

"Sorry boss, but we're just not going to be able to meet that deadline, because, well, a language extension we were using was dropped from the language, and the syntax for some core operators was changed. Not only is our code broken, but many of the libraries we were using are broken. Don't worry, though, we're 'agile', so our unit tests will tell us when our code is working again."

Big business demands stability.

Hi, Of course, the haskell community is that immature. People keep dropping extensions without a thought for potential problems. And the package versioning policy is just a joke written for next april fools day. Sorry for the spoiler. Cheers, Thu

On 2009-10-02 09:04 -0600 (Fri), John A. De Goes wrote:

I'm not saying Haskell is unstable. I'm saying that the attitude expressed in the following quote is at odds with the needs of business:

"And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development."

I don't know how much commercial experience you have, but I've been a founder of two companies, CTO or CEO of several businesses, a "chief architect" in a couple more, and consider myself as much a businessman and manager as a developer. The attitude you express is certainly common in many businesses, but it's not the only way to run a successful business. I won't go further here, since this kind of argument generally leads into a, "no, what you do isn't possible" kind of flamewar, but I did want to point this out here, so that others can know that, the attitude John De Goes expresses, while comon, is not the only way busineses look at the world. I should note, too, the the agile development momement over the past ten years has had and still does have exactly the same sort of attacks on it, and yet has successfully moved into the mainstream and is well-accepted by many parts of it. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On 2009-10-09 20:53 -0600 (Fri), John A. De Goes wrote:

The vast majority of applications being built today are web apps.

Right, and the vast majority of these are done in PHP, followed by Ruby and Python. For these languages, the majority of libraries are not native, but C libraries. So this makes me wonder, if cross-platform support is so necessary, why have these PHP, Ruby and Python folks not switched to Java, rather than remain suffering doing their development on Linux boxes? And if libraries are the issue, why would not just creating a SWIG for GHC make all of these people move to Haskell? On 2009-10-08 09:50 -0600 (Thu), John A. De Goes wrote:

I don't dismiss Haskell in business. I only maintain it's a niche market.

I agree it's a nich market, too. So I guess our point of disagreement is that you believe that it's lack of libraries keeping it a nich market, whereas I believe that even if it had libraries out the wazoo like Java (and of similar quality) it would still be a nich market. In other words, having a relatively small quantity of libraries is not a problem.

There are some domains where the infrastructure in more established languages is minimal, and in such cases, I think Haskell can be more efficient than those languages.

Indeed. I found many domains (including web ones) where I didn't use that infrastructure (such as it was) in Ruby, either. Where there are libraries and frameworks that are considered signficantly better, such as Rails over what's available in PHP, people switching are switching for incremental improvements in what they already do; these are not the kind of people who would ever switch to Haskell. (Rails is beloved basically because it's the bastard spawn of a PHP programmer and web designer; it's certainly not a framework that offers any big difference over doing the same thing in PHP in the traditional style it's always been done there.)

What has moved [from the agile development moment] into mainstream is unfortunately connected chiefly to agile by virtue of the word itself. Agile means more than getting software out the door quickly, a fact many businesses have yet to learn.

Right. But that practically defines the mainstream: adopting misinterpretations of truly radical changes so that they don't really have to change. If you want Haskell to *really* go mainstream, that's what you want. If you want libraries for Haskell that will help it go mainstream in that sense, you want bad ones that offer no significant improvement over the bad ones already out there for Java or whatever, and thus provide little productivity improvement. That just seems pointless to me, because those looking for real improvements can't use that sort of stuff. When I need RDBMS access, libraries like Hibernate and Active Record are useless to me, because they force me to work in a stupid manner. For web sites, Rails is useless because again, it deals with stuff in a stupid, unproductive way. This is why I say libraries aren't important. True, it is nice to have good ones that really help you be productive, but not only does Haskell not have them, neither Java nor Ruby do, either. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On 2009-10-11 10:58 -0600 (Sun), John A. De Goes wrote:

On Oct 9, 2009, at 10:37 PM, Curt Sampson wrote:

...

And if libraries are the issue, why would not just creating a SWIG for GHC make all of these people move to Haskell?

Making it possible and making it easy are two different things. It's already _possible_ to do Haskell interop with any other language, it's just difficult and cumbersome.

Have you written (non-SWIG) interop code for both Haskell and other languages? I've done, in the recent past, both Haskell and Ruby, and while Ruby is one of the easier ones out there, Haskell is even easier than that. As far as I know, when writing FFI code "by hand," there is *nothing* out there easier than Haskell. (I am happy to be convinced by a counterexample. However, I'd want to see how other FFIs support not only simple calls into functions written in other languages, but also how they deal with callbacks [passing function pointers to foreign-language libraries for them to call], memory allocated and deallocated by foreign libraries, and so on. If you want a small example that covers a lot of this, try writing enough of an interface into the Microsoft DDE library that you can write a simple DDE server and query it via the standard DDE client used for debugging. I can provide a Haskell library that does just this; it's less than 500 lines of code.)

...

I agree it's a nich market, too. So I guess our point of disagreement is that you believe that it's lack of libraries keeping it a nich market,

Haskell will never be "popular", because it's too hard for the masses. But I could see big companies like Yahoo, Facebook, Google, etc., using Haskell extensively to develop web infrastructure -- _if_ there were no longer a significant penalty to doing so. Right now the barrier of entry is too high, because too much infrastructure would have to be developed from scratch, and then maintained at cost.

Well, my experience (three years running a company that wrote a lot of web applications, and about 12 years total writing web applications under various circumstances) says otherwise. There are two different approaches to writing web applications. The "we think we're not smart enough to write a web framework" category of developers use Rails or whatever, and yes, the lack of libraries in Haskell is likely to hurt them. But then again, they're not likely to touch anything like Haskell anyway; they'd never use something that isn't already popular and doesn't cause them to have to change their mental model too much. The "we think web frameworks aren't hard to write" category may or may not use a framework, depending on how suitable it really is. For large sites that require a distributed system, generally you end up writing a lot of custom framework-type code. (I don't have experience with truly huge systems, but I think that a "small" one serving less than 10,000 requests per second and about 7-8 Gbps continuously during the peak hours is big enough that I have some understanding of what goes on there.) For these people, they do have a lot of libraries in C they can still use, and it's trivial for them to write the interfaces, and they're highly likely to write their own framework, or customize so heavily the one they're using that it might as well be a different framework anyway.

Well, I don't know much about Rails, but I do know some Rails developers can build a fully-functional, database-backed Web 2.0 site in a matter of hours.[2] That level of productivity is not available in Haskell yet.

Sure. And I can do that with my Ruby web framework, too. If I were doing web applications in Haskell, I'd write a framework there that would get me to the same point pretty quickly. But keep in mind, people who like Rails are very much not the kind of people who would ever consider Haskell for anything, no matter how good the libraries. Rails is successful because it's an incremental improvement on a rather poor way of writing web applications, and so it doesn't challenge all of those PHP programers who don't want to think too much.

Put another way, it would cost me far more to hire you to develop a Haskell site than a good Rails developer....

It depends on the site. For a simple site, yes, you can hire a cheap Rails developer, a cheap PHP developer, or a cheap almost-anything-else developer. If you're doing something with any technological difficulty, however, such as the next Twitter, Rails won't provide much of the help you really need. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On Oct 24, 2009, at 18:08 , Iain Barnett wrote:

On 24 Oct 2009, at 07:47, Curt Sampson wrote:

...

If you're doing something with any technological difficulty, however, such as the next Twitter, Rails won't provide much of the help you really need.

Twitter was (originally, at least) done using ROR. What is it that Haskell can do that Ruby can't when it comes to websites?

Twitter's also a steaming mess *now*. Would it be as bad if you could prove its correctness? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 25 Oct 2009, at 03:42, Curt Sampson wrote:

There's the key difference between us, I suppose. You believe that knowing the syntax and libraries of a language is the hardest part of a programming project. I believe it's a nearly trivial part.

I certainly didn't say that. Do you always misrepresent someone else's argument to help make a point? Perhaps if you took a minute to take in what I wrote before you wouldn't need to go with the straw man argument. It's easy. You stick to your own points instead of recasting other people's, try not to point out the obvious (it's got a compiler, ffs!) and give me an example that isn't from a time when Oasis actually made good records (I'll give you a clue, they only made one, and it was their first). One that involves Haskell would be good, handling Twitter-esque traffic would be even better. Since of course, the next Twitter could never be done in ROR even though the current one was. Think of it as dealing with facts instead of looking down your nose at all those mentally challenged PHP developers - the C++ and Perl guys have all that sneering covered for you, why bother? Perl6 is going to be better than everything anyway. On 25 Oct 2009, at 00:48, Brandon S. Allbery KF8NH wrote:

Twitter's also a steaming mess *now*. Would it be as bad if you could prove its correctness?

But they're using a compiler now ;) Joking aside, it seems to work better and more often for me than Facebook, and they're using Haskell as part of their development. They say it's because Haskell has "good parsing libraries", so maybe library choice does attract business. http://github.com/facebook/lex-pass/blob/master/README Iain

On 2009-10-25 04:58 +0000 (Sun), Iain Barnett wrote:

...

Ok, let me sum up the basic, serious points first, and then I'll get into the fun usenet-style tit-for-tat afterwards. No web application doing significant traffic is running on Rails as you'd roll it out by installing the appropriate packages on your Ubuntu server, and following the Rails tutorial. There's an enormous amount of other work that goes on there, usually involving things like vertical and horizontal database partitioning, read-only replicas, memcached, interesting caching schemes, and quite clever changes to the application to support clustering. Oh, and throw in entire systems that have no connection with Rails whatsoever, such as Twitter's self-developed Starling [no connection to my company] queue server, written in Ruby, which, now that they've learned what they're doing, they're replacing with a new server written in Scala. This is not unusual. Google's map-reduce is not something built from "good/many libraries and a large pool of developers." Nor was Rails itself (bad as it is), for that matter; it didn't even have the "stable code base" requirement. By your standards, Rails should never have been written in Ruby, it ought to have been written in Perl. Chew on that for a while before you dismiss Haskell as failing here, because it's failing in exactly the same way (well, not as badly, really) as Ruby was before Rails came along. Now for the tit-for-tat!

...and give me an example that isn't from a time when Oasis actually made good records (I'll give you a clue, they only made one, and it was their first).

Actually, I liked best their second album, though it's not my usual Creation fare. (It's probably obvious that Momus is more my style.) But the example of Twitter replacing Ruby with Scala happened around the time when Oasis was given the NME Award for Best British Band of the year. So perhaps your clue is wrong?

One that involves Haskell would be good, handling Twitter-esque traffic would be even better.

Sorry. My project (an automated options trading system) deals with only five million or so messages in a (6-hour) day. Admittedly it does some fairly complex processing on them, and runs pretty easily on a single i7 without much work (even when it's simulating the stock exchange as well), but what can I say? Guilty: I cannot personally come up with a Haskell application that is currently dealing with Twitter's traffic, even though I can see that such a thing would not be terribly hard to write (at least compared to doing it in Ruby).

Since of course, the next Twitter could never be done in ROR even though the current one was.

Err. Yeah. You mean the current one that fell apart and got replaced with Scala? The current one that used "ROR" despite the fact that the back-end wasn't a web application? The current one where you'd have to consider MySQL and some of the interesting clustering tools for it to be part of "Ruby" for it to be written in that?

Think of it as dealing with facts....

I'd like to think I do. After all, I'm not here because I'm an academic who loves Haskell and functional programming. (I rather disliked the idea when I'd first heard of it, actually.) I'm here because (though I don't do web sites any more, at least for the moment), after building web sites for more than a decade, in Bourne Shell, PHP, Perl, Java, Ruby, and a few other things besides, having built my own web framework in Ruby, having built sites in this framework that can deliver seven gigabits per second sustained, I think that Haskell, which I had never heard of four years ago and had never used in anger less than two years ago, can offer me more of what I was looking for when I moved to Java in '99 and Ruby around '04. Well, so there's your happy ending, or mine at least, anyway. I can now point out that all of the arguments against Haskell that I'm getting now are pretty much rehashes of the ones I got against Ruby in 2004. And I expect anybody in most organizations promoting Haskell now as hard as I did Ruby in 2004 is going to get fired in pretty much the same way. I just hope Haskell doesn't end up being known for and stuck with something as awful as Rails, five years from now. It would be like waking up to find out that everybody remembered The Smiths for Morrissey, not Marr... cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On 2009-10-25 14:48 +0000 (Sun), Iain Barnett wrote:

On 25 Oct 2009, at 08:31, Magnus Therning wrote:

...

Also, as I'm sure you've found out re libraries, more isn't necessarily better.

Definitely. Choice can become a real pain, especially in the face of lacking documentation.

Or if the choices are from a set of bad things. Being a guy who understands the point of RDBMSes, Hibernate is near the top of my hit list. But way back in my Java days (i.e., the days when I was converting people from Python to Java--I am ashamed of this[^1]) even I had my doubts about Struts, and and so I had our team's greatest promoter of Struts grab his favourite other developers and put together a Struts prototype of the system we were about to build, while I did a home-grown "framework." Struts came out at three times the amount of code, and was more confusing. Now, putting my manager hat on, if I'd decided I wasn't going to program any more and had a gang of six Struts-experienced people, I might well say that Struts would be the way to go anwyay. Chosing the Ford model of software production, making sure that every programmer is a replacable cog, and knowing you're going to have to hire a lot of them, is actually a reasonable business approach in many situations. But in others, such as the Viaweb one, you'll lose, as we've seen. Consider your original proposition:

That means that a language with a stable code base, good/many libraries, and a large pool of developers is a good choice.

Let's compare with what Paul Graham contemplates in "Beating the Averages" (http://www.paulgraham.com/avg.html): ] During the years we worked on Viaweb I read a lot of job descriptions. ] ... After a couple years of this I could tell which companies to ] worry about and which not to. The more of an IT flavor the job ] descriptions had, the less dangerous the company was. The safest kind ] were the ones that wanted Oracle experience. You never had to worry ] about those. You were also safe if they said they wanted C++ or Java ] developers. If they wanted Perl or Python programmers, that would be ] a bit frightening [keep in mind this is the late '90s --cjs]--that's ] starting to sound like a company where the technical side, at least, ] is run by real hackers. If I had ever seen a job posting looking for ] Lisp hackers, I would have been really worried. So where do you fall here, Iain?

...

I'd argue that many, if not most, commonly used libraries are excellent for "common" tasks, but as soon as you go into a niche many fall short of your requirements for scalability, speed, resource usage, etc. In the end you're likely to have to put considerable work into writing your own or modifying others'.

But if someone has already done some of the work, or an app or language is known to have been (at least) partially successful in an area, then this makes it a lot more likely to be picked, right?

Not really. If they've picked a bad interface, or written it badly, or worse yet, both, it's often a lot faster to just start again than to try and deal with fixing the crap you've been given. This is especially true if you don't need full library functionality, but just need a relatively small part of it. There have been plenty of occasions for me where it's been faster to write a small, incomplete "library" that works properly for what I need than to use something existing. (This is not at all Haskell-specific, by the way, it's just why I don't worry about libraries in Haskell any more than I do about not using Rails when I use Ruby.)

You could make the case, but are you saying that programmers of major languages like Java, Perl, Ruby, PHP, C#, C++... aren't self-motivated, don't enjoy their language, and aren't clever?

Well, I'll say that anybody who's using one of those (possibly excepting C#, much as I hate to say it, because there's some awfully good stuff creeping into that) is indeed behind the curve. But on that note, I think I'll give this up. If somebody wants to tell me that I'm going wrong because Clean is really what I should be using, or because I'm not doing enough proofs in Agda before I translate into Haskell, I'm willing to listen to that. And hell, you're probably right. I'm willing to admit I'm wrong about Haskell in the same way that I was wrong about Ruby, and wrong about Java before that, and wrong about C even before that, and wrong about...well, we won't go in to what I was programming in before that. Haskell, for me, is just the next step up on the road to learning about what it takes to get an idea into a computer, which turns out to be a lot harder than I thought it was twenty-five years ago. On 2009-10-25 14:59 +0000 (Sun), Iain Barnett wrote:

Then again, I really prefer the Fall over any Manc band.

Funny, I do too. Still, when Luxuria opened for them in Vancouver in the '90s, I started to think about what Howard Devoto was doing.... cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com [1]: Actually, this may be a key point. A lot of the stuff I advocate now, I advocate because I did it the other way several times in several ways. I do it differently know because of that experience. In other words, "I fucked up."

On 25 Oct 2009, at 08:31, Magnus Therning wrote:

Also, as I'm sure you've found out re libraries, more isn't necessarily better.

Definitely. Choice can become a real pain, especially in the face of lacking documentation.

I'd argue that many, if not most, commonly used libraries are excellent for "common" tasks, but as soon as you go into a niche many fall short of your requirements for scalability, speed, resource usage, etc. In the end you're likely to have to put considerable work into writing your own or modifying other's.

But if someone has already done some of the work, or an app or language is known to have been (at least) partially successful in an area, then this makes it a lot more likely to be picked, right?

I'm not sure it necessarily means that. There is a good case to be made for choosing a good, but obscure language, on the basis that the people who have bothered to learn it are likely to be self-motivated, enjoy the language, and quite likely be clever. Having a smaller pool of developers to choose from is not necessarily bad, as long as it is offset by a higher ratio of first-rate developers.

You could make the case, but are you saying that programmers of major languages like Java, Perl, Ruby, PHP, C#, C++... aren't self- motivated, don't enjoy their language, and aren't clever? Fact is, you'll get good and bad, self motivated and not, in every pool of developers, in every language - these aren't properties given to people by the language. If you're going to get a higher proportion of the "good" in a smaller language then that isn't necessarily offset by the risks to a project of having a smaller pool to pick from.

You get what you pay for, if you have extreme requirements in any area you'll have to pay well in order to get good developers who can handle the task.

In my experience good developers don't produce "fancy pants code", they'll produce code that is easier to understand and maintain. The fancy parts are limited to where it is required. Cheap, mediocre developers are more likely to produce fancy-pants-looking code, that is overly complicated, harder to understand and maintain, and often is buggy.

I totally agree, you (generally) get what you pay for. What I was referring to by fancy pants code, was the Creator God-like abilities being attributed to Haskell code over other languages. What you said holds true in any language, of course. Iain

...

...

...

...

"Magnus" == Magnus Therning writes:

Magnus> Again, in my own experience the amount of work to find a Magnus> good developer is about the same, and sometimes stacked in Magnus> favour of using an obscure language. I would be inclined to agree with you. Coming from the other end, as someone who has spent the last 7 years as an Eiffel developer (Haskell is only something I can do in my spare time), I believe that the company I work for has no problem finding good Eiffel developers (or just good developers who can be expected to learn Eiffel quickly). I think the risk is rather on the developer than the company. Suppose the company I work for were to go under in the near future (in the current economic climate, that can't be ruled out). Since they are probably the last company employing any significant number of Eiffel developers, I would probably find it very difficult indeed to find another job as an Eiffel developer, so I would have to look elsewhere, encumbered by a CV that did not show recent work in popular languages. Probably the risk for Haskell developers would be less, since Haskell popularity is rising, rather than falling. But it is certainly a consideration I would have thought (not that I ever thought about it seriously when accepting an Eiffel job - I'm an enthusiast - though now more for Haskell). -- Colin Adams Preston Lancashire

2009/10/25 Magnus Therning :

On 24/10/09 23:08, Iain Barnett wrote:

...

If you're in business, you're trying to keep your costs lower than your income. That means that a language with a stable code base, good/many libraries, and a large pool of developers is a good choice.

I'm not sure it necessarily means that. [...] Having a smaller pool of developers to choose from is not necessarily bad, as long as it is offset by a higher ratio of first-rate developers.

I think you also have to consider how committed you are to retaining developers. Plenty of people aren't; for them Java and PHP are feasible where Haskell (and RoR) aren't.

Also, as I'm sure you've found out re libraries, more isn't necessarily better.

Indeed -- if libraries were sufficient, CPAN would have been enough to keep Python and Ruby from ever growing into the force they now are. -- Jason Dusek

I'm absolutely missing your point. Here's an example. I'm a commercial developer. I need to create an SNMP agent. You show me Haskell, I point at Erlang. Erlang wins for time to market, and Haskell doesn't get to be part of the solution. We need libraries. On Wed, Oct 28, 2009 at 2:44 AM, Alberto G. Corona wrote:

IMHO, the software industry is no driven by workforce or by stocked stuff like libraries. It is driven by ideas. People with ideas tend to use the tools that materialize these ideas in their free time faster and better, with joy and beauty, It comes to my mind the first Jazz players that invented a new tradition, choose to play sax and trumpets because these instruments were easier to learn, small, very expressive, portable and brighting. Sometimes a long tradition of doing things in a certain way is an obstacle for innovation. If you think that Haskell can not compete with the tons of boring stuff for doing the same boring applications then you missed the point

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

On Fri, Oct 2, 2009 at 10:54 AM, John A. De Goes wrote:

On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote:

And as far as something like dealing with a changing language and

...

libraries, the mainstream already has well-established and popular techniques for doing just: agile development.

A project manager's worst nightmare:

"Sorry boss, but we're just not going to be able to meet that deadline, because, well, a language extension we were using was dropped from the language, and the syntax for some core operators was changed. Not only is our code broken, but many of the libraries we were using are broken. Don't worry, though, we're 'agile', so our unit tests will tell us when our code is working again."

While I agree that it probably isn't the right idea to say that we are Agile, so it is safe for us to build on a foundation that is constantly shifting underneath us, this same argument came up from Credit Suisse regarding the standardization of Haskell' at ICFP 06. At the time, as I recall, they were limiting themselves to Haskell 98 + Addenda. I argued that they should be interesting in having _more_ such standardization efforts to bring into the fold more features that they can rely upon. Even so, Haskell' includes only one breaking change (dropping n+k patterns) at this time and really how often do language features get dropped from GHC? (And at the time even the n+k change was laughed at by the audience as a joke proposal, not one that anyone was serious about -- how times have changed). There have been a couple of quirky changes in how big scary types involving scoped type variables change. Otherwise it has been far more stable and consistent over the last 11 year run than any non-toy compiler that *I* can think of. Heck, think how different your C compiler is now than it was in 1999. It feels, to me that there are more breaking changes in just upgrading to, say, C99 than there have been over the entire post-Haskell 98 life of GHC. -Edward Kmett Big business demands stability.

Regards,

John

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

Hi John, IMHO, with medium sized projects which are not application software to be installed on a greater number of unknown systems, the problem described by you is less aggravating: Hackage offers a fairly good track of version history and I for myself have adapted versions a good deal of times and found it - easy, to be honest. Speaking about small and especially medium sized projects, I think agile development fits well this scope. Please do not forget this. Nick John A. De Goes wrote:

On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote:

...

And as far as something like dealing with a changing language and libraries, the mainstream already has well-established and popular techniques for doing just: agile development.

A project manager's worst nightmare:

"Sorry boss, but we're just not going to be able to meet that deadline, because, well, a language extension we were using was dropped from the language, and the syntax for some core operators was changed. Not only is our code broken, but many of the libraries we were using are broken. Don't worry, though, we're 'agile', so our unit tests will tell us when our code is working again."

Big business demands stability.

Regards,

John

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