> this IRC conversation on my page should be instructive (I am "rindolf" there).
PERL folks bashing on Haskell in #perl is instructive? I think your a tad under the bar.
> Essentially, even an elegant dinky "log analyser" that people showed me how to write properly using ghc segfaulted.
On a practical level: this isn't helpful without a version of GHC, platform information, and a copy of the progrma that was "properly written". On a theoretical level: this says nothing about the language.
> As much as I like Haskell, I still think the language has many inherent limitations due to its restrictive design decisions
There are many design decisions I'd happily question - but I wouldn't call those ones limiting. Which ones are you referring to?
> and ghc still has many bugs
True! But its been a while since I've been caught by a segfault.
> and is a huge memory hog
Are you saying your programs are huge memory hogs? The compilation process takes too much memory? Perhaps you are claiming "all" or "too many" progrmas use unnecessary amounts of memory? If your claim is either of the second two I must disagree. I've built many memory friendly programs, but it does take a little more skill to predict the memory use than most people think it should.
> Someone I talked with on IRC, said he'd like to create an alternative operating system written in Haskell
Hundreds of them out there (alternative OSes) and Haskell is fun to play with. I'd like to do this too. His lack of care about POSIX doesn't say anything about the language or the tool - so I'm not sure what you're getting at there or if you're just going on a tangent.
> The kernel developers are likely to reject Haskell modules
Upstreaming was never a goal - oh, that would be a headache without any reward!
Posted Sep 27, 2009 7:25 UTC (Sun) by shlomif (subscriber, #11299)
[Link]
Essentially, even an elegant dinky "log analyser" that people showed me how to write properly using ghc segfaulted.
On a practical level: this isn't helpful without a version of GHC, platform information, and a copy of the progrma that was "properly written". On a theoretical level: this says nothing about the language.
Here is the Haskell program in all its glory - I lost the original one, but people on #haskell have recreated a mostly equivalent one:
import System.Environment
import Data.List
main = do [infile,outfile] <- System.Environment.getArgs
text <- readFile infile
writeFile outfile . unlines . map (\xs -> (show (length xs)) ++ "\t" ++ head xs) . group . sort . words $ text
This program no longer segfaults (even though I recall it segfaulting), but it consumes 38.3% of my 2.5 GB of RAM (I still remember my first 20 MB hard-disk), and takes a long time to run. On the other hand, the equivalent Perl program consumes less than 2% of my RAM and finishes faster:
#!/usr/bin/perl
use strict;
use warnings;
my %hash;
open my $in, "<", "FreeNode-#perlcafe.log"
or die "Could not open - $!";
while (my $l = <$in>)
{
chomp($l);
foreach my $word (split (/ +/, $l))
{
$hash{$word}++;
}
}
close($in);
open my $out, ">", "analysis-perl.txt"
or die "Could not open for writing - $!";
while (my ($word, $occurs) = each(%hash))
{
print {$out} "$occurs\t$word\n";
}
close($out);
As much as I like Haskell, I still think the language has many inherent limitations due to its restrictive design decisions
There are many design decisions I'd happily question - but I wouldn't call those ones limiting. Which ones are you referring to?
The very strong typing, the lazy-only evaluation, the lack of assignment. All of these are essential cornerstones of Haskell, yet result in under-performing code when put together.
Writing kernel modules in Haskell
Posted Oct 7, 2009 17:53 UTC (Wed) by TomMD (guest, #56998)
[Link]
1) You are comparing different algorithms.
Your algorithms for these two program are entirely different. Your Perl program will take one word, modify a map of counters, and then process the next word - a constant space algorithm. This is entirely doable in Haskell but you have decided not to. Instead, you read in the entire file, sort the words, group them, and count the resulting list lengths, requiring O(n) memory (actually more, given that you are sorting).
2) You are using linked lists of linked lists for processing
Anyone serious about time and space would be using packed strings, from the bytestring package.
The first issue seems especially obvious, making me think this is done on purpose. Please don't troll on LWN.