The future of Haskell discussion

[S. Alexander Jacobson]

Rather than talking about general features of the language that might
improve adoption in general, it is more useful to talk about specific
features of the language that make it killer in a particular application
domain.

In his classic book, "Crossing the Chasm : Marketing and Selling High-Tech
Products to Mainstream Customers", Geoffrey Moore argues that the way to
gain mainstream adoption of a new technology is to target specific
segments of the customer population and to deliver whole product to them
(because integration challenges are daunting).

In http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt, Paul Graham
argues that:
   One of the reasons to use Lisp in writing Web-based applications
   is that you *can* use Lisp.  When you're writing software that is
   only going to run on your own servers, you can use whatever language
   you want.

And further that:
   Until recently, writing application programs meant writing software to
   run on desktop computers.  In desktop software there was a strong bias
   toward writing the application in the same language as the operating
   system.

I would add that web based applications can use web interfaces and that
HTML is a good interface to many applications.  (and that Paul Graham's
comments about Lisp are also true of Haskell)

As such, I would like to see a focus on making Haskell great for web
application and web service development.  Some of the the pieces required
are application level, some are libraries, and some are language features.
Here is my quick take:

Application Framework
* a simple build/install process on both unix and win32
* a way to run/link haskell applications to a web server (apache)
* a decent libary organization and CPAN-like library sharing system
* a system for publishing apps to live servers

Libraries
* an OS file/directory access library
* a database connection library (even just ODBC would be fine!)
* a database connection pool library
* a mail handling library
* an XML parser library
* an XML-RPC/SOAP library

Language Features
* concurrency (to make requests to multiple servers simultaneously)
* FFI (to access libraries in other languages)
* exceptions (may not matter depends on the webserver/haskell interface!)

Documentation
* an O'Reilly class book on learning and developing web apps in Haskell
* sample applications that demonstrate useful web service functions
* a process for managing Haskell web app development

As a general matter, the addendum process strikes me as confusing and
dangerous.  I don't want to have a conversation like: I am using
Haskell'98 with Addendum A, C, and E.  I'd rather say, I am using Haskell
2001 and know that it is useful for developing web apps.

I know this is a lot of work, but it was what you get from Python, Perl,
and Java.  If Haskell wants to compete in this arena, it needs to provide
this level of service.  Also, I think a lot of these exist in pieces, so
the real work is in compiling it all into a good usable package.  I am not
volunteering to do it, but I would be happy to help beta if someone else
does.

-Alex-

PS There may be other better/easier initial application domains for
Haskell, but this is what I know.


___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-646-638-2300 voice                    The Easiest Way To Shop (sm)



On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote:

> Olaf Chitil <olaf@cs.york.ac.uk> wrote,
>
> > Here a short summary by Malcolm and me of the final discussion at the
> > Haskell workshop:
>
> I also took a couple of notes which I like to add.
>
> > John Launchbury and many further people made a plea that the single
> > biggest hindrance to the further spread of Haskell is the lack of a
> > standard
> > cross-platform GUI. Alas, no answer to the problem was found. There is
> > no agreement which (existing) library could be the basis of a standard
> > one and nobody wanted to commit himself to developing and supporting
> > such a library. Well, Manuel Chakravarty promised to continue developing
> > the GTK+ binding and would be happy about people helping him. (The GUI
> > library presented at the workshop is not intended to solve the standard
> > GUI problem.)
>
> In fact, the recent release of binary packages for Gtk+HS
> and an example applications that demonstrates how to use
> the GTK+ API in Haskell have been a reaction to the
> discussions at HW & ICFP.
>
> Let me reiterate: Gtk+HS as it is today is sufficient for
> applications requiring a GUI of medium complexity.  As far
> as I see, despite not covering all of GTK+ yet, Gtk+HS
> already has a wider variety of widgets and functionality
> than Tcl/Tk provides in its whole API.  So, at least on
> Unix, the statement that there is no GUI for Haskell is just
> not valid anymore.  For Win32, somebody would have to set up
> the binding for use with the Win32 port of GTK+.  I am happy
> to include any patches coming out of this into the main
> distribution.
>
> You can see how programs coded against the GTK+ API in
> Haskell look like at the following example:
>
>   http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html
>
> (As for Unix/Win32 portability of GUI code, that's not great
> for C or C++ either.)
>
> > Rather than starting work on a successor to Haskell, people
> > generally want to see `blessed addendums' to the Report,
> > for common agreed extensions, e.g. FFI, exceptions,
> > concurrency, MPTC, fundeps, etc.  The FFI addendum is almost ready,
> > but any others need volunteers, not to mention agreement between
> > designers and implementations.  The idea is that a solid
> > reference definition/documentation of each extension should
> > exist independent of any particular compiler (but there is a lack
> > of volunteers).
> >
> > It was noted that the future job of designing Haskell-2 will be
> > made much easier by many small steps rather than one large effort.
>
> Generally, as last year, there seemed to be not much
> interest to look into Haskell 2.  Meanwhile, addenda to H98
> seem to be a feasible alternative.  In fact, one aim with
> the FFI Addendum was to create a precedent that can be
> repeated for other extensions.
>
> The nature of an addendum brings with it that the extension
> should be rather non-invasive.  For example, in the case of
> the FFI, one new keyword (`foreign') is added, taking it from
> the pool of available variable identifiers.  The rest of the
> functionality should not invalidate any existing H98
> programs.  As a consequence, the kind of extensions that can
> be realised in this way are limited.  For example,
> extensions of the type system are much more likely to have a
> severe effect on existing H98 programs.  So, they will be
> less easy to add in this form.
>
> It was also pointed out that we should go for an addendum
> only where
>
> - the design is clear and tested (example implementations
>   exist and have been used in applications) and
>
> - where there is considerable demand.
>
> The first point is surely self-explanatory.  As for the
> second, defining an addendum is a lot of work, which can be
> used better otherwise unless the extension is really
> important.
>
> Possible further addenda (in addition to the FFI), which
> have been mentioned, are the following:
>
> - The core library (in fact, there is already exists a task
>   force to look into this extension)
> - Concurrency support (there just are applications that are
>   virtually impossible to implement well without
>   concurrency)
> - Exceptions (again a really elementary feature of modern
>   languages)
> - Graphics library (obviously there is a lot of demand, but
>   it is also a rather involved task)
>
> In my opinion, all the above functionality falls into the
> catergory embarrassing not to have.  The lack therefore, in
> fact, promotes the image of Haskell being an academic toy
> language.  The only exception is to a degree the graphics
> library (again my opinion, which obviouly is not shared by
> everybody, most notably John Launchbury).  My reason is
> that, while access to GUI toolkits is a must, few languages
> standardise them.
>
> Type extensions (multi-parameter type classes, existential
> types, rank-2 polymorphism, etc.) have been mentioned, but
> it seemed that there isn't really a consus as to how they
> should exactly be implemented and whether they are really so
> urgently needed.  Moreover, they tend to be more invasive.
> Personally, I would believe that multi-parameter type
> classes may maybe be the most likely candidate for an
> addendum.
>
> There was the feeling that there is not frequent enough
> feedback from the "Task Forces" (eg, FFI Task Force, Library
> Task Force) to the Haskell community as a whole.  Clause
> Reinke kindly volunteered to collect status reports of Task
> Forces on a 6-monthly basis and post them to the Haskell
> mailing list.
>
> Claus, maybe you should give the Task Forces an idea of when
> you expect the first status report.
>
> > Manuel Chakravarty: A standard Foreign Function Interface for Haskell98
> > Basically finished (general part and C, not for Java). Solicits last
> > comments from the general community.
>
> The plan is to have one last round of edits on the FFI list,
> and, then post the draft on the main Haskell list.  (Should
> happen soon, but I am still trying to recover from jet lag
> and a huge pile of emails and todos that waited for me upon
> return from ICFP).
>
> Cheers,
> Manuel
>
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>