Re: [Haskell-cafe] What *not* to use Haskell for
(1) Function as a system of N concurrent inputs and 1 output is easy essence. How about function as N concurrent inputs and M concurrent outputs? I think it's not native to lambda calculus. So system's programming (if we ever had such paradigm) would solve this issue, while criticizing all FP. (2) For me, I hope this category (What *not* to use Haskell for) won't include SOA. That's what I'am currently trying to decide. (3) I think if CPU's would be lambda-based, not imperative, and paradigm be stronger, most of the why *not* to use Haskell's would be solved, and imperative would be in opposition instead.. with it's enthusiasts. =) They would have good answers for your question. -- View this message in context: http://www.nabble.com/What-*not*-to-use-Haskell-for-tp20436980p20755239.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
I've been using HSH with good results for sysadmin tasks, and recently uploaded HSHHelpers to hackage. Of course with Cpan a lot of stuff has already been done for you, but that's a library issue. Nothing beats bash for a quicky of course, but there a lot of ways to shoot yourself in the foot (eg global variables, hard to remember quoting rules) that haskell protects me from. Like perl protects you, but better. thomas. 2008/11/12 wren ng thornton [EMAIL PROTECTED]: Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) With the appropriate caveats about particular subdomains (see final paragraph), I wouldn't use Haskell for scripting. That is, (1) for Bash-style programming where 95% of the code is just invoking *nix jobs, or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often used. Re #1: Honestly, I don't see anything other than a dedicated competitor being able to unseat Bourne/Bash at this task. Certainly a competitor would have much room for improvement-- what with being able to replace string-rewriting semantics with term-rewriting semantics, vastly improving type safety and catching innumerable bugs. However, with unsavory frequency, it is exactly those type-unsafe substitutions which can make shell scripting cleaner and more direct than a type-safe alternative. Having type safety as well as this sort of non-compositional structure would take a good deal of work to get right. Re #2: People often complain about spooky Perl that uses things like implicit $_ or other hidden variables. While these constructs can make any sizable project unmaintainable, for the quick and dirty jobs they're just what's needed to get things done with clarity. While ByteString code using regexes is just as fast in Haskell, it's often more than twice as long as the Perl, Sed, or Awk equivalents because many of the basic control structures (like Perl's -n, -p, -l,... flags) aren't already provided. That said, this isn't necessarily a bad thing for Haskell. Real programming languages often don't do so well in these areas (Perl being the exception), and they don't feel too bad about it. Both varieties of shell scripting are very much of the DSL nature; for programs with a significant amount of actual logic instead of mere plumbing or regexing, Haskell can certainly outshine these competitors. On the one hand, C and friends fight dirty and much work has been done so Haskell can join in on the bit-bashing glory. However, shell scripting is a whole different kind of imperative muck and very little work (that I've seen) has tried to get Haskell to jump down in the sewers with them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dan Piponi schrieb: Real time audio applications are top of my list of crazy projects I would work on if I had a month spare. I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. -- Dan On Tue, Nov 11, 2008 at 7:41 PM, sam lee [EMAIL PROTECTED] wrote: I haven't found multitrack audio recording applications written in Haskell. These are usually written in C++ using Jack audio or ASIO. This probably means that it is not a good idea to write real time audio applications in Haskell at the moment. So, probably avoid writing applications that use a high frequency timer and IO that should be synchronous to the timer in Haskell. I do real time audio processing based on lazy storable vectors, however I do not plan to implement another GUI driven program but want to program audio algorithms and music in Haskell. http://www.haskell.org/haskellwiki/Synthesizer Although I can do some processing in real-time I don't approach the speed of say SuperCollider so far. I must rely on GHC's optimizer and sometimes it does unexpected things. I know that one of Paul Hudak's students is working on something similar, called HasSound. The DSL approach is already implemented for CSound in Haskore (again there is also a not yet published library which encapsulates this functionality) and you can also do real time sound processing by controlling SuperCollider: http://www.haskell.org/haskellwiki/SuperCollider See also: http://www.haskell.org/haskellwiki/Category:Music ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dan Piponi wrote: On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin [EMAIL PROTECTED] wrote: In other words, Haskell is an excellent language for designing special-purpose compilers and interpretters for custom languages. ;-) If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be tempted to try it myself... You could generate assembly language instructions directly. Yeah. I figure if I knew enough about this stuff, I could poke code numbers directly into RAM representing the opcodes of the machine instructions. Then I only need to figure out how to call it from Haskell. It all sounds pretty non-trivial if you ask me though... ;-) [Don't some OS versions implement execution-prevention? Presumably you'd also have to bypass that in some platform-dependent way too...] But if you use the Haskell LLVM bindings your generated code will be (1) platform independent and (2) optimised. I think there's a cool project lurking there. Never heard of LLVM, but from the Wikipedia description it sound like warm trippy goodness. Pitty there's no Haddock. :-( [From the build log, it looks like it failed because the build machine doesn't have the LLVM library installed. Is that really necessary just for building the docs?] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Excerpts from Andrew Coppin's message of Fri Nov 14 14:13:01 -0600 2008: Yeah. I figure if I knew enough about this stuff, I could poke code numbers directly into RAM representing the opcodes of the machine instructions. Then I only need to figure out how to call it from Haskell. It all sounds pretty non-trivial if you ask me though... ;-) Save yourself some time: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy Using harpy, you can generate x86 assembly /inside/ your code and execute it, using a DSL. This makes it excellent for code generators and playing around with code generation. Here's a calculator I wrote using it: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/calc For more information, http://uebb.cs.tu-berlin.de/harpy/ Never heard of LLVM, but from the Wikipedia description it sound like warm trippy goodness. Pitty there's no Haddock. :-( It's a pretty excellent little system, to be honest. One of the cleanest APIs I've ever used, too (especially for C++.) [From the build log, it looks like it failed because the build machine doesn't have the LLVM library installed. Is that really necessary just for building the docs?] It's necessary to even get through the 'cabal configure' step, since the configure script bundled with the haskell llvm bindings is run then, which checks for the llvm-c headers. Austin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
People have been admitting to using Haskell like that for quite a while now. I think it's an excellent use of Haskell as a DSEL host. -- Lennart On Thu, Nov 13, 2008 at 12:40 AM, [EMAIL PROTECTED] wrote: G'day all. Quoting Tom Hawkins [EMAIL PROTECTED]: Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Bingo! And thanks for someone for admitting that they do this. :-) Hard real-time applications is a huge area, and not all of the code that you write is code that ends up running on the target. Generally, in DSL/MDD-style development, not very much of the code that you write ends up running on the target. In some cases, _none_ of the code you write ends up running on the target. Haskell is almost ideal for tasks like this. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Real time audio applications are top of my list of crazy projects I would work on if I had a month spare. I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. -- Dan On Tue, Nov 11, 2008 at 7:41 PM, sam lee [EMAIL PROTECTED] wrote: I haven't found multitrack audio recording applications written in Haskell. These are usually written in C++ using Jack audio or ASIO. This probably means that it is not a good idea to write real time audio applications in Haskell at the moment. So, probably avoid writing applications that use a high frequency timer and IO that should be synchronous to the timer in Haskell. On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton [EMAIL PROTECTED] wrote: Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) With the appropriate caveats about particular subdomains (see final paragraph), I wouldn't use Haskell for scripting. That is, (1) for Bash-style programming where 95% of the code is just invoking *nix jobs, or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often used. Re #1: Honestly, I don't see anything other than a dedicated competitor being able to unseat Bourne/Bash at this task. Certainly a competitor would have much room for improvement-- what with being able to replace string-rewriting semantics with term-rewriting semantics, vastly improving type safety and catching innumerable bugs. However, with unsavory frequency, it is exactly those type-unsafe substitutions which can make shell scripting cleaner and more direct than a type-safe alternative. Having type safety as well as this sort of non-compositional structure would take a good deal of work to get right. Re #2: People often complain about spooky Perl that uses things like implicit $_ or other hidden variables. While these constructs can make any sizable project unmaintainable, for the quick and dirty jobs they're just what's needed to get things done with clarity. While ByteString code using regexes is just as fast in Haskell, it's often more than twice as long as the Perl, Sed, or Awk equivalents because many of the basic control structures (like Perl's -n, -p, -l,... flags) aren't already provided. That said, this isn't necessarily a bad thing for Haskell. Real programming languages often don't do so well in these areas (Perl being the exception), and they don't feel too bad about it. Both varieties of shell scripting are very much of the DSL nature; for programs with a significant amount of actual logic instead of mere plumbing or regexing, Haskell can certainly outshine these competitors. On the one hand, C and friends fight dirty and much work has been done so Haskell can join in on the bit-bashing glory. However, shell scripting is a whole different kind of imperative muck and very little work (that I've seen) has tried to get Haskell to jump down in the sewers with them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dan Piponi wrote: Real time audio applications are top of my list of crazy projects I would work on if I had a month spare. I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. In other words, Haskell is an excellent language for designing special-purpose compilers and interpretters for custom languages. ;-) If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be tempted to try it myself... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
andrewcoppin: Dan Piponi wrote: Real time audio applications are top of my list of crazy projects I would work on if I had a month spare. I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. In other words, Haskell is an excellent language for designing special-purpose compilers and interpretters for custom languages. ;-) If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be tempted to try it myself... No need, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy Well, you still should probably know something of what you're doing.. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Thu, Nov 13, 2008 at 11:08 AM, Andrew Coppin [EMAIL PROTECTED] wrote: In other words, Haskell is an excellent language for designing special-purpose compilers and interpretters for custom languages. ;-) If I knew a damned thing about IA32 assembly and dynamic linkage, I'd be tempted to try it myself... You could generate assembly language instructions directly. But if you use the Haskell LLVM bindings your generated code will be (1) platform independent and (2) optimised. I think there's a cool project lurking there. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
G'day all. Quoting Lennart Augustsson [EMAIL PROTECTED]: People have been admitting to using Haskell like that for quite a while now. I think it's an excellent use of Haskell as a DSEL host. DSL is a proper superset of DSEL. Just saying. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Don Stewart [EMAIL PROTECTED] writes: Data.ByteString is full of mutation-heavy inner loops. I suspect you are missing Kyle's point, which I interpret to be more like what Paul Graham talks about in ANSI Common Lisp: [OO] provides a structured way to write spaghetti code. [...] For programs that would have ended up as spaghetti anyway, the object oriented model is good: they will at least be structured spaghetti. In my opinion, Haskell is pretty bad at spaghetti. And although it is possible that some programs simply need to be spaghetti-structured, I still think not supporting it is a good thing - Haskell should instead provide the tools for writing an equivalent non-spaghettized program. Bytestrings have mutation-heavy inner loops, but localized, well-structured, and exporting a neat, pure interface, so they don't count here. There's nothing magic about it. Now you're just being modest. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Anatoly Yakovenko [EMAIL PROTECTED] wrote: Has there been any progress in getting ghc set up for porting to non x86/unix/windows platforms? Can it generate ropi code? It would also be nice to be able to compile to C that rvct/arm tools can compile in thumb mode. AFAIK, you can bootstrap ghc onto lots of non-PC-centric platforms, using the unregisterized porting guide. However, it is not a trivial exercise, and it does not address the question of setting ghc up as a cross-compiler, should your device be too small to host ghc at all. Other Haskell compilers might be a better starting point. For instance, nhc98 uses portable C as a target language, and has a configure-time option to set it up as a cross-compiler. See http://www.cs.york.ac.uk/fp/nhc98/install.html (cross-compiler info towards the bottom of the page). The example given is for ARM/linux. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Hi Reinier, On Wed, Nov 12, 2008 at 14:22, Reinier Lamers [EMAIL PROTECTED] wrote: Also, in my experience Haskell is not so good at data structures where you can't do structural recursion easily, like graphs. In such cases you want a language with easy pointers and destructive updates. You can do those things in pure Haskell by using the ST monad, but the code will be more verbose than in Java or C++, and it will occasionally drive you insane with type messages like the above (You thought you could use '$' freely instead of application? Wrong!). Can you give examples of what you mean and why algebraic data types are not sufficient? In my research most things are structurally recursive and it was because Haskell is so good at such things that I started using it. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
2008/11/11 Dave Tapley [EMAIL PROTECTED]: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Let's say something controversial: I think that Haskell's type system gets in your way when you're writing one-shot scripts that don't need to conform to the highest correctness standards. Imagine typing a command at the shell prompt and getting the sort of abstract error message that Haskell compilers give every now and then, like: whyerror.lhs:36:25: Ambiguous type variable `a' in the constraint: `Arrow a' arising from use of `' at whyerror.lhs:36:25-27 Possible cause: the monomorphism restriction applied to the following: liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b b1 - a b c (bound at whyerror.lhs:36:1) unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c (bound at whyerror.lhs:34:1) split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction You don't want to be bothered by such monstrosities (yes, they are, even though many of you may not see it because of years of conditioning) when you're just hacking up a simple script to make a catalog of your MP3 collection / check for patterns in log files / whatever. Also, in my experience Haskell is not so good at data structures where you can't do structural recursion easily, like graphs. In such cases you want a language with easy pointers and destructive updates. You can do those things in pure Haskell by using the ST monad, but the code will be more verbose than in Java or C++, and it will occasionally drive you insane with type messages like the above (You thought you could use '$' freely instead of application? Wrong!). Regards, Reinier ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
tux_rocker: 2008/11/11 Dave Tapley [EMAIL PROTECTED]: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Let's say something controversial: I think that Haskell's type system gets in your way when you're writing one-shot scripts that don't need to conform to the highest correctness standards. Imagine typing a command at the shell prompt and getting the sort of abstract error message that Haskell compilers give every now and then, like: whyerror.lhs:36:25: Ambiguous type variable `a' in the constraint: `Arrow a' arising from use of `' at whyerror.lhs:36:25-27 Possible cause: the monomorphism restriction applied to the following: liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b b1 - a b c (bound at whyerror.lhs:36:1) unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c (bound at whyerror.lhs:34:1) split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction You don't want to be bothered by such monstrosities (yes, they are, even though many of you may not see it because of years of conditioning) when you're just hacking up a simple script to make a catalog of your MP3 collection / check for patterns in log files / whatever. Why are you using Arrows in your one shot scripts? Do you use Arrows in your shell scripts? Seems like a strawman argument.. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Wed, 2008-11-12 at 10:50 -0800, Don Stewart wrote:
tux_rocker:
2008/11/11 Dave Tapley [EMAIL PROTECTED]:
So I should clarify I'm not a troll and do see the Haskell light. But
one thing I can never answer when preaching to others is what does
Haskell not do well?
Let's say something controversial: I think that Haskell's type system
gets in your way when you're writing one-shot scripts that don't need
to conform to the highest correctness standards. Imagine typing a
command at the shell prompt and getting the sort of abstract error
message that Haskell compilers give every now and then, like:
whyerror.lhs:36:25:
Ambiguous type variable `a' in the constraint:
`Arrow a' arising from use of `' at whyerror.lhs:36:25-27
Possible cause: the monomorphism restriction applied to the
following:
liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b
b1 - a b c
(bound at whyerror.lhs:36:1)
unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c
(bound at whyerror.lhs:34:1)
split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1)
Probable fix: give these definition(s) an explicit type signature
or use -fno-monomorphism-restriction
You don't want to be bothered by such monstrosities (yes, they are,
even though many of you may not see it because of years of
conditioning) when you're just hacking up a simple script to make a
catalog of your MP3 collection / check for patterns in log files /
whatever.
Why are you using Arrows in your one shot scripts?
Because a generic operator like () is
a) More likely to exist, and
b) easier to remember
than a special case operator like --- actually, I don't think GHC does
come with a standard version of () type-specialized to functions,
only a version of (). Or if it does, I can't remember it.
Do you use Arrows in
your shell scripts?
I use pipelines. Frequently. I even type them up at the command line.
Beyond that, I was considering the pipeline
uses -l snippet_calculate\\b |
perl -lne 'chomp; print $_ unless qx{svn st | grep $_}'
(`uses' is a recursive grep-like shell function I have). The use of
perl immediately suggested that it could profitably be re-written in
Haskell (actually, in a similar FP language I've been designing --- not
relevant); my translation included a line something like
interactiveM $ filterM $ comp \ x - translation of qx{svn st |
grep $x}
So yeah, I use arrows in my shell scripts. Who doesn't?
(On the other hand, I'm actively designing an FP shell-like language...)
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Anything with hard performance requirements, and/or that needs to run on tiny computational resources (CPU speed, RAM size, etc.) I'd say device drivers too, except that the House guys apparently managed to do this... I'd really love to tell everybody that Haskell is *the* language of algorithms - except that it tends to not be very performant. Unfortunately, with the current state of the art, high-performance computer programs still require lots of low-level details to be explicitly managed. Hopefully one day this will cease to be the case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Tue, Nov 11, 2008 at 5:18 AM, Jules Bean [EMAIL PROTECTED] wrote: Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? GHC's scheduler lacks any hard timeliness guarantees. Thus it's quite hard to use haskell in realtime or even soft-realtime environments. Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Thanks to this great language, we traded 100K lines of Simulink for 3K lines of Haskell. Our current program is planned to hit the production lines in a few months. With similar methods, Haskell is also a great language for ASIC and FPGA design. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
andrewcoppin: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Anything with hard performance requirements, and/or that needs to run on tiny computational resources (CPU speed, RAM size, etc.) I'd say device drivers too, except that the House guys apparently managed to do this... I'd really love to tell everybody that Haskell is *the* language of algorithms - except that it tends to not be very performant. Depends on who's writing the Haskell in my experience. GHC's a perfectly capable compiler if you feed it the proper diet. -- Don (Board member of the Don't think linked lists are the same as UArr Double movement) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
G'day all. Quoting Tom Hawkins [EMAIL PROTECTED]: Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Bingo! And thanks for someone for admitting that they do this. :-) Hard real-time applications is a huge area, and not all of the code that you write is code that ends up running on the target. Generally, in DSL/MDD-style development, not very much of the code that you write ends up running on the target. In some cases, _none_ of the code you write ends up running on the target. Haskell is almost ideal for tasks like this. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
--- On Tue, 11/11/08, Dave Tapley [EMAIL PROTECTED] wrote: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? 'Hard' real-time applications? I don't know that there couldn't be a 'real-time friendly' Haskell, but for some applications, the unpredictability (however slight) of when, for example, garbage collection happens, or how long it takes, is unacceptable. (Even the unpredictability of heap allocation/deallocation a la malloc/free is unacceptable for some real time apps). Haskell is in the same boat here with lots of other languages, of course. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Jules Bean [EMAIL PROTECTED] wrote: GHC's scheduler lacks any hard timeliness guarantees. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. Actually, I would say it is much worse than that. It is not merely a question of implementation. We do not have _any_ predictable theory of resource usage (time, memory) for a lazy language. There is no analysis (yet) which can look at an arbitrary piece of Haskell code and tell you how long it will take to execute, or how much heap/stack it will eat. What is more, it is very hard to do that in a modular way. The execution time of lazy code is entirely dependent on its usage/demand context. So you can't just apply WCET to single functions, then combine the results. It's a question I'd love to be able to solve, but I note that those who are currently working on predictable execution of functional languages (e.g. the Hume project) have already ditched laziness in favour of eager execution. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Malcolm Wallace wrote: Jules Bean [EMAIL PROTECTED] wrote: GHC's scheduler lacks any hard timeliness guarantees. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. Actually, I would say it is much worse than that. It is not merely a question of implementation. We do not have _any_ predictable theory of resource usage (time, memory) for a lazy language. There is no analysis (yet) which can look at an arbitrary piece of Haskell code and tell you how long it will take to execute, or how much heap/stack it will eat. What is more, it is very hard to do that in a modular way. The execution time of lazy code is entirely dependent on its usage/demand context. So you can't just apply WCET to single functions, then combine the results. That's true but I'm not sure you need to solve that (hard, interesting) problem just to get *some* kind of timeliness guarantees. For example the guarantee that a thread is woken up within 10us of the MVar it was sleeping on being filled doesn't require you to solve the whole problem. It requires you to be able to bound GC time, or preempt the GC, but that's feasible isn't it? Then there is the possibility of a strict DSL (probably but not necessarily a Monad) within haskell which has strong timeliness guarantees. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
You can hire one Haskell programmer instead of 1,2,3... programmers in your favorite imperative language. On Tue, Nov 11, 2008 at 12:32 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi all, On Tue, Nov 11, 2008 at 11:38, Dave Tapley [EMAIL PROTECTED] wrote: Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) I would not use Haskell if I were faced with the prospect of producing a huge system in short time (i.e. meaning I couldn't do it by myself) and all I had was a pool of regular programmers that have been trained in .NET, Java, C++, Python, your favorite imperative language. Yes, sad - but true. I'd very much like to see this twisted to an argument for Haskell :) cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Hi all, On Tue, Nov 11, 2008 at 11:38, Dave Tapley [EMAIL PROTECTED] wrote: Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) I would not use Haskell if I were faced with the prospect of producing a huge system in short time (i.e. meaning I couldn't do it by myself) and all I had was a pool of regular programmers that have been trained in .NET, Java, C++, Python, your favorite imperative language. Yes, sad - but true. I'd very much like to see this twisted to an argument for Haskell :) cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Tue, Nov 11, 2008 at 14:37, Krasimir Angelov [EMAIL PROTECTED] wrote: You can hire one Haskell programmer instead of 1,2,3... programmers in your favorite imperative language. That's assuming I can find a Haskell programmer in the first place. Also, he/she has to be good to replace 10 other programmers. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What *not* to use Haskell for
Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
consalus: On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley [EMAIL PROTECTED] wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] What *not* to use Haskell for
Hello Don, Wednesday, November 12, 2008, 12:51:10 AM, you wrote: Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? not I/O, but IO :) btw, i use C++ for speed-critical code (compression encryprion) and Haskell/GHC for everything else in my FreeArc project (it has 19k downloads ATM). i also plan to switch to C# for GUI part since gtk2hs provides less features, less documented, les debugged, doesn't have IDE and my partner doesnt know Haskell :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart [EMAIL PROTECTED] wrote: consalus: On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley [EMAIL PROTECTED] wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? -- Don Of course, with a lot of skill, good design, and a pile of language extensions state/io-heavy Haskell code can be clean and flexible. Performance can be pretty good, and for complex algorithmic code arguably a better choice than most other languages. Still, neither of the projects you reference (to my knowledge) have a mutation-heavy inner computation loop. XMonad does all of its mutation in a custom monad that is ReaderT StateT IO or something similar, and it apparently works beautifully. However, my understanding is that stack of monad transformers tend not to be particularly efficient, and while that usually isn't an issue, the case that I'm talking about is that where mutation performance is a major concern. Other languages offer similar expressive power, minus the joys of laziness and referential transparency. Persistent data structures are great, but if you're not using the persistence it is less convenient and less efficient. So again, Haskell _can_ do mutation and IO just fine, but if laziness, purity, and immutability will be the rare exception rather than the rule, might be easier to use a language that makes strictness and impurity easier. (Unless you're a Haskell guru, in which case I imagine Haskell is always the most convenient language to use). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) GHC's scheduler lacks any hard timeliness guarantees. Thus it's quite hard to use haskell in realtime or even soft-realtime environments. This is probably not a fundamental problem with haskell. It's a problem with the compiler/RTS which we happen to be using. It may be true that it's harder to write an RTS with realtime guarantees but I doubt it's impossible. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
consalus: On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart [EMAIL PROTECTED] wrote: consalus: On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley [EMAIL PROTECTED] wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? -- Don Of course, with a lot of skill, good design, and a pile of language extensions state/io-heavy Haskell code can be clean and flexible. Performance can be pretty good, and for complex algorithmic code arguably a better choice than most other languages. Still, neither of the projects you reference (to my knowledge) have a mutation-heavy inner computation loop. Data.ByteString is full of mutation-heavy inner loops. There's nothing magic about it. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Has there been any progress in getting ghc set up for porting to non x86/unix/windows platforms? Can it generate ropi code? It would also be nice to be able to compile to C that rvct/arm tools can compile in thumb mode. Its whats stopping me from trying to use it for mobile development. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Kyle, I would say that most apps don't actually require that you write a mutation heavy inner loop. They can be written either way, and Haskell gives you the facility to do both. Even my field, which is visualization can be written either way. I write with a mutation heavy inner loop myself, because it's how I started out, and I haven't had any trouble with performance. OpenGL is always my upper bound. Even 2D code, which I've written on occasion seems not to suffer. On Tue, Nov 11, 2008 at 5:23 PM, Kyle Consalus [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart [EMAIL PROTECTED] wrote: consalus: On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley [EMAIL PROTECTED] wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? -- Don Of course, with a lot of skill, good design, and a pile of language extensions state/io-heavy Haskell code can be clean and flexible. Performance can be pretty good, and for complex algorithmic code arguably a better choice than most other languages. Still, neither of the projects you reference (to my knowledge) have a mutation-heavy inner computation loop. XMonad does all of its mutation in a custom monad that is ReaderT StateT IO or something similar, and it apparently works beautifully. However, my understanding is that stack of monad transformers tend not to be particularly efficient, and while that usually isn't an issue, the case that I'm talking about is that where mutation performance is a major concern. Other languages offer similar expressive power, minus the joys of laziness and referential transparency. Persistent data structures are great, but if you're not using the persistence it is less convenient and less efficient. So again, Haskell _can_ do mutation and IO just fine, but if laziness, purity, and immutability will be the rare exception rather than the rule, might be easier to use a language that makes strictness and impurity easier. (Unless you're a Haskell guru, in which case I imagine Haskell is always the most convenient language to use). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Go Haskell! (was: [Haskell-cafe] What *not* to use Haskell for)
Do you have an example of a mutable state/ IO bound application, like, hmm, a window manager or a revision control system or a file system...? If you're looking for a challenge, how about this one (there used to be lots of Haskellers into this game, any of you still around?-): http://computer-go.org/pipermail/computer-go/2008-October/016680.html The specification is the numbered list at the end of the message, or in the zip file with the Java example implementation (README). Actually, the interesting part from a performance perspective doesn't even require GTP or AMAF, just implement the random legal playouts for a 9x9 board, do a loop over them, keeping some basic win/loose/game length statistics. Can you complete that in competitive speed, preferably from the specs, without just transliterating the low-level Java code? I won't tell you yet what typical playouts-per-second-per-core numbers are floating about for lightly optimised code; try to improve your code and say stop, this is good enough before comparing with the Java bot runtimes. You'll probably have no room left for any high-level operations, ending up with mostly imperatively threaded array manipulations in a loop that is expected to be run several thousand times per real-game move (the idea being to run lots of dumb, but legal, simulations to the end, where evaluation is easy, gather statistics, then choose the move that seems to have the most potential). Bonus points if you can preserve any of the high-level advantages of working in Haskell (such as easy debuggability, because there will be bugs, especially if you can't afford to maintain redundant information representations) without sacrificing speed. (*) As specified, the bot won't win any tournaments - it is the starting point (or remote ancestor) for the current champions, with lots of room for algorithmic improvement, not to mention actual game knowledge, tree search and parallelization (the configurations being used for tournaments and exhibition games are highly parallel). The reference spec is a recent effort, meant to provide a first milestone for aspiring Go programmers to compare their code against, while also inviting programmers to to show how their favourite language is eminently suitable for Go programming (without sacrificing performance!). There are versions in Java, D, C++, C#, and C around somewhere, possibly others. But: please, no language evangelism on that mailing list! Those people seem decent, peaceful and open-minded (there's even a Haskell spec of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ). And some of them have years (a few even decades) of experience, much of which is made available in the mailinglist archives and bibliography (pointers available on request - if you wanted to get serious about playing with Go programming, you'd be expected to mine the archives and bibliography, because just about anything you'll come up with in your first few months will have been discussed already;-), in spite of commercial interests and ongoing competitions. They are already tired and wary of useless language wars (who isn't?). Claus (who has been wanting to write a Go player ever since he had to decide between research and learning more Go, either one trying to eat all available time and then some; perhaps I should write a researcher instead, and return to playing Go?-) (*) it would be nice if the sequential baseline performance of functional Haskell/Ghc arrays would be better, btw; that would make the ongoing work on parallel arrays much more interesting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Hi again, On Tue, Nov 11, 2008 at 11:38, Dave Tapley [EMAIL PROTECTED] wrote: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? C does extremely well when you want to write low level exploits, such as meddling with memory, the machine stack and others. This goes also for writing device drivers, media codecs, compression algorithms etc. and applications that are mostly about copying bits (with some transformations) between various memory locations. I imagine this kind of thing would be very hard to write in Haskell. Does that count? cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) With the appropriate caveats about particular subdomains (see final paragraph), I wouldn't use Haskell for scripting. That is, (1) for Bash-style programming where 95% of the code is just invoking *nix jobs, or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often used. Re #1: Honestly, I don't see anything other than a dedicated competitor being able to unseat Bourne/Bash at this task. Certainly a competitor would have much room for improvement-- what with being able to replace string-rewriting semantics with term-rewriting semantics, vastly improving type safety and catching innumerable bugs. However, with unsavory frequency, it is exactly those type-unsafe substitutions which can make shell scripting cleaner and more direct than a type-safe alternative. Having type safety as well as this sort of non-compositional structure would take a good deal of work to get right. Re #2: People often complain about spooky Perl that uses things like implicit $_ or other hidden variables. While these constructs can make any sizable project unmaintainable, for the quick and dirty jobs they're just what's needed to get things done with clarity. While ByteString code using regexes is just as fast in Haskell, it's often more than twice as long as the Perl, Sed, or Awk equivalents because many of the basic control structures (like Perl's -n, -p, -l,... flags) aren't already provided. That said, this isn't necessarily a bad thing for Haskell. Real programming languages often don't do so well in these areas (Perl being the exception), and they don't feel too bad about it. Both varieties of shell scripting are very much of the DSL nature; for programs with a significant amount of actual logic instead of mere plumbing or regexing, Haskell can certainly outshine these competitors. On the one hand, C and friends fight dirty and much work has been done so Haskell can join in on the bit-bashing glory. However, shell scripting is a whole different kind of imperative muck and very little work (that I've seen) has tried to get Haskell to jump down in the sewers with them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
I haven't found multitrack audio recording applications written in Haskell. These are usually written in C++ using Jack audio or ASIO. This probably means that it is not a good idea to write real time audio applications in Haskell at the moment. So, probably avoid writing applications that use a high frequency timer and IO that should be synchronous to the timer in Haskell. On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton [EMAIL PROTECTED] wrote: Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) With the appropriate caveats about particular subdomains (see final paragraph), I wouldn't use Haskell for scripting. That is, (1) for Bash-style programming where 95% of the code is just invoking *nix jobs, or (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often used. Re #1: Honestly, I don't see anything other than a dedicated competitor being able to unseat Bourne/Bash at this task. Certainly a competitor would have much room for improvement-- what with being able to replace string-rewriting semantics with term-rewriting semantics, vastly improving type safety and catching innumerable bugs. However, with unsavory frequency, it is exactly those type-unsafe substitutions which can make shell scripting cleaner and more direct than a type-safe alternative. Having type safety as well as this sort of non-compositional structure would take a good deal of work to get right. Re #2: People often complain about spooky Perl that uses things like implicit $_ or other hidden variables. While these constructs can make any sizable project unmaintainable, for the quick and dirty jobs they're just what's needed to get things done with clarity. While ByteString code using regexes is just as fast in Haskell, it's often more than twice as long as the Perl, Sed, or Awk equivalents because many of the basic control structures (like Perl's -n, -p, -l,... flags) aren't already provided. That said, this isn't necessarily a bad thing for Haskell. Real programming languages often don't do so well in these areas (Perl being the exception), and they don't feel too bad about it. Both varieties of shell scripting are very much of the DSL nature; for programs with a significant amount of actual logic instead of mere plumbing or regexing, Haskell can certainly outshine these competitors. On the one hand, C and friends fight dirty and much work has been done so Haskell can join in on the bit-bashing glory. However, shell scripting is a whole different kind of imperative muck and very little work (that I've seen) has tried to get Haskell to jump down in the sewers with them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
At Tue, 11 Nov 2008 22:41:48 -0500, sam lee wrote: I haven't found multitrack audio recording applications written in Haskell. These are usually written in C++ using Jack audio or ASIO. This probably means that it is not a good idea to write real time audio applications in Haskell at the moment. There are at least two Haskell bindings to JACK. I wrote one of them. The big issue is (no surprise) garbage collection. Audio stuff can generate a lot of garbage fast if you aren't careful. And the stop-the-world collection can happen at unfortunate times. The uvector library might help things -- but ultimately Haskell would need a more realtime friendly garbage collector. So, realtime audio can be done in Haskell today, but is is definitely fragile at best. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On 11 nov 2008, at 11:38, Dave Tapley wrote: Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Working with relational databases can be a bit cumbersome. There's some bitrot in the HaskellDB packages in general, so taking a more low- level approach seems sensible, but because the lack of extensible records you don't get much help from the compiler, so you need to do most of the checking (and 'marshalling') yourself. In that sense, it's not worse than doing it with most other languages, except that for those languages there are often high-level libraries available to do, for example, cute things like object relational mapping (ORM). -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
