|
 |
>> Is this supposed to be efficient?
>
> If your functional language is pure enough, your compiler can often
> optimize out the apparent inefficiency. Of course, that requires a
> Sufficiently Smart Compiler.
>
> In practice, it's less efficient, but not as obviously awful as it would
> appear.
In a way, it's a bit like SQL. In SQL, if you want to find the customer
name for each order, you say "take the Cartesian product of the order
table and a customer table, then go through the result and throw away
all rows except the ones where ord_cust = custID". If both tables are of
size N, then the first step is O(N^2) in time and space, and the second
step is O(N^2) in time and O(N) in space.
That's nauseatingly inefficient! But fortunately, every half-sane RDBMS
on the planet looks at that query and goes "ah-HAH! You're doing a table
join!" and replaces it with a vastly more efficient algorithm. (Be it a
hash-join or an index lookup or whatever.)
If SQL wasn't being run by a "sufficiently smart interpreter", it would
be too laughably inefficient to even consider using. The *only* reason
its so ubiquitous is that everybody has built really, *really* smart
interpreters. And everybody /relies on/ the query you actually write
being optimised into something very fast. Usually it works every well
indeed.
Of course, SQL isn't a general-purpose programming language. It solves
one problem well. (Although it's not quite the relational algebra...)
Haskell is a general-purpose programming language. You write constructs
which /look/ horrifyingly inefficient. And then the compiler does its
thing, and the end result is more efficient than you'd imagine. Sure,
probably not as fast as C, but fast enough.
Also: I love how this started out as "how easy is it to understand
Haskell?" and has once again degenerated into "Haskell must be really
slow". Which wasn't the question at all.
You know those C hackers? The ones who write horribly unmaintainable
code in the name of being a few clock cycles faster? The ones who are so
obsessed with using the minimum amount of CPU time and RAM that they
write horrid spaghetti code?
Yeah, everybody hates those guys. You know what their problem is? They
fail to realise that programs are judged on criteria *other* than
run-time efficiency. Obviously nobody /wants/ slow code. But then nobody
/wants/ buggy code, unmaintainable code, code that crashes, code that's
impossible to understand, code that takes months to write and debug.
There's a /reason/ people code stuff in C and not assembly. Even though
(in theory if not in practise) assembly is faster, people use C. As I
recall, there was a long time where people wouldn't use C++ because they
said it was "too slow", and that only C was "fast enough". (Which as
amusing, given that the Language Shootout claims that C++ is actually
marginally /faster/ than C...)
Haskell usually isn't as fast as C or C++. It's also a lot simpler to
program. Especially if you want parallelism. You ask me "how do I update
a heap without copying?" I ask you "how do you update a heap in a
thread-safe manner?" Immutable by default => thread-safe by default.
That's just one example of the kind of benefits that Haskell brings.
According to the Language Shootout, Haskell averages about 3x slower
than C. Java averages only 1.5 slower (but uses more memory than
Haskell). Then again, people actually write applications in Ruby, Python
and so forth. People build high-traffic websites with PHP and Perl. All
of these come in at *hundreds of times* slower than C. And it hasn't
dented their popularity at all.
Sometimes run-time efficiency isn't the most important thing.
(One could argue that although Perl is Turing-complete, it probably
shouldn't be regarded as a general-purpose language. It's probably
blisteringly fast for the tiny fraction of the language that most people
actually use. One could also argue that the Language Shootout is a
benchmark to see which language has the most zealous fans with the most
spare time...)
Post a reply to this message
|
|
