Re: Pitfalls of lacking a MMU
Posted: Tue Dec 06, 2011 11:20 am
What is this, Brendan? Just throw all reason out the window and mock people when you run out of things to say? If you can't be bothered to read or even google something, then what you had already assumed must be correct? If someone tries to point out some common ground, you sarcastically pretend they have nothing else to say? If someone tries to use an analogy to describe something, you twist it around and don't even try to comprehend their point?
Functional programming is not merely an attempt to remove side effects- it emphasizes function application and immutable values as an alternative. In fact, most functional languages are not pure. Many of the ideas that come from this point of view were borrowed by (or inspired by!) imperative programming languages.
Don't get the wrong idea- I'm not claiming functional programming is unequivocally better. I wouldn't write a kernel in Haskell (though it's been done
), but I would use functional techniques in a kernel, and I would write other kinds of programs in functional languages.
However, functional programming's focus on transforming values gives several advantages:
Most operators, even in C, are pure functions - they take inputs and give outputs without any side effects - as opposed to assembly, where most instructions destructively update their operands.
The functions you use in spreadsheets are the same - they take inputs and give outputs without any side effects. I would even bet that Excel has a function somewhere that takes a cell's contents and returns its value without changing anything.
You're right that there's a difference between describing how and what... but they're both programming. One of them is simply at a higher level of abstraction. Blueprints describe to the builders what to do, just like your call to a standard sort function describes what to do.
Shall we look at an example?
Here's quicksort in C:
Here's quicksort in Haskell, and I'll even throw in the standard filter function it uses:
Are you really going to say the Haskell version isn't a program? Are you really going to say that declarative description of a sorted list is "unnatural" or harder to understand? Are you really going to say that having "qsort [ 3, 7, 1, 8, 9 ]" evaluate to "[ 1, 3, 7, 8, 9 ]" isn't functional programming just because it's possible in imperative languages? Are you really going to say something like QuickCheck would work just as well in C? Are you really going to say you can't parallelize the Haskell version trivially?
Functional programming is not merely an attempt to remove side effects- it emphasizes function application and immutable values as an alternative. In fact, most functional languages are not pure. Many of the ideas that come from this point of view were borrowed by (or inspired by!) imperative programming languages.
Don't get the wrong idea- I'm not claiming functional programming is unequivocally better. I wouldn't write a kernel in Haskell (though it's been done
), but I would use functional techniques in a kernel, and I would write other kinds of programs in functional languages.However, functional programming's focus on transforming values gives several advantages:
- functions are easier to reuse - their dependencies are explicit and can thus be explicitly exchanged
- code is easier to test - for the same reasons as reuse, it's easier to call a function with all kinds of inputs
- programs are easier to optimize - pure functions are automatically thread-safe and less coupled
- interfaces are easier to understand - everything the interface uses is right there at a glance
Most operators, even in C, are pure functions - they take inputs and give outputs without any side effects - as opposed to assembly, where most instructions destructively update their operands.
The functions you use in spreadsheets are the same - they take inputs and give outputs without any side effects. I would even bet that Excel has a function somewhere that takes a cell's contents and returns its value without changing anything.
You're right that there's a difference between describing how and what... but they're both programming. One of them is simply at a higher level of abstraction. Blueprints describe to the builders what to do, just like your call to a standard sort function describes what to do.
Shall we look at an example?
Here's quicksort in C:
Code: Select all
void qsort(int a[], int lo, int hi)
{
int h, l, p, t;
if (lo >= hi) return;
l = lo;
h = hi;
p = a[hi];
do {
while ((l < h) && (a[l] <= p))
l = l+1;
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
t = a[l];
a[l] = a[h];
a[h] = t;
}
} while (l < h);
a[hi] = a[l];
a[l] = p;
qsort( a, lo, l-1 );
qsort( a, l+1, hi );
}Code: Select all
qsort [] = []
qsort (x:xs) = qsort small ++ [x] ++ qsort large where
small = filter (< x) xs
large = filter (>= x) xs
filter [] = []
filter f (x:xs) = if f x
then x : (filter f xs)
else filter f xs
