Haskell as a disruptive technology?
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.
Hi,
- Larger memory footprint You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint.
- Little integration with GUI tools. No "Visual Haskell" or "Borland Haskell" equivalents. http://www.haskell.org/visualhaskell/ - indeed there is :)
- Little integration with databases. There are quite a few Haskell DB programs, I've never used any, but they do exist.
Thanks Neil
Neil Mitchell wrote:
- Larger memory footprint
You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint.
We should be clear about whether we're talking about the footprint of the compiler or the generated binary. I can well believe that GHC needs a lot more memory than nhc98 to run, but I'm not at all sure that the same relation holds when you consider the generated binaries, especially when GHC's compacting collector is being used and optimisation is turned on. Code size is probably larger with GHC. It'd nice to see some actual measurements done here. Cheers, Simon
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.
Paul, very interesting reflections! There are a lot of small businesses that could benefit from those type of software to automate their existing workflow. Like you have pointed out, some are already utilizing excel macros and off the shelf packages, hence the popularity of microsoft access. Although this trend minimizes a business's competitive advantage, as people are now forced to work in the framework of the software instead of their more efficient natural business operation model; interestingly enough, it has the benefit of making the task performer interchangable (e.g. Hiring someone who already knows how to use QuickBooks from a previous job). Recall the earlier remark about : "support and maintenance. Those bright developers may not be around in the long term"? By using _generic_ software, software maintainence is transformed into staff maintainence. From a manager's perspective, this is a much much more tractable domain. Programming job postings nowadays are laden with buzzwords, a trademark of genericity, instead of simply saying, one bright developer please. It is conceivable that this cycle is self fullfilling as bright developers are far and few. In addition, even with bright developers, their software creations, no matter how provably correct, are still sub-turing. A $10/hour intern can not only correct bad user inputs but also make you coffee. Hence, I feel this is just as much a social issue as a technological one. jake
On 26/03/06, Paul Johnson <paul@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
Paul Johnson wrote:
- 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.
Writing a functional specification is a very good design method. The nice thing with Haskell is, that this specification is executable and with ghc it usually executes fast enough.
- Concerns about support and maintenance. Those bright developers may not be around in the long term.
This seems to be a hen & egg problem. Students do not study functional programming deeply because it seems irrelevant to finding a job. Decision makers, on the other hand, either have never heard of FP or are aware that there are not enough people familiar with it and so there are natural concerns about maintenance. Michael
- Concerns about support and maintenance. Those bright developers may not be around in the long term.
This seems to be a hen & egg problem. Students do not study functional programming deeply because it seems irrelevant to finding a job. Decision makers, on the other hand, either have never heard of FP or are aware that there are not enough people familiar with it and so there are natural concerns about maintenance.
On the other hand, a project is much more likely to succeed if bright developpers are involved. Using haskell is a very good way to attract bright developpers. Hence, a project is much more likely to succeeds if it uses haskell. This is exemplified by the Pugs project. Cheers, JP.
participants (7)
-
Cale Gibbard -
J -
Jean-Philippe Bernardy -
Michael Marte -
Neil Mitchell -
Paul Johnson -
Simon Marlow