Haskell is not an academic toy, but it is not corporate ready either

Submitted by metaperl on Sat, 11/05/2005 - 6:15am.

Today in #haskell, Sylvan said that Haskell had a reputation as an academic toy and that books should start off with Monadic I/O and other "practical" concerns to eliminate that stereotype.

Cale responded by saying that GHCi's REPL provided adequate I/O facilities.

I responded by saying that the most practical thing you could do in learning Haskell is to obtain the ability to decompose a problem into a set of functions. Everything else about Haskell follows from pure lazy functions and until you are comfortable and conversant in this paradigm, you really can't develop any new and useful code. You will simply be an ignorant little monkey, aping things you saw in a tutorial which crippled your ability to analyze and synthesize strongly-typed, lazy functions.

I did not say this then, but I also have this response. The impression of Haskell will not change with another book with practical examples. It will only change when Haskell has huge corporate-ready libraries for every huge corporate issue: when Haskell has a CPAN locked and loaded and ready to go. When Haskell has something as widely used as Mailman. When every website you see is done with Haskell instead of PHP. When you can deploy CORBA apps with Haskell. When you can cache and pre-compute queries for a SQL database in Haskell. When you have the speed and flexibility and eager persistent data loading of mod_perl for Haskell. When you have the best or second best or third best or any high-quality fully functional efficient streaming media player sitting on everyone's Linux desktop. When the favorite free drawing program is written in Haskell. For Haskell equating CPAN. CGI has been a web standard for almost 10 years. Try matching the real-world ready-to-go functionality of CGI.pm - that's one CPAN module in the Perl toolbox. Just one. Then you have 4000 more to go.

Haskell is the most beautiful, elegant, and correctly designed programming language on this planet. It is also the most powerful at chopping apart new specs and writing reliable code in short periods of time - how else could it stomp every other language 2 years in a row in the ICFP? But the only way to remove an impression is with results - tangibles, deliverables and unfortunately the focus on beauty, elegance and correctness seems to get in the way of ever getting anything corporate-ready out the door.

I am grateful to be studying Haskell. It has done wonders for my corporate-level Perl development. The book to read is "The Haskell Road to Logic, Maths and Computer Programming." This book will force you to think clearly. It does not cover monads, but monads can wait until you can specify and solve problems. But my improved thought processes are one thing. Delivering projects on a deadline is another and Perl continues to deliver through a cooperative community based around CPAN. The Haskell community is based around the reason of masterminds doing the intelligent things. The Perl community is based around the needs of people doing practical things in the best way that they can.

Finally, getting corporate ready is not something you can plan. It happens. It happens by necessity. It happens when someone has to swim or sink.

Submitted by jgoerzen on Sun, 11/06/2005 - 7:48pm.

On the one hand, you are right. The default CGI in fptools stinks (though there *are* competant CGI modules for Haskell out there.) HSQL has issues as well, etc.

On the other hand, look at the progress made in Haskell with a community vastly smaller than Perl's.

This situation is a concern, and was a concern for me when I switched from Python to Haskell.

However, I believe that Haskell will continue to improve rapidly. We already have basic working code for a CPAN-like system (Python doesn't even have that).

Within the past year, I alone have written FTP client and server modules, Python interface library (not available for Perl), native GZip parser, a filesystem virtualization framework (not available for Perl AFAIK), etc. Others have written major new features for Cabal, new Web frameworks, new IRC code, great progress on editors, regular expression libraries, etc.

It is true that there is a larger codebase in Perl than Haskell.

What I find is that reinventing the wheel in Haskell is faster than reusing it in Perl.

Case in point: my Gopher bot. I decided that we need to preserve Gopherspace, so I wrote a bot to archive it (like archive.org). I wrote it from scratch. Had I used Perl or Python, I could have used existing libraries for various bits and pieces. In Haskell, I used HSQL and parts of MissingH.

I had a working, multithreaded, persistent bot going in just a few hours. I was able to make dramatic changes to the threading and spidering algorithms very quickly, and they usually worked the first time I tried to run the resulting program.

The more I use it, the more I am impressed with how amazingly productive I am in Haskell.

Submitted by Cale Gibbard on Mon, 11/07/2005 - 1:28am.

I'd like to point out that I made that comment in the context of teaching the language. Of course for practical considerations, one is eventually going to have to learn about the wonderful IO facilities that Haskell provides (but I disagree that IO is the most important thing to teach first).

There are plenty of people out there who already have a great deal of experience in decomposing problems, and for whom the main issues in learning Haskell are primarily language issues: What is the syntax? How does the type system work? What's available in the standard libraries? Of course, there's usually also the question of monads, as most people haven't been exposed to them either, but I find that this really isn't a difficulty when people are adequately prepared through discussion of the type system, and when things are presented clearly.

Of course, there are other computer science topics that become less obscured when one is writing Haskell code than say, Java, or Perl. One can discuss various recursion schemes, catamorphisms on various types for example, in a much more natural way. It also opens the floor for very practical-minded discussion about category theory. One can extend one's notion of a Haskell Functor or Monad to the corresponding notions of category theory, and get a much wider and richer perspective. This is a good thing, but it's a separate issue from just learning the language Haskell. As someone with a mathematical background, I would say it's very useful to know about general ways of thinking about things. However, I still wouldn't consider it essential to know about the more general setting to be able to write pragmatic Haskell code, and get what is essentially the full benefit of this nicely designed, very practical programming language.

I find that it's very easy in Haskell to write programs to solve problems. Even when I just started learning Haskell, and the standard libraries were a lot smaller than they are today, I was impressed with how easy it was to get things done (even if my code at the time was not as pretty as it could have been). The relatively small number of libraries which were available, were usually very generally useful. In Haskell, learning a new library can be like learning a new programming language in terms of the new features which are expressible. In the case of the monad template libraries, there is a sense in which this is quite literal, as they describe building blocks which one can put together into specialised languages in which to express a solution to one's problem.

Now we have library support for quite a number of specialised things, and it's growing all the time. There are libraries for OpenGL, X11 and GTK2, as well as cross-platform GUI support. There are parser combinators and pretty printing libraries. A system of program distribution and compilation management libraries. Libraries for tackling graph theoretic problems. Libraries for automatic code testing. Libraries for manipulating XML and connecting to databases. This has all come together in the last few years, and is continuing to develop at quite a rapid pace given the size of the Haskell community.

I would say that Haskell is ready for many (or perhaps even most) corporate tasks. There are some tasks in which one might still struggle, but it's getting better every day. At the same time, the basics of the language necessary to write simple code remains relatively easy to learn. Certainly, starting from scratch, learning Haskell is no harder than learning most OO languages. One can always delve deeper into the details of how things work, or learn new abstractions and libraries built with Haskell, but to get yourself started writing useful programs, it's impressively easy. (People only complain because they can't get immediate satisfaction from their knowledge of imperative and OO languages.)

Anyway, that's my take on things. Haskell is both a very nice academic language, and one which is already fairly practical to write everyday code in. I have at almost every turn, found it a very nice direct language for expressing ideas about how to solve a problem computationally, and also for getting the satisfaction of being able to run those ideas directly on a computer, bringing them into the real world.

Submitted by jfeingold on Tue, 03/14/2006 - 10:34am.

One thing that might help adoption is better documentation. Many interesting libraries that ship with GHC have dozens of functions that contain absolutely no comments of any kind. For example, the parsec library is wonderful but, to use it, you need to visit the author's website and view descriptions of functions for an outdated version of the library. Much of the socket libraries is lacking documentation as well. I think this may be a barrier for some people.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.