I'm reading Clayton Christensen's classic book "The Inventor's
Dilemma". The gist, for those who haven't heard of it, is that
successful large companies are tuned for "sustaining" technology
improvements: small incremental improvements. But every so often a
"disruptive" technology comes along that leaves the incumbents
flat-footed. Christensen presents a detailed case study of the hard
drive industry, where at every stage in the shrinkage of disk drives
(14" mainframe, 8" minicomputer, 5.25" microcomputer,
3.5" for early laptops) the incumbent companies could not see the
attraction of the smaller size drives to be sold in small markets for
small margins. Instead they pursued premium customers in the high end
of the computer industry.
Something similar happened to steam shovels. Hydraulic diggers were
initially small and low value, sold to farmers and builders to dig
trenches. Steam shovels were sold to quarries and big construction
projects, and that was where the money was. The steam shovel companies
subsequently went bust and hydraulics now rules the world.
The problem for the incumbents was never the technology: both disk drive
makers and steam shovel manufacturers were capable of mastering and
using the new technology. The problem was identifying and targetting
markets. The term "disruptive market" might actually be more
descriptive. For example, most camera manufacturers have made the
switch to digital. The technology is radically different, but the
market is just the same. On the other hand the smaller disk drives were
essentially the same technology, but sold to a very different market
with different value networks and propositions.
Which leads me to consider Haskell. Haskell has all the signs of a
disruptive technology: a different value proposition which stacks up
badly against current industry norms, but has attributes that are likely
to be valued by someone somewhere. The question is, who?
Haskell's current value proposition, relative to "standard" programming
languages (as I see it):
+ Faster development (4-10 times)
+ More reliable software (hard to quantify, but probably a similar
improvement)
+ Good concurrency support with STM.
+ Good support for loosely structured data such as XML.
- Slower programs (Shootout efforts notwithstanding)
- Larger memory footprint
- Little integration with GUI tools. No "Visual Haskell" or "Borland
Haskell" equivalents.
- Little integration with databases.
- 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.
- Concerns about support and maintenance. Those bright developers may
not be around in the long term.
So: we seem to be looking for a market that is currently under-served by
incumbent languages because its not worth bothering with. It doesn't
need complex databases (although a few ODBC queries are OK) or lots of
GUI dialogs. The software is likely to be run on comparitively few
computers (so that development cost is more important than hardware
cost), or else do something that is not very computationally intensive.
It is likely to have some degree of concurrency or soft real time (to
use that STM capability), and have a short lifespan so that maintenance
is not too much of a concern.
Bear in mind that this market may well not use software at present, or
it may be using computers in a way that is not thought of as
"programming". For example they may be using horribly complex Excel
macros to do stuff. The current pain point may actually be reliability
and verification rather than development cost. They probably think that
hiring programmers to solve their problems is beyond their budget, and
attempts to sell them a conventional development contract will fail to
even get a hearing.
I don't know what this market might be. Does anyone have any ideas?
Paul.
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
