That's not really true. Just use CAL from the Open Quark framework... It's almost Haskell 98, with some extras, and compiles to fast JVM code. http://openquark.org/Open_Quark/Welcome.html http://openquark.org/Open_Quark/Welcome.htmlThey even seem to do all kinds of advanced optimizations - like converting tail calls to loops - to get good Java performance. And they have a better record system, a graphical environment to learn it, etc. So I think CAL should be in the list, and since it's basically Haskell... On Sun, Sep 27, 2009 at 6:36 PM, John A. De Goes wrote:

I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM.

It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as "next Java's", because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses.

Regards,

John A. De Goes N-Brain, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote:

No, it's not quite what it sounds like. :-)

...

Stuart Halloway recently posted a series of blog entries entitled "Java.next"[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting.

I'll probably be posting these about one per week, starting some time next week.

[1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary...

cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

CAL is interesting, but unfortunately dead, and has no community. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Sep 27, 2009, at 3:38 PM, Peter Verswyvelen wrote:

That's not really true. Just use CAL from the Open Quark framework... It's almost Haskell 98, with some extras, and compiles to fast JVM code.

http://openquark.org/Open_Quark/Welcome.html

They even seem to do all kinds of advanced optimizations - like converting tail calls to loops - to get good Java performance.

And they have a better record system, a graphical environment to learn it, etc.

So I think CAL should be in the list, and since it's basically Haskell...

On Sun, Sep 27, 2009 at 6:36 PM, John A. De Goes wrote:

I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM.

It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as "next Java's", because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses.

Regards,

John A. De Goes N-Brain, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote:

No, it's not quite what it sounds like. :-)

Stuart Halloway recently posted a series of blog entries entitled "Java.next"[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting.

I'll probably be posting these about one per week, starting some time next week.

[1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary...

cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

I think they made a mistake choosing a syntax so close to Haskell: 1. It's close enough to Haskell to attract Haskellers; 2. It's far enough away from Haskell to push Haskellers away; 3. It's not the language one would design if one were prioritizing easy interop with Java in a modern lazy, functional language. If CAL were 100% Haskell 98 + extensions, it would be a success (Haskell + all Java libraries, trivial cross-platform library development, Haskell on Android & AppEngine, etc.). If it were nothing like Haskell, but had the features of Haskell plus strong, seamless, and easy Java interop, then it would be a success. Having neither, I'm not surprised it has no community and development has ceased. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Sep 28, 2009, at 9:59 AM, Peter Verswyvelen wrote:

That's a really shame. Any idea why?

On Mon, Sep 28, 2009 at 3:02 PM, John A. De Goes wrote:

CAL is interesting, but unfortunately dead, and has no community.

Regards,

John A. De Goes N-Brain, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Sep 27, 2009, at 3:38 PM, Peter Verswyvelen wrote:

...

That's not really true. Just use CAL from the Open Quark framework... It's almost Haskell 98, with some extras, and compiles to fast JVM code.

http://openquark.org/Open_Quark/Welcome.html

They even seem to do all kinds of advanced optimizations - like converting tail calls to loops - to get good Java performance.

And they have a better record system, a graphical environment to learn it, etc.

So I think CAL should be in the list, and since it's basically Haskell...

On Sun, Sep 27, 2009 at 6:36 PM, John A. De Goes wrote:

I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM.

It makes sense to discuss Clojure, Groovy, JRuby, Scala, Fan, etc., as "next Java's", because they all run on the JVM and have seamless interop with Java. Haskell is not in this category. It's stuck in a different world, wholly inaccessible to the masses.

Regards,

John A. De Goes N-Brain, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote:

No, it's not quite what it sounds like. :-)

Stuart Halloway recently posted a series of blog entries entitled "Java.next"[1], discussing the benefits of four other languages that compile to JVM bytecode and interoperate with Java: Clojure, Groovy, JRuby, and Scala. I thought I'd put my oar in and write a parallel series comparing Haskell to these. I've finished a draft of the first posting, started on the third, and made a couple of notes on the second and fourth, and I thought I'd post the drafts[2] and solicit comments here. If you have time to read and comment, I'd greatly appreciate the help; feel free either to e-mail me privately or post here. Also feel free to forward this to anybody else you feel might be interested in commenting.

I'll probably be posting these about one per week, starting some time next week.

[1]: http://blog.thinkrelevance.com/2008/9/24/java-next-overview [2]: http://www.starling-software.com/en/blog/drafts/2009/09/27.succ-java-summary...

cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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

I think a language needs the following to exist: - a community - good library - a package manager Thoughts? -- Regards, Casey

On Tue, 29 Sep 2009 12:25:30 +1000, you wrote:

I think one must distinguish what it means for a language to "exist" and "be practical." Counter-example: Java fails catastrophically at all three and it most certainly exists; boy do I know it.

QOTM!

Casey Hawthorne wrote:

...

I think a language needs the following to exist:

- a community

- good library

- a package manager

Thoughts? --

-- Regards, Casey

On Mon, 28 Sep 2009 21:50:14 -0500, you wrote:

Good libraries are not enough for a language to go beyond mere existence. There must exist good documents, i.e., good tutorials, good books, and good explanations and examples in the libraries, etc, that are easy for people to learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better.

Good thought! Is there a good way to add Haskell examples to the libraries? -- Regards, Casey

A Cook Book is good but relies on people specifically working on it. I think most of the package authors submit their packages because they themselves need the modules in his real world. I think package authors adding examples in the Descriptions section is a good start when they submit their packages. You do want to facilitate people understanding and using your modules, right? Maybe later on we can add an Example section to Description, Synopsis, and Documentation sections produced by Haddock. Also, having a section for comments is helpful. This is the case especially when there are several similar packages coexisting, comments can help people choose which one to use. Thanks, Hong On Mon, Sep 28, 2009 at 9:55 PM, Casey Hawthorne wrote:

On Mon, 28 Sep 2009 21:50:14 -0500, you wrote:

...

Good libraries are not enough for a language to go beyond mere existence. There must exist good documents, i.e., good tutorials, good books, and good explanations and examples in the libraries, etc, that are easy for people to learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better.

Good thought!

Is there a good way to add Haskell examples to the libraries?

A Haskell CookBook might be just the ticket, also.

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

brad.larsen:

On Mon, Sep 28, 2009 at 11:11 PM, Hong Yang wrote: [...]

...

Maybe later on we can add an Example section to Description, Synopsis, and Documentation sections produced by Haddock.

Also, having a section for comments is helpful. This is the case especially when there are several similar packages coexisting, comments can help people choose which one to use.

Thanks,

Hong [...]

+1

I'd like to see people writing comparative reviews of libraries in each category, and publishing those reviews online. -- Don

If there's an Example section, it might actually be a good idea to include it on the package's hackage page, too. From a usability point of view, CPAN is much more helpful than the relatively spartan hackage description - if you're looking for a particular set of functionality, being able to filter out misses quickly is really nice. mark On 29/09/2009, at 1:11 PM, Hong Yang wrote:

A Cook Book is good but relies on people specifically working on it. I think most of the package authors submit their packages because they themselves need the modules in his real world.

I think package authors adding examples in the Descriptions section is a good start when they submit their packages. You do want to facilitate people understanding and using your modules, right?

Maybe later on we can add an Example section to Description, Synopsis, and Documentation sections produced by Haddock.

Also, having a section for comments is helpful. This is the case especially when there are several similar packages coexisting, comments can help people choose which one to use.

Thanks,

Hong

On Mon, Sep 28, 2009 at 9:55 PM, Casey Hawthorne wrote: On Mon, 28 Sep 2009 21:50:14 -0500, you wrote:

...

Good libraries are not enough for a language to go beyond mere existence. There must exist good documents, i.e., good tutorials, good books, and good explanations and examples in the libraries, etc, that are easy for people to learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better.

Good thought!

Is there a good way to add Haskell examples to the libraries?

A Haskell CookBook might be just the ticket, also.

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

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

Tom Tobin wrote:

This. As an experienced Pythonista but a beginning Haskeller, there is *no way* I would have been able to wrap my head around the basics of Haskell without the tutorage of Learn You A Haskell, Real World Haskell, and various smaller tutorials scattered around the Haskell wiki — but I still find the array of libraries confusing (just what comes with GHC — I'm not even talking about Hackage here), since the documentation seems to be quite terse compared to Python's docs. I'm getting better at reading the code directly, but I'm often at a loss for what a particular library is good for in the first place. The library documentation seems to assume a mathematical or (advanced) computer science background, and has no problem sending a reader off to see a journal paper for details — not exactly friendly to those who are trying their hardest to unlearn their imperative ways as it is. ;-

While some of the stuff that comes with GHC is quite well documented, others are highly under-documented. (As an exercise, go count how many module descriptions say "inspired by the paper by XXX at this URL"...) Admittedly, the System.IO module probably isn't the place to explain what a monad is and write a full tutorial on using them. However, look at (say) Control.Concurrent.STM.TVar. In my copy (GHC 6.10.3) it lacks even type signatures, let alone actual descriptions. Similarly, Parsec has some lovely external documentation (unfortunately as a single giant HTML page), but the Haddock stuff is bare. Now, the operative question (and I'm sure we've debated this one before) is: how do we fix all this?

On Tue, Sep 29, 2009 at 3:36 PM, Andrew Coppin wrote:

Tom Tobin wrote:

...

This.  As an experienced Pythonista but a beginning Haskeller, there is *no way* I would have been able to wrap my head around the basics of Haskell without the tutorage of Learn You A Haskell, Real World Haskell, and various smaller tutorials scattered around the Haskell wiki — but I still find the array of libraries confusing (just what comes with GHC — I'm not even talking about Hackage here), since the documentation seems to be quite terse compared to Python's docs.  I'm getting better at reading the code directly, but I'm often at a loss for what a particular library is good for in the first place.  The library documentation seems to assume a mathematical or (advanced) computer science background, and has no problem sending a reader off to see a journal paper for details — not exactly friendly to those who are trying their hardest to unlearn their imperative ways as it is. ;-

While some of the stuff that comes with GHC is quite well documented, others are highly under-documented. (As an exercise, go count how many module descriptions say "inspired by the paper by XXX at this URL"...)

Admittedly, the System.IO module probably isn't the place to explain what a monad is and write a full tutorial on using them. However, look at (say) Control.Concurrent.STM.TVar. In my copy (GHC 6.10.3) it lacks even type signatures, let alone actual descriptions. Similarly, Parsec has some lovely external documentation (unfortunately as a single giant HTML page), but the Haddock stuff is bare.

Now, the operative question (and I'm sure we've debated this one before) is: how do we fix all this?

As a Wikipedian, my knee-jerk answer is: lower entrance costs! Specifically, in the past I've tried to think of uses for Gitit beyond just the normal wiki stuff. One thing I came up with: - run a Gitit wiki on top of a copy of the base libraries' repos. The actual Haskell files will be displayed as highlighted articles; eg. here's a .lisp file displayed nicely: http://gitit.net/sudoku.lisp People will be able to log in and edit the docs as they please. Every week or so, the edits could be batched up by some sort of hook and emailed to the libraries@haskell.org ML; good edits get applied to the master repo, bad edits get ignored. Another hook periodically deletes patches that don't make it to the master repo. Thanks to the darcs backend and per-article editing, we can have the 'wiki' repo (with all the Front Pages and .conf files one wants for a nice wiki) follow the 'master' repo without running into conflicts. This is nice enough an idea, but we can go further. Even better would be haddocks rebuilt on every edit, so users can edit and see the results immediately*. (You can sort of approximate this locally by working on files in an editor, keeping a cabal-install looping, and refreshing in your browser.) I can't guarantee that this would get people to contribute tips, work-arounds, and examples to the docs, but it seems much more likely to encourage contributions than our current quite arcane system of hidden repos and obscure darcs sends to even more obscure mailing lists. (Wait, you want me to implement this idea instead of just throwing out suggestions? Maybe next week...) * It's not clear to me how to make the built haddocks immediately accessible to an editor of the .hs page. After all, half the point of using Gitit is that it can work with the original repo almost as-is. I have a crazy idea that the Haddock .html can be built and then moved to Talk:sudoku.lisp, but I've no idea whether this would work. I'm not sure Talk: pages of non-article files are even possible. -- gwern

On Tue, Sep 29, 2009 at 9:36 PM, Andrew Coppin wrote:

Similarly, Parsec has some lovely external documentation (unfortunately as a single giant HTML page), but the Haddock stuff is bare.

The last version (3.x) improves things.

On Tue, Sep 29, 2009 at 3:16 PM, Don Stewart wrote:

korpios:

...

wiki — but I still find the array of libraries confusing (just what comes with GHC — I'm not even talking about Hackage here), since the

What comes with GHC is the Haskell Platform these days. Actually, the other way around. GHC comes with the Haskell Platform.

   http://haskell.org/platform/

The contents of which are specified here:

   http://haskell.org/platform/contents.html

I'm talking about poking around here randomly: http://www.haskell.org/ghc/docs/latest/html/libraries/index.html ... and trying to figure out what a given library does — not for the sake of selecting it among other options (the Platform idea), but just as part of getting a grip on Haskell's "standard library", as it were. Put another way, I'm doing the opposite of the Platform — instead of saying "I have requirement X, what library would be the best match?", I'm asking "Hmm, hello library Y, what could I use you for?"

On 2009-09-29 13:28 -0700 (Tue), Don Stewart wrote:

I'd welcome input on how to best present all this -- the Haskell Platform gives us a chance to package up the docs in a better format for consumption.

Part of the issue is that the Haskell libraries are so different in many ways that there's a (relatively) large amount of background required to be able to understand how things normally fit together. One of the best resources I've seen for this is Brent Yorgey's article "The Typeclassopedia." How we get from particular bits of design in random libraries back to an understanding of why they were designed that way that would be informed by something like the above, I'm not sure. Including a design document with libraries that explains how and why they were designed that way might be a big help. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On Wed, Sep 30, 2009 at 6:45 PM, namekuseijin wrote:

On Mon, Sep 28, 2009 at 11:50 PM, Hong Yang wrote:

...

learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better.

The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already:

import Data.Array.Diff import Data.IArray

update :: (Char -> [Int]) -> DiffArray Int ModP -> Char -> DiffArray Int ModP update lookup arr c = arr // (map calc . lookup $ c) where calc i = (i, (arr ! i) + (arr ! (i-1)))

solve line sol = (foldl' (update lookup) iArray line) ! snd (bounds iArray) where iArray = listArray (0, length sol) $ 1 : map (const 0) sol lookup c = map (+1) . findIndices (== c) $ sol

I've not been following Haskell too much and am completely lost when reading code like that. I understand (+1), : and ! but what the hell are . and $ for? And that weird monad symbol in the Haskell logo is not even used! >>= Not quite the worst example of such line noise much of Haskell idiomatic code uses nowadays, though.

Point is: >>= . $ : ! `` and meaningful whitespace are all nice shortcuts, but also hairy confusing...

I overall agree with the sentiment (I avoid declaring operators at all costs), but the example is a bad one. $, ., and >>= are all very basic to Haskell, and should be picked up almost immediately. As far as becoming line noise like Perl, well, I happen to like Perl :). Michael

On 2009-09-30 13:45 -0300 (Wed), namekuseijin wrote:

The Perl call is spot on. Specially because Haskell has been incorporating so much syntatic sugar that it's almost looking Perlish noise already: [examples deleted]

No, I disagree with your particular examples; they're bog-standard Haskell that don't use any syntatic sugar (. and $ are just library functions), and I find them perfectly fine to read. Note that nothing in there is inconsistent or interpreted in any sort of exceptional way, unlike many things that look like that in Perl. It does take time to learn to read that sort of stuff, but once you've got it, "simplifying" this sort of thing would only make it harder to read, because it would be more verbose without saying anything more. Haskell's concision is one of its most important strengths. (Incidently, a good exercise for learning to understand stuff like that might be to go thorugh it and convert it to use parens instead of $, full application instead of ., and so on.) cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

On 2009-10-01 11:42 +1000 (Thu), Tony Morris wrote:

There is a significant difference between:

* A $ function without a type system * A statically checked $ function * A $ keyword without static checking

Sure, but I'm not not clear on the point you're trying to make, since we all know which one of these that Haskell uses. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

Hong Yang wrote:

Good libraries are not enough for a language to go beyond mere existence. There must exist good documents, i.e., good tutorials, good books, and good explanations and examples in the libraries, etc, that are easy for people to learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better.

I wouldn't say 'better' as many, if not most, Perl libraries offer not much beyond example usage as documentation. Even if they do, the docs are often ambiguous, corner cases left to the user's imagination -- which is (at least in my case) regularly different from the library author's -- etc. IMO this is just the other extreme of the spectrum. It sure gets you started quite cheaply, but in the long run you pay an ugly amount of interest as you spend more and more time with debugging due to said ambiguities and corner cases. BTW, apparently, Perl library authors like to model their APIs after their mother language Perl itself, of which one could justly say that its only exact definition /is/ its implementation. Which doesn't mean that documentation of many Haskell libs couldn't be greatly improved... Cheers Ben

Interop between Haskell and Java is too difficult to be practical. And I stand by my statement that no Java shop is going to switch over to Haskell, precisely because they cannot afford to abandon either their existing investment, or the _billions of dollars_ worth of commercial- friendly open source libraries available for the Java platform. But I do agree on this: the JVM does indeed need a Haskell-like language. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Sep 27, 2009, at 8:10 PM, Curt Sampson wrote:

On 2009-09-27 10:36 -0600 (Sun), John A. De Goes wrote:

...

I'm not sure what the point of your series is. No one who is using Java now commercially can move to Haskell because Haskell doesn't run on the JVM.

That's a rather strong statement, and I don't accept it. I can not only think of many possible circumstances where it would be possible for a Java-using shop to write a piece of software that doesn't run on the JVM, but I have sween many of these. There are lots of shops out there using, e.g., C++ code as well as Java code, who are already obviously able to use non-JVM languages.

Given that, one point would be to show that there are more benefits to be gained by switching from Java to Haskell than there are from switching from Java to one of the other languages mentioned. This may be enough to tip some shops into Haskell.

Second, it might inspire people to have a look at bringing a more Haskell-like language to the JVM, or add more Haskell-like features to existing JVM languages.

Third, even if a shop is not going to switch, having people understand what's out there, and where many of these ideas come from, is a good thing, I feel.

cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

If you have counterexamples, then perhaps you can name them. I'm looking for Java shops with 5+ developers and code bases of > 100k converting over to Haskell. I don't know _any such shop_ that has switched to Haskell, and I doubt any exist, but I'd be delighted to learn I'm wrong. Let me ask you this question: how long would it take you to get an HTML/CSS, W3 compliant browser in Haskell? Or how about a peer-to-peer networking system with seamless scaling and automatic failover? How about a scalable BigTable implementation? In Java, the answer to these questions -- and just about any others you can think of -- is "a few minutes", because the code has already been written. Libraries are _everything_. In many cases, they can increase your effective budget by 10x or even 100x. That means instead of having $100k for a project, you suddenly have $1 - 10 million worth of resources at your disposal. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Sep 28, 2009, at 7:49 AM, Curt Sampson wrote:

On 2009-09-28 07:01 -0600 (Mon), John A. De Goes wrote:

...

And I stand by my statement that no Java shop is going to switch over to Haskell....

I have counterexamples. So "pfffft!"

...

...or the _billions of dollars_ worth of commercial- friendly open source libraries available for the Java platform.

Right; the library myth. I rank this one up there with, "Haskell can never be an effective programming language, because it doesn't have objects."

I've been hearing that having lots of libraries is an insurmountable advantage, and you're doomed if you give them up, since long before I took up Haskell. It's mostly myth promulgated by people driven by fear. I'm sure it's the case in some shops that they have lots of people who can glue libraries together but can't program, and they somehow manage to produce applications this way, but even that I suspect is not so frequent a situation as you'd think.

Nonetheless, since all of this is rather missing the point of my articles, anyway, I think I'll leave that as my last word on the topic.

cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Edward Middleton

...

If you have counterexamples, then perhaps you can name

them. I'm looking

...

for Java shops with 5+ developers and code bases of > 100k converting over to Haskell. I don't know _any such shop_ that has switched to Haskell, and I doubt any exist, but I'd be delighted to learn I'm wrong.

http://portal.acm.org/citation.cfm?doid=1596550.1596578

If you lack an ACM subscription, then this is likely the same document: http://www.starling-software.com/misc/icfp-2009-cjs.pdf Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

Ok, my last post on this for real this time. On 2009-09-28 08:13 -0600 (Mon), John A. De Goes wrote:

Let me ask you this question: how long would it take you to get an HTML/CSS, W3 compliant browser in Haskell?

A long time. On the other hand, by grabbing a copy of Mozilla, I'll have one far faster than you'll have yours in Java, mine will work a lot better, run more quickly, and work better with most sites. While I advocate using Haskell, I don't advocate being silly. (Incidently, I have direct experience with an almost exactly parallel situation. I replaced a system that was thousands of lines of difficult-to-maintain Java code with a few hundred lines of Haskell that feed Microsoft Excel. The user is very pleased that he can now can do far more extensive tweaking of the UI himself, including major features he never had at all before, such as real-time graphing of the data.)

Or how about a peer-to-peer networking system with seamless scaling and automatic failover?

Can you give me an example of a real-life system using this you've set up in "a few minutes"? My experience building systems with similar things (the very mature and proven MogileFS suite of tools) has been that the libraries were nice, but did not solve the majority, or even a large minority, of the problem.

Libraries are _everything_. In many cases, they can increase your effective budget by 10x or even 100x.

Or the other way around, as I've seen by ripping out thousands of lines of Hibernate code, and all of the work done to adapt a system to that model, and replace it with a few hundred lines of SQL and JDBC calls. That library has probably wasted more man-years than anything else I've seen in the Java world. cjs -- Curt Sampson +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

John A. De Goes wrote:

write them yourself (at a cost of several to dozens of man years), Is that right?

-- Tony Morris http://tmorris.net/

It's the early adopters who develop the first libraries that pull in ever wider audiences. Yes, the early adopters are drawn by the syntax of the language, but commercial adoption doesn't come until it's economically competitive to do so. And that doesn't happen until the library market is booming and/or they can seamlessly reuse existing assets (that's what the JVM languages discovered: if you allow people to use what they already have, in a seamless fashion, incrementally building new stuff using the new language, then you can dramatically shorten the time between early adoption and mass adoption). Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Sep 28, 2009, at 11:01 AM, Jason Dusek wrote:

2009/09/28 John A. De Goes :

...

Libraries are _everything_...

Not exactly. Python would never have gotten a foothold over Perl, nor Java over C, if cleaner language semantics weren't enough for some shops or certain applications.

-- Jason Dusek

...

...

...

...

"Michael" == Michael Snoyman writes:

Michael> not be written in pure Haskell, but then again I'm not Michael> sure if there are any fully W3 compliant browsers *not* Michael> written in C++. I'm not sure if there are any fully W3 compliant browsers. How could there be? It would mean consistent W3C recommendations. -- Colin Adams Preston Lancashire