> I did a Haskell short course late last year and I challenged the main instructor. I told him "this is all well and good, but I bet I can still make useful software using my practical languages faster than you can". He said no way - using haskell he was convinced he could implement anything I could implement, faster and better and with less code. We didn't test the claim - but I still wonder - is he right?
OK, here's a problem. Read a file of text (the name is to be passed in as a command-line parameter). For each line, if it begins with a number, print out the number.
I'd use Perl, and it would take me one or, at most, two minutes. It would take me seven lines, only because I put my curly braces on their own lines.
Now, I picked a problem that is a better fit for Perl than for Haskell. But that's kind of the point - there are problems that are a better fit for other languages than for Haskell, and when you hit one, you're better off writing the program in a language that fits better.
Haskell is actually one of the greatest text handling languages out there, and will beat Perl5 on most such tasks. (Perl6 was made similar to Haskell, so none would beat the other.)
This one contrived example does favor Perl, and will beat Haskell by a small margin. But as soon as the user says "Oh, sorry, I was mistaken, I needed the number and the next letter" or something like that, Haskell is on top again. As Haskell is one of the greatest languages for handling "Oh, sorry, actually..." requisites, and Perl one of the worst.
As long as the "actually..." only needs a small change to a simple regex (as in your example), perl probably wins the "actually..." game as well until you pull in enough libraries that the Haskell looks a lot like the perl. It's when the regex starts getting overcomplicated and the Haskell breaks out parser combinators that Haskell probably moves into the lead.
As you say, though, the margin perl maintains is small.
I think marcosdumay's claim is that Perl is less editable than Haskell. That's arguably true, though I'm not sure that editing a simple regexp in a simple script actually shows the issue.
Yeah, I agree with the broader claim. IMO well-structured Haskell will tend to be easier to maintain then well-structured Perl, and poorly structured Haskell will tend to be easier to get well structured than poorly structured Perl.
I just thought the express claim being made significantly oversold it. Whichever approach you take with the Haskell in the example under discussion, modifying the Haskell is not easier than adding a handful of characters to a simple regex.
Actually, that problem sounds fairly well-suited to Haskell, because it's essentially a series of pure transformations. My Haskell is quite rusty, but I imagine the program would look something like:
I don't disagree with your thesis, but Haskell isn't too bad here - it took me one or two minutes and is somewhere between three and ten lines depending on how I break it up, including imports. IMO, it's uglier than the equivalent perl but ymmv.
Seven lines is even a bit much. You could do it all on the commandline if you don't mind a bit of ugliness, and all Perl programmers should be used to some ugliness.
perl -ne 'if (/^(\d+)/) { print $1, "\n" }'
Put the list of input files at the end of the line.
OK, here's a problem. Read a file of text (the name is to be passed in as a command-line parameter). For each line, if it begins with a number, print out the number.
I'd use Perl, and it would take me one or, at most, two minutes. It would take me seven lines, only because I put my curly braces on their own lines.
Now, I picked a problem that is a better fit for Perl than for Haskell. But that's kind of the point - there are problems that are a better fit for other languages than for Haskell, and when you hit one, you're better off writing the program in a language that fits better.