RE: [Haskell] Haskell as a disruptive technology?
Hi, I had to chuckle at this one in particular, since the implementation of transactions in Haskell was based on experiences with prototype software TM in Java and C#! In truth, Haskell adds a few things to the mix that make STM dramatically better. Most important are STM and STRef---it's no longer possible to accidentally commingle transactional and non-transactional access to the same storage, or to do I/O in the middle of a transaction by mistake. I don't think that the Haskell STM implementation is as closely based on the Java / C# work as it appears... Before Simon Marlow's SMP extensions we relied on there being only a single thread running in an STM operation in the RTS at any time, so the STMCommit operation could run without interference. Even with SMP support, and the possibility of multiple threads in the RTS, we've never aimed for non-blocking progress because we assume that the number of OS threads will be tuned to the number of available cores. As well as the use of the STM monad to separate out IO/tx/non-tx access, I think the big thing that we learnt from the Haskell work was the retry/orElse abstractions for composable blocking. BTW, I've put a copy of another recent STM-Haskell paper online at http://research.microsoft.com/~tharris/drafts/2006-invariants-draft.pdf. It's about defining invariants over transactionally-managed data structures -- feedback's very welcome! Cheers, Tim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On Thu, Mar 30, 2006 at 11:39:34AM +0100, Tim Harris wrote: BTW, I've put a copy of another recent STM-Haskell paper online at http://research.microsoft.com/~tharris/drafts/2006-invariants-draft.pdf. It's about defining invariants over transactionally-managed data structures -- feedback's very welcome! Here is my feedback: great stuff! :-) Best regards Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On 3/27/06, Robert Dockins [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Sorry to have been out of the discussion for so long. I've just upgraded to Fedora Core 5. Multimedia and the proprietary NVidia 3d driver have yet to be added, but at least email is now up. Robert Dockins wrote: 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. Sorry. I really wish I could agree, but I don't. Like I said earlier, it doesn't matter how good your technology is, if you go up against the incumbents you will lose every time. Here is how I see it playing out: 1: People start to complain that effective use of multicore CPUs is very hard. The trade press editorialize on the problem: is this the end of the computer performance revolution. 2: Sun and Microsoft bring out support for STM in Java and C# respectively. The trade press editorialize on this wonderful new technology. Haskell may get a mention as the original prototype, but now its ready for mainstream use. 3: The Java and C# support turns out to be unsafe, partial and inefficient. Long articles are written in the trade press about how to make sure your programs use it properly. Programmers with proven experience in these flavours get big pay rises. 4: We sit around wondering what happened. Its not fair: we had this years ago and done right. Why is everyone using the broken stuff? I've seen this happen before, with Eiffel. From around 1989 I was telling people that Eiffel was the way to go. It was better than C++ in every way, and garbage collection was a great win. Nobody would try Eiffel. They said GC was inefficient, and anyway real programmers didn't need it. Then Java came out, and a couple of years later a project manager who had previously ignored my enthusiasm about Eiffel told me how great it was to have GC in Java, and how few bugs they were getting as a result. I managed a weak smile. Getting good concurrency support on SMP is important, of course. But its not going to beat Java and C++ on their home turf. That is the point of disruptive technologies: they start out in a niche and then spread. First find a niche. One of the lessons Clayton Christensen draws from his study of disruptive technologies is that the market for them is unknown and unknowable. As a rule you don't identify and analyse it, you notice it by accident and have the agility to exploit it. One example from the book: Honda initially tried to sell its motorcycles by competing head-on with incumbents like Harley Davidson. They got nowhere, but when the frustrated marketroids took their sample bikes out on the sand dunes for some fun, friends asked where they could get one. So the marketroids got a few as a favour to their friends. And *their* friends asked for some too, and it eventually dawned on Honda that there was a whole new market for light recreational sport bikes that their model was just right for. So it is with Haskell. I've spent some time looking for niches where Haskell might fit. I've got a couple of ideas (test harnesses and experimental simulations), but if I or anyone else laid out a marketing programme based on those ideas then it would very likely be wrong in some important way. What we need to do is to look for lots of similar sorts of software: marginal opportunities that are poorly served by the big incumbents, but where Haskell can shine. When you find something like that then push Haskell and see if it fits. If you win then spread the word, and get your new converts to do the same *in their speciality*. Then we will be going places. Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On Mar 29, 2006, at 4:28 PM, Paul Johnson wrote: ... 2: Sun and Microsoft bring out support for STM in Java and C# respectively. The trade press editorialize on this wonderful new technology. Haskell may get a mention as the original prototype, but now its ready for mainstream use. I had to chuckle at this one in particular, since the implementation of transactions in Haskell was based on experiences with prototype software TM in Java and C#! In truth, Haskell adds a few things to the mix that make STM dramatically better. Most important are STM and STRef---it's no longer possible to accidentally commingle transactional and non-transactional access to the same storage, or to do I/O in the middle of a transaction by mistake. Without Haskell's support for monadic typing this would have required wholesale reworking of the language implementation. That's the situation most other languages find themselves in. As long as we keep discovering new techniques that fit within the monadic box, Haskell will remain ahead of mainstream languages here. -Jan-Willem Maessen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
[EMAIL PROTECTED] writes: G'day all. Quoting Immanuel Litzroth [EMAIL PROTECTED]: I have created programs that fill an array with the first 100 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: [EMAIL PROTECTED] web : www.enfocus.be *** ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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 [EMAIL PROTECTED]: 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
- 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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Donald Bruce Stewart [EMAIL PROTECTED] 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 100 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: [EMAIL PROTECTED] web : www.enfocus.be *** ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Paul Johnson [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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/ --- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Malcolm Wallace wrote: Paul Johnson [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On 3/27/06, Paul Johnson [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
* 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/ --- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Dusan Kolar [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
Dusan Kolar wrote: Malcolm Wallace wrote: Paul Johnson [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On Mar 27, 2006, at 9:03 AM, Sebastian Sylvan wrote: On 3/27/06, Paul Johnson [EMAIL PROTECTED] 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Haskell as a disruptive technology?
Robert Dockins wrote: 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. I think your enthusiasm outstrips reality a bit here. STM appear to provide a much improved model for concurrent programming on shared memory architectures (I say appears here because I've read the papers but haven't used it). Whilst this applies directly to the limited scalability of new multi-core desktop machines, I don't think it's going to provide huge benefits to the more scalable architectures based upon message passing (eg MPI and Cell). I'd be pleased to be corrected, but I'm not aware of any mainstream haskell libs/extensions that make implementing message passing concurrent systems fundamentally easier than in other languages. Tim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
G'day all. Quoting Immanuel Litzroth [EMAIL PROTECTED]: I have created programs that fill an array with the first 100 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell as a disruptive technology?
On 26/03/06, Paul Johnson [EMAIL PROTECTED] 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.
Re: [Haskell] Haskell as a disruptive technology?
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=partialsumslang=all In general I would say GHC/Haskell was very very fast, as long as you know what you're doing. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
