[Haskell] Haskell as a disruptive technology?

[Cale Gibbard]

On 26/03/06, Paul Johnson <paul at cogito.org.uk> wrote:
> + Good support for loosely structured data such as XML.
http://www.fh-wedel.de/~si/HXmlToolbox/

> - Slower programs (Shootout efforts notwithstanding)
I'd say it depends on which Haskell implementation you're using and
which other language implementation you're comparing with. Let's say
you're talking about GHC. Slower than hand-tuned C or assembly? Sure,
for the most part, you could usually do better. Then again, if you
really want performance, you might try writing a Haskell program to
write your C or assembly for you, and search through possible
implementations (see FFTW for an example of this being done with
O'Caml). Slower than Java or VB or Python? Probably not. Of course, it
all depends on what level of tuning you want to go to, and how well
you understand code performance in Haskell.

> - Larger memory footprint
Larger than what? I haven't noticed my Haskell programs using much
more memory than reasonable. Sure, if you're processing really large
blocks of data in a *non-sequential* manner, and using lists to manage
it, it'll be slow, but that's just an example of using the wrong data
structure. You can make the same mistake in C.

> - Little integration with GUI tools.  No "Visual Haskell" or "Borland
> Haskell" equivalents.
As has been pointed out, Visual Haskell actually does exist. It
doesn't have much to do with building GUIs, but it does have nice
integration with GHC to do things like automatically highlight type
errors, and provide contextual completion. One nice combination you
can make with GUI tools is to use Glade to design your GUI and load
the resulting XML file using Gtk2Hs. The effect is not unlike that of
using VB to design your GUI. While as of yet, there's no direct Glade
support for writing the boilerplate GUI-loading code in Haskell, it's
still not so much trouble (iirc, it's only 5-10 lines of code to get
something on the screen, to the point where you can start adding event
hooks). I highly recommend trying it, you can get fairly complex GUIs
off the ground with relatively little code.

> - Little integration with databases.
HDBC looks rather nice, and has drivers for Sqlite v3, PostgreSQL, 
and ODBC, and apparently is really easy to extend to other databases.
(About 1-2 days work for a new driver, from what I heard)

> - Little integration with mainstream software development.  No analysis
> or design methods or notations.  Haskell development appears to be
> primarily a matter of paying a bunch of very bright developers to cut code.

Hm? I'm not exactly sure what you're after here. No analysis methods
or notations? What's wrong with ordinary mathematical proofs /
denotational semantics? Haskell programs usually satisfy quite a few
nice properties, so it's far easier to prove them correct than your
average C++ program.

As for design, well, we don't have many gimmicks like UML, but English
(or whatever language you like to use) is decent. You can also draw
things like module dependency graphs, which occasionally help a bit.
I'm not really sure what a 'design notation' would be -- Haskell is a
decent enough notation for program design on its own. You can usually
construct almost any abstraction you'd like to use to design your
program in, along with an interpretation so that the specification
actually runs.

As for design methods, that's somewhat language independent, isn't it?
The usual top-down and bottom-up approaches both work reasonably well.
Some people also use an approach which is somewhat like 'inside-out',
building a path through the main functionality of the program at every
level, usually with the intent of getting the thing running, and then
rounding that out with features afterward.

> - Concerns about support and maintenance.  Those bright developers may
> not be around in the long term.

This is a valid concern, as there aren't too many Haskell programmers,
compared to, say, C++ programmers, but things are getting better here.
Many universities are teaching students to use Haskell in their
courses.

On the topic of what applications might be good, Haskell is a really
great language in which to construct domain specific languages.
Because it's so easy to do, I think one area where there's a lot of
potential is for people to create interesting embedded DSLs in which
to express business logic, where perhaps a data entry UI, and data
storage mechanism would be automatically generated from the EDSL
description. SPJ described a mechanism for using Haskell in order to
express and reason about business contracts.

Another area which I find interesting is in code generation for modern
processors. Processors are getting really complicated, and it's
getting quite tricky for humans to hand-tune code to take full
advantage of them. Problem-specific code generators, or even
higher-level programs which make use of those in order to build
provably correct high-performance software would be much nicer to
write in a language like Haskell.

 - Cale