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. - Cale _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
