Re: [Haskell] Haskell as a disruptive technology?
Neil Mitchell wrote:
- Larger memory footprint
You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint.
I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language.
- Little integration with GUI tools. No "Visual Haskell" or "Borland Haskell" equivalents.
http://www.haskell.org/visualhaskell/ - indeed there is :)
I've never used Visual Haskell, but from the web page two things stand out: 1: Its version 0.0. This is not for production use. 2: Its just a programming environment. The point I was making was about integration with GUI tools. You can't (AFAIK) draw a dialog box and then tie each button to a Haskell function in the IO monad.
- Little integration with databases.
There are quite a few Haskell DB programs, I've never used any, but they do exist.
I have used HSQL, and it does what it does perfectly competently. But it requires a bunch of boilerplate code in the IO monad for every query. There are higher level libraries that build nice type-safe stuff on top of this, but they don't seem to be production strength yet. Remember that this is not about what Haskell could or should be in the future, its about what Haskell is right now. If you start a Haskell development project then this is the reality that you face. Now, we could try to fix these "deficiencies". That means playing catch-up with the entire infrastructure that has been erected around conventional languages. We will simply never succeed. Sure, we can probably do it with a 10th the manpower of the conventional languages, but they have 100 times our manpower to throw at the problem. Or we can play to our strengths by looking for markets where the negatives don't matter, or matter less than the positives. Haskell offers a value proposition that is very different to conventional languages. There is likely to be a market out there that is poorly served by conventional languages, but where Haskell will fit very nicely. All we have to do is find it and target it. Hmmm. I wonder about simulation and testing. Some time ago I asked here about doing discrete event simulation, and I have succeeded. (Unfortunately the resulting code is owned by my employer, so I can't share it). QuickCheck has shown a new approach to testing. Testing of stateful stuff using this approach would require a simulation of the thing to be tested. This might be a winning proposition. Paul.
paul:
Neil Mitchell wrote:
- Larger memory footprint
You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint.
I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language.
It's not always clear that it won't work for very fast computation: http://shootout.alioth.debian.org/gp4/benchmark.php?test=partialsums&lang=al... In general I would say GHC/Haskell was very very fast, as long as you know what you're doing. -- Don
"Donald Bruce Stewart" <dons@cse.unsw.edu.au> writes:
In general I would say GHC/Haskell was very very fast, as long as you know what you're doing.
I have created programs that fill an array with the first 1000000 prime numbers using erathostenes sieve. I have done this in lisp, c++, ocaml and haskell. Lisp and c++ win hands down, being approximately 5x faster than ocaml, haskell. Immanuel -- *************************************************************************** I can, I can't. Tubbs Tattsyrup -- Immanuel Litzroth Software Development Engineer Enfocus Software Antwerpsesteenweg 41-45 9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell@enfocus.be web : www.enfocus.be ***************************************************************************
So far all the responses apart from the one by "jake" have taken issue with one or other of my assessments of Haskell's weaknesses. Curiously, nobody seems to be arguing with my assessments of its strengths. I know the feeling: Haskell is so obviously great that it becomes a kind of spinal reflex to defend it against even the slightest slight. I used to feel that way about Eiffel, before I learned Haskell. And we could have long and learned arguments about how to optimise GHC, the relative benefits of nhc98, wxHaskell vs Gtk2hs, and all the rest it. But in my original post I tried to look at a broader question. I've seen other excellent languages wind up as roadkill (did I mention I liked Eiffel?), and one thing I have learned is that trying to fight the incumbents on their own turf is just suicide. You will never win, and it doesn't matter how long you try or how brilliant your technology is. There are lots of reasons for this, some good, some bad, and thats just the way the world is. History has repeatedly shown that the only way you dislodge an incumbent technology is through the "disruptive technology" route, which would be better described as "disruptive marketing". Find a niche that is not adequately addressed by the incumbents and establish a beachead there. Then move out from that base. So I tried to summarise the Haskell "value proposition" compared to the incumbent languages. Thats what it looks like to me, and I am not exactly ignorant on the subject, so I suggest we take it as a given for now and look at the real question: Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend? Paul.
Paul Johnson <paul@cogito.org.uk> wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to railway signalling equipment, to medical devices. These markets are relatively small / low-volume, with needs for high assurance, and better development times. However, despite these appealing characteristics, I would say Haskell is still currently unsuitable for those areas. * These tend to be embedded systems, with daunting memory, speed, and power-consumption limits. * Analysing and guaranteeing performance characteristics (time, memory) is something we still can't do well with Haskell. Note, this is not a question of raw speed, it is a question of hard guarantees to meet deadlines. In this field, a slow implementation that provably meets a deadline of 2ms is better than a fast implementation that claims a cycle time of .02ms, but cannot be shown to be failure-free. Regards, Malcolm
Malcolm Wallace wrote:
Paul Johnson <paul@cogito.org.uk> wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to railway signalling equipment, to medical devices. These markets are relatively small / low-volume, with needs for high assurance, and better development times.
Well, the market is growing and not that small. ;-) Think of mobile phones and cars, for instance, they are "full" of embedded computers.
However, despite these appealing characteristics, I would say Haskell is still currently unsuitable for those areas.
* These tend to be embedded systems, with daunting memory, speed, and power-consumption limits. * Analysing and guaranteeing performance characteristics (time, memory) is something we still can't do well with Haskell.
Well, is it a problem to make GC a deterministic task or there is a problem that a program may run out of memory unpredictably? Can you be more explicit, or link to some article? Regards Dusan
* Analysing and guaranteeing performance characteristics (time, memory) is something we still can't do well with Haskell.
Seconded. I think all three of: specification, prediction and post-morten analysis of resource consumption of Haskell programs are largely uncharted territory. I don't see a widely accepted formal base (a resource calculus) and that's probably why there is no tool support (yes, I know about ghc -prof -auto-all). Ultimately, there should be some refined type system that allows to express and prove resource consumption guarantees. best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Dusan Kolar <kolar@fit.vutbr.cz> wrote:
Yes. Safety critical systems, encompassing everything from avionics to railway signalling equipment, to medical devices. These markets are relatively small / low-volume, with needs for high assurance, and better development times.
Well, the market is growing and not that small. ;-) Think of mobile phones and cars, for instance, they are "full" of embedded computers.
The embedded computation market is certainly huge (about 10x the size of the PC market), but how many of those systems are actually safety critical? Mobile phones certainly are not. A safety critical system is one whose failure could directly lead to loss of life, e.g. gas turbine engine controller on an Airbus.
* Analysing and guaranteeing performance characteristics (time, memory) is something we still can't do well with Haskell.
Well, is it a problem to make GC a deterministic task or there is a problem that a program may run out of memory unpredictably? Can you be more explicit, or link to some article?
The problem goes much further than amortising the cost of GC. With lazy evaluation, in general we do not even know the complexity class of space usage (constant, linear, exponential) for any given program of moderate size without doing some empirical measurement or profiling. There have been a few attempts at formal analysis in this field (Pareto and Hughes, Hammond and Michaelson) but nothing is yet truly comprehensive. Regards, Malcolm
Dusan Kolar wrote:
Malcolm Wallace wrote:
Paul Johnson <paul@cogito.org.uk> wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to railway signalling equipment, to medical devices. These markets are relatively small / low-volume, with needs for high assurance, and better development times.
Well, the market is growing and not that small. ;-) Think of mobile phones and cars, for instance, they are "full" of embedded computers.
Mobile phones are a big market, but they are not safety critical. In fact, you can make a phone which crashes quite often and still sell it successfully (as I know to my cost!). Low power (==long battery life) is probably more important for phone software. Here execution time is strongly correlated with energy use, but things like compacting garbage collection can actually help--you can turn off part of your memory after a GC and save the leakage current. I think low power functional programming could be very interesting, but we certainly have no good story on this point at the moment. Car components are commodities and sold under extreme price pressure. Because volumes are high, the price per unit is all that matters, and there is typically no way to charge for software at all--it's assumed that the subcontractor develops it as part of the development cost of the component. Maybe that could give Haskell an advantage--lower software development costs--as long as the hardware doesn't need to cost a penny more. But again, with hard real time constraints, this doesn't feel like a natural market for Haskell in its current state. I think Paul asked just the right question--but I wonder if we'll see the answer on this list? After all, anyone with a really *good* answer stands to make a lot of money... John
Paul Johnson wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
yes - teaching principles of programming (and languages). E. g. I have my students (2nd year) learn (some) Haskell first, so they will hopefully understand better what is a (polymorphic) type and what is behind those OO-design patterns (Composite => algebraic data type, Visitor => map/fold, Template Method => higher order function etc.) But the comparison to e. g. Java also shows quite clearly that Haskell is lacking some features (ranging from essential to convenient) in the area of software engineering (module system, record system, annotations, etc., see some entries on Haskell-prime) And I don't hide that opinion from the students. You may say that my teaching is "disruptive", but then, there's no "market" since the students have no choice ... But most of them accept the challenge. (I'm afraid they'd accept an advanced Perl(*) hacking course as well.) (*) - replace with name of any untyped interpreted scripting language. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On 3/27/06, Paul Johnson <paul@cogito.org.uk> wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
As far as I'm concerned, yes almost every market. At least soon. Within a few years (say, five) we will have tens of cores on the desktop. The speed of an application will correspond fairly directly to how well it uses multiple threads. This will only become more and more true in the future. Haskell (lightweight threads + STM) really is a godsend in this area. It's really not feasible to distribute a general application to tens or hundreds of threads in C++ (or any imperative langauge, really). Some specific problems (e.g. raytracing) are simple enough to be easily parallellised in any language, but in general we need purely functional programming with good support for concurrency and parallellism if we are to have any hope of remaining sane while using these massively multicore systems of the future effectively. Haskell (or rather GHC) is ideal here. Parallellising pure functions are fairly easy, for concurrency I think message passing and immutable values are really pretty the best story right now, and even if you decide you need some layer of shared-state concurrency we can remain pretty safe using STM. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
On Mar 27, 2006, at 9:03 AM, Sebastian Sylvan wrote:
On 3/27/06, Paul Johnson <paul@cogito.org.uk> wrote:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
As far as I'm concerned, yes almost every market. At least soon. Within a few years (say, five) we will have tens of cores on the desktop. The speed of an application will correspond fairly directly to how well it uses multiple threads. This will only become more and more true in the future.
FWIW, I'd like to voice my agreement with this view. The hardware manufacturers are hard at work building the perfect niche for Haskell -- all of commodity desktop computing! Moore's law is still packing more transistors onto the silicon, and it seems like people have run out of ideas for what to do with them, so they just start duplicating cores ;-) All we have to do is be ready for it when it arrives. When people see that, using Haskell, they can write programs using 1) fewer man-hours with 2) fewer bugs which 3) scale effortlessly to highly parallel hardware to beat the pants off C/C++/Java/what-have- you, they'll be beating down the doors to get it. I'd love to see Haskell on highly concurrent hardware becoming more of a reality: Haskell on the Cell is a great idea; I'd love to see Haskell over MPI (using YHC bytecode maybe?); Haskell-over-GPU (you know you like it!); and of course, SMP Haskell is also interesting. One of the things I love about Haskell is that the language definition transcends execution strategy/environment.
Haskell (lightweight threads + STM) really is a godsend in this area. It's really not feasible to distribute a general application to tens or hundreds of threads in C++ (or any imperative langauge, really). Some specific problems (e.g. raytracing) are simple enough to be easily parallellised in any language, but in general we need purely functional programming with good support for concurrency and parallellism if we are to have any hope of remaining sane while using these massively multicore systems of the future effectively. Haskell (or rather GHC) is ideal here. Parallellising pure functions are fairly easy, for concurrency I think message passing and immutable values are really pretty the best story right now, and even if you decide you need some layer of shared-state concurrency we can remain pretty safe using STM.
Indeed. And for this reason, I'm glad to see concurrency very seriously considered for Haskell'. I'd even go so far as to say that STM is a good candidate for inclusion, or at least for addendum status. STM makes writing concurrent programs a joy rather than a total PITA. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
On 3/27/06, Robert Dockins <robdockins@fastmail.fm> wrote:
I'd love to see Haskell on highly concurrent hardware becoming more of a reality: Haskell on the Cell is a great idea;
From what I've heard, programmers of games for next-gen consoles (XBox 360 and PS3) are having a hard time using all available cores effectively. Tim Sweeney (founder of Epic games, these days probably best known for his work on the Unreal game engine) talked about some of these issues in his POPL talk (http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf). There are some interesting details on the characteristics of code that goes into modern games, and he thinks there is lots of room for (lazy) functional programming. There are some nits that he doesn't like about Haskell, but the overall direction of the language is the right one.
There is a long discussion of this talk on Lambda the Ultimate (http://lambda-the-ultimate.org/node/1277) in which Sweeney took part. One interesting quote from him: " do believe [garbage collecting memory] is completely practical as the sole memory management solution, even in a realtime application like a game." It's true that games development does not fulfill all of the criteria Paul set out as the ideal niche for Haskell to take and grow by stealth to world domination: it is way too big and visible a market. But it does seem like it would be worthwhile to push existing Haskell compilers to support multicore CPUs and eventually to include more extreme multicore cases like the Cell. Davor
Paul Johnson <paul@cogito.org.uk> writes:
So I tried to summarise the Haskell "value proposition" compared to the incumbent languages. Thats what it looks like to me, and I am not exactly ignorant on the subject, so I suggest we take it as a given for now and look at the real question:
Is there a market that is poorly served by the incumbent languages for which Haskell would be an absolute godsend?
What about speed of development, and speed of change? One of the pragmatic programmer guys recently suggested that software development could become simple enough that you could have a dev on every street corner. You'd walk down to the corner and ask for certain app, then get it in a few hours. Abstraction addiction can be a danger, but it also lets you put out working code in a tiny amount of time, as well as later extend that code to add new features in equally small amounts of time. What if development time for new programs was measured in days not years? -- I've tried to teach people autodidactism, | ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson
G'day all. Quoting Immanuel Litzroth <immanuell@enfocus.be>:
I have created programs that fill an array with the first 1000000 prime numbers using erathostenes sieve. I have done this in lisp, c++, ocaml and haskell. Lisp and c++ win hands down, being approximately 5x faster than ocaml, haskell.
Can we see your programs? Cheers, Andrew Bromage
<ajb@spamcop.net> writes:
G'day all.
Quoting Immanuel Litzroth <immanuell@enfocus.be>:
I have created programs that fill an array with the first 1000000 prime numbers using erathostenes sieve. I have done this in lisp, c++, ocaml and haskell. Lisp and c++ win hands down, being approximately 5x faster than ocaml, haskell.
Can we see your programs?
Yes, I'll post them tomorrow. Immanuel -- *************************************************************************** I can, I can't. Tubbs Tattsyrup -- Immanuel Litzroth Software Development Engineer Enfocus Software Antwerpsesteenweg 41-45 9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell@enfocus.be web : www.enfocus.be ***************************************************************************
As an author of HSQL and Visual Haskell I do agree that there is still a lot to be done in order to make Haskell as popular as C++/Java in the industry. We need strong support for GUI, Database, XML and many other libraries that the other languages already have. The existing development environments also need a lot of improvements. I know that we already have many bits of that but it is still not enough. Fortunately the situation is improving and now we have much better libraries and tools than few years ago. Cheers, Krasimir 2006/3/27, Paul Johnson <paul@cogito.org.uk>:
Neil Mitchell wrote:
- Larger memory footprint
You are talking about GHC, not Haskell. Take a look at nhc98, which has a small memory footprint.
I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language.
- Little integration with GUI tools. No "Visual Haskell" or "Borland Haskell" equivalents.
http://www.haskell.org/visualhaskell/ - indeed there is :)
I've never used Visual Haskell, but from the web page two things stand out:
1: Its version 0.0. This is not for production use.
2: Its just a programming environment. The point I was making was about integration with GUI tools. You can't (AFAIK) draw a dialog box and then tie each button to a Haskell function in the IO monad.
- Little integration with databases.
There are quite a few Haskell DB programs, I've never used any, but they do exist.
I have used HSQL, and it does what it does perfectly competently. But it requires a bunch of boilerplate code in the IO monad for every query. There are higher level libraries that build nice type-safe stuff on top of this, but they don't seem to be production strength yet.
Remember that this is not about what Haskell could or should be in the future, its about what Haskell is right now. If you start a Haskell development project then this is the reality that you face.
Now, we could try to fix these "deficiencies". That means playing catch-up with the entire infrastructure that has been erected around conventional languages. We will simply never succeed. Sure, we can probably do it with a 10th the manpower of the conventional languages, but they have 100 times our manpower to throw at the problem.
Or we can play to our strengths by looking for markets where the negatives don't matter, or matter less than the positives. Haskell offers a value proposition that is very different to conventional languages. There is likely to be a market out there that is poorly served by conventional languages, but where Haskell will fit very nicely. All we have to do is find it and target it.
Hmmm. I wonder about simulation and testing. Some time ago I asked here about doing discrete event simulation, and I have succeeded. (Unfortunately the resulting code is owned by my employer, so I can't share it). QuickCheck has shown a new approach to testing. Testing of stateful stuff using this approach would require a simulation of the thing to be tested. This might be a winning proposition.
Paul. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Paul Johnson wrote:
I've never used Visual Haskell, but from the web page two things stand out:
1: Its version 0.0. This is not for production use.
Also: "You may not use or distribute this Software or any derivative works in any form for commercial purposes."
Visual Haskell is now with BSD license and it is open sourced. See http://darcs.haskell.org/vshaskell/ Cheers, Krasimir 2006/3/28, Ashley Yakeley <ashley@semantic.org>:
Paul Johnson wrote:
I've never used Visual Haskell, but from the web page two things stand out:
1: Its version 0.0. This is not for production use.
Also: "You may not use or distribute this Software or any derivative works in any form for commercial purposes."
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
participants (14)
-
ajb＠spamcop.net -
Ashley Yakeley -
Davor Cubranic -
dons＠cse.unsw.edu.au -
Dusan Kolar -
Immanuel Litzroth -
Johannes Waldmann -
John Hughes -
Krasimir Angelov -
Malcolm Wallace -
Paul Johnson -
Robert Dockins -
Sebastian Sylvan -
Shae Matijs Erisson