Functional Programming (was Pitfalls of lacking a MMU)

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
Rusky
Member
Member
Posts: 792
Joined: Wed Jan 06, 2010 7:07 pm

Re: Pitfalls of lacking a MMU

Post by Rusky »

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 :twisted:), 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
Further, what I was really trying to say with those analogies is that you already use functional programming. Backus put expressions in Fortran for the same reasons that he advocated functional programming, and it worked.

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 );
}
Here's quicksort in Haskell, and I'll even throw in the standard filter function it uses:

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
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?
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Pitfalls of lacking a MMU

Post by Brendan »

Hi,
Colonel Kernel wrote:@FP guys: I think the biggest problem with encouraging adoption of FP is that Haskell is used as the poster-child, but it looks so alien to most programmers. The important points to make are about the benefits of individual FP features (purity, immutability, etc.) in the right context. Personally I've always had a hard time understanding Haskell just because the syntax is so different than what I'm used to, but I've use FP techniques all the time in the languages I use in my day job (C++ and C#).
Before this discussion started I thought functional programming was different to imperative programming. Now I'm having a hard time seeing any difference at all; except for "it looks alien".

Think of it like this. You can do "pure functional programming" in virtually any imperative language, simply by restricting yourself to things without side-effects. Therefore "pure functional programming" is just a subset of imperative programming. Of course "pure functional programming" is a pain in the neck (the subset is too restrictive), so most functional programming languages find "alien" ways of working around the restrictions (non-pure functions, monads, whatever).

Is "functional programming" just a large pile of marketing hype with no fundamental difference to imperative programming, other than "it looks alien"? If there is a fundamental difference (beyond "it looks alien"), what is it?


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Pitfalls of lacking a MMU

Post by Brendan »

Hi,
Rusky wrote: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?
Mostly I've come to understand that you argue for the sake of arguing; and the reason you can't express your point in a clear and concise manner is that you never really had a point to express.
Rusky wrote:Functional programming is not....

[Snipped: Lots of stuff saying that imperative programming is better than functional programming because it's capable of all the same things with all the same advantages, without the silly/artificial restrictions]

... returns its value without changing anything.
Yep.
Rusky wrote: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.
Blueprints describe what the end result should look like (to a builder, for e.g.); but do not describe how to achieve that end result. A photo of my hairy arse describes the end result should look like (to someone making a sculpture, for e.g.); but doesn't describe how to achieve that end result. Neither of these are programming at all.
Rusky wrote:Shall we look at an example?
Um? That's 2 examples describing how to do something (in different languages); and no example that describes what. I don't know what am I supposed to compare these 2 "how" examples to.

For fun, I compared the Haskell example to a photo of my hairy arse (it was easier to obtain than a blueprint). I understood the photo without any problem (and without any special "how to understand a photo" training). Haskell was much harder to understand. ;)

[EDIT]
Ok, so I was thinking of an example of "describing what" for quicksort. Here's my example:

Code: Select all

Input values: 4, 1, 76, 9, 23, 5, 45, 123, 32
Output values: 1, 4, 5, 9, 23, 32, 45, 76, 123
You'll see there's no description of "how" involved; and because there is no description of "how" the same description of "what" would apply equally well to bubblesort, quicksort, insertion sort, etc (which are just different ways of achieving the same result). It would be extremely difficult for software (a compiler) to convert this description into working code (although something like this might work well for unit testing).
[/EDIT]


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Pitfalls of lacking a MMU

Post by Combuster »

Brendan wrote:Think of it like this. You can do "pure functional programming" in virtually any imperative language, simply by restricting yourself to things without side-effects. Therefore "pure functional programming" is just a subset of imperative programming. Of course "pure functional programming" is a pain in the neck (the subset is too restrictive), so most functional programming languages find "alien" ways of working around the restrictions (non-pure functions, monads, whatever).
Both paradigms are turing-complete and therefore theoretically identical. The only difference between imperative and functional languages is that imperative expresses the steps from start to end (do this, this and that to get this), whereas a functional language expresses all steps from back to front (we want this, which means we need this and this, and for that we need ...).

The difference is that programmers are taught (by standard) to think imperative, and that is also what makes most programmers bad Makefile writers. That process happens because it is what the world expects from them. A mathematician however would be much quicker in picking up haskell than they would C, because their inherent line of thought is reversed.

The advantages of functional programming is essentially the compiler - by reducing the possible styles of flow, the compiler gets its much easier to reason on the program as a whole, and therefore give the end result much more room for optimisation, including free multithreading.

On the subject of Haskell, it comes with a bunch of features that makes writing particular bits of code much, much easier and elegant. In particular when algorithms and data structure manipulation comes looking around the corner.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
Rusky
Member
Member
Posts: 792
Joined: Wed Jan 06, 2010 7:07 pm

Re: Pitfalls of lacking a MMU

Post by Rusky »

Brendan wrote:Before this discussion started I thought functional programming was different to imperative programming. Now I'm having a hard time seeing any difference at all; except for "it looks alien".
[...]
Is "functional programming" just a large pile of marketing hype with no fundamental difference to imperative programming, other than "it looks alien"? If there is a fundamental difference (beyond "it looks alien"), what is it?
You're falling into a turing tarpit. Both functional and imperative languages are (usually) turing complete- that's not the point. I will quote myself:
Rusky wrote:Functional programming is not merely an attempt to remove side effects- it emphasizes function application and immutable values as an alternative.
Functional programming is different from imperative programming in the way C is different from assembly:

You can do all the same things in C as in assembly, and most of the time there's a direct translation, although not always if you stick to "pure C" without inline assembly (and the naive translation is probably inefficient), but C is more abstracted from the hardware so it's a better tool for some things.

You can do all the same things in functional programming as in imperative programming, and most of the time there's a direct translation, although not always if you stick to "pure functional programming" without IO or FRP (and the naive translation is probably inefficient), but functional programming is more abstracted from the hardware so it's a better tool for some things.

Functional programming by itself (i.e. as it can be used in imperative languages) is good, but functional programming languages are fundamentally different in their goals. Features like higher order functions, operators reified as functions, pattern matching, algebraic data types, etc. make it easier to express and organize a large class of programs.
Brendan wrote:
Rusky wrote:Functional programming is not....

[Snipped: Lots of stuff saying that imperative programming is better than functional programming because it's capable of all the same things with all the same advantages, without the silly/artificial restrictions]

... returns its value without changing anything.
There you go again. Expressions, no matter what language they're in, are a form of functional programming. Just like how ordered lists of side effects, no matter what language they're in, are a form of imperative programming. You usually can't label a single language as purely one or the other- see The C Language is Purely Functional for an satire of how ridiculous things get when you try.
Brendan wrote:Blueprints describe what the end result should look like (to a builder, for e.g.); but do not describe how to achieve that end result. A photo of my hairy arse describes the end result should look like (to someone making a sculpture, for e.g.); but doesn't describe how to achieve that end result. Neither of these are programming at all.
Given 1) the "standard library" of knowledge builders have about how to make the stuff they see in blueprints, and 2) the detail blueprints have, I don't see much difference between a blueprint, a C program calling a standard sort function, and a Haskell program calling a standard sort function. "sort [ 4, 1, 9, 5 ]" means "a sorted list containing these numbers" just like a blueprint means "a building with ...this here, that there, with these dimensions...".
Brendan wrote:Haskell was much harder to understand. ;)
The same way this is harder to understand for a hairy-arse-ologist who hasn't learned surface integrals?
Image
[edit]
Combuster wrote:The difference is that programmers are taught (by standard) to think imperative, and that is also what makes most programmers bad Makefile writers. That process happens because it is what the world expects from them. A mathematician however would be much quicker in picking up haskell than they would C, because their inherent line of thought is reversed.
[/edit]
Brendan wrote:Ok, so I was thinking of an example of "describing what" for quicksort. Here's my example:

Code: Select all

Input values: 4, 1, 76, 9, 23, 5, 45, 123, 32
Output values: 1, 4, 5, 9, 23, 32, 45, 76, 123
You'll see there's no description of "how" involved; and because there is no description of "how" the same description of "what" would apply equally well to bubblesort, quicksort, insertion sort, etc (which are just different ways of achieving the same result). It would be extremely difficult for software (a compiler) to convert this description into working code (although something like this might work well for unit testing).
Just like functional/imperative, what/how is a continuum, not black and white. Your example is at one extreme with no "how" at all, but the Haskell program certainly has less "how" than the C program, which certainly has less "how" than an assembly program.
User avatar
Colonel Kernel
Member
Member
Posts: 1437
Joined: Tue Oct 17, 2006 6:06 pm
Location: Vancouver, BC, Canada
Contact:

Re: Pitfalls of lacking a MMU

Post by Colonel Kernel »

@Rusky and Brendan: Watching you two guys argue is like watching a train wreck in slow motion. :)
Brendan wrote:[Snipped: Lots of stuff saying that imperative programming is better than functional programming because it's capable of all the same things with all the same advantages, without the silly/artificial restrictions]
Brendan, those "silly/artificial restrictions" have a purpose. That purpose may not apply to most of the kinds of programming you do on a regular basis, but that doesn't make it invalid. In general, language restrictions are there to keep programmers from getting into trouble. You are a very experienced expert programmer and you know how to keep yourself out of trouble, so naturally you see these restrictions as pointless.

Have you ever worked on a very large body of code with a team of more than four developers, some of whom are inexperienced? If so, I would hope you'd be able to appreciate the value of imposing some restrictions.

Back to the debate at hand, I think you guys need to more carefully separate "functional programming" as a style versus "functional programming languages". The former is unquestionably present in almost everything we do (whether we realize it or not) and has intrinsic value. The latter is open for debate. My take on it is that one of you is arguing for chocolate, and one for peanut butter, but why not have both? :)
Top three reasons why my OS project died:
  1. Too much overtime at work
  2. Got married
  3. My brain got stuck in an infinite loop while trying to design the memory manager
Don't let this happen to you!
User avatar
JackScott
Member
Member
Posts: 1031
Joined: Thu Dec 21, 2006 3:03 am
Location: Hobart, Australia
Contact:

Re: Pitfalls of lacking a MMU

Post by JackScott »

Colonel Kernel wrote:My take on it is that one of you is arguing for chocolate, and one for peanut butter, but why not have both? :)
Completely off-topic, but if you melt chocolate and peanut-butter together in the microwave, you get an awesome topping for icecream. Not sure what that's an analogy for.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Pitfalls of lacking a MMU

Post by Combuster »

JackScott wrote:Not sure what that's an analogy for.
I believe it's good analogy for casting magic missile at this thread. Roll for damage :wink:
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
CrypticalCode0
Member
Member
Posts: 81
Joined: Wed Nov 09, 2011 2:21 am
Location: Behind a keyboard located in The Netherlands

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by CrypticalCode0 »

*facepalms*

last i checked this thread wasn't here for swapping recipe's, Although i do agree on the fact that peanut butter and chocolate paste do mix well on a sandwich.

IMHO there are some interesting hardware concepts that without a MMU become just that more interesting.

to give a example:
two CPU's in the same address space but access to memory is phase shifted 180 degrees opposed to each other.(AMP vs SMP)
Have fun multi threading without causing race conditions. ;)
childOfTechno
Member
Member
Posts: 28
Joined: Fri Feb 24, 2012 5:10 pm

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by childOfTechno »

I'm going to have a rant ...

It's amazing how the uninformed can be so sure of themselves *cough* Brendan *cough*. Just because YOU don't understand something, doesn't mean that it doesn't have merit. Please open your mind a little.

principle #1:
"Being able to prove things about a program has performance advantages."

Code generated by a good Java compiler (for instance) will often outperform code for the same algorithm generated by an equally good C++ compiler. The simple fact is that it is a lot harder for the compiler to reason about a C/C++ program, which limits the optimisations it can do (primarily because of pointers.) By the way, I'm talking about compiling Java straight to machine code, not bytecode.

an example:

In C++ "const" doesn't really mean "const". The compiler can't rely on a pointer/reference to a const variable not having it's constness cast away at some point: the assumption that when you pass a reference to a local const variable to some arbitrary function it's value won't change simply doesn't hold. (although it should, and you should assume that the compiler thinks this way.) In more strict languages const (or whatever it's equivalent is) means "bloody well immutable," so the compiler absolutely knows that no implicitly called function will modify the value of a variable referenced as such, and can optimise accordingly.

principle #2:
"Being able to prove things about programs is sometimes absolutely required."

The simple fact is: C/C++ is a pretty poor language if you want to formally prove anything about your code (automatically or otherwise.) This is why programs that absolutely have to work (fly-by-wire systems, control systems for nuclear power plants, etc) are almost never written in C/C++. Really, just about ANY language is better for formal verification methods!

A collection of functions with no side effects is amenable to mathematical analysis; ideally you can absolutely say how it will behave for ALL possible input values, not just those you think to test. Just because "it seems to work fine" is usually good enough for your daily coding needs doesn't mean that it's anywhere NEAR good enough for life critical systems. Bluntly, stop being an ignorant twat and think outside your little world. It's not academic wank :\
User avatar
gravaera
Member
Member
Posts: 737
Joined: Tue Jun 02, 2009 4:35 pm
Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by gravaera »

EDIT: Nvm, thread is just not worth the effort.
Last edited by gravaera on Fri Feb 24, 2012 7:45 pm, edited 2 times in total.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
User avatar
VolTeK
Member
Member
Posts: 815
Joined: Sat Nov 15, 2008 2:37 pm
Location: The Fire Nation

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by VolTeK »

childOfTechno wrote:It's amazing how the uninformed can be so sure of themselves *cough* Brendan *cough*. Just because YOU don't understand something, doesn't mean that it doesn't have merit. Please open your mind a little.
childOfTechno wrote:Bluntly, stop being an ignorant twat and think outside your little world. It's not academic wank :\
That is not needed in part of a response to this thread. Do not call people out to make judgement, and do not insult.
childOfTechno
Member
Member
Posts: 28
Joined: Fri Feb 24, 2012 5:10 pm

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by childOfTechno »

That is not needed in part of a response to this thread. Do not call people out to make judgement, and do not insult.
To be perfectly frank, Brendan's demeaning and insulting tone irritated me more than usual. I think he's more than deserving :)

---

My last post has me musing.

The virtue of learning about functional programming is that it is implicitly an exercise in learning about formal methods. Most programmers aren't mathematicians, which is fine, but in my opinion improving your understanding of maths will always make you a better programmer (I know it has done so for me.) A good example is the way I treat types and operators in C++

Where operators are overloaded, they should behave in the way you'd expect for the operator. If a type has "+" and "*" defined, one would naively expect that associativity and distributivity will hold; if it doesn't then code utilising "+" and "*" is not free of type context. An example:

Code: Select all

template <class any_t> const any_t some_function(const any_t a, const any_t b, const any_t c)
{
    return (a * c) + (b * c);
}
Now if operators are free of type context, you can replace the expression with "(a + b) * c", and things should, for the most part, behave themselves. (obviously there are subtle exceptions, but the point remains.) The advantage to the coder is simple, less context means less thinking; if you see an expression, you know what transformations you can make without having to pay much attention to the types involved.

My view of types is that a type defines a set. An instance of the type is a reference to an element of the set. Functions and operators defined over different sets should behave consistently. Operators don't necessarily need to conform to field axioms, just behave in a consistent way across the code base. (For example: when I am working on 3d code I relax the commutativity requirement for "*" and just ensure that types with it defined behave as groups.)

Extending this line of thinking: ideally casting operators should reflect isomorphisms between the structures defined by the operators and functions. A good example is the behaviour of vectors, unit quaternions and matrices in my vector maths library, which respect various group isomorphisms:

Code: Select all

(vec_t)(some_float * some_float) == (vec_t)some_float * (vec_t)some_float
(mat_t)(some_vec * some_vec) == (mat_t)some_vec * (mat_t)some_vec
(mat_t)(some_quat * some_quat) == (mat_t)some_quat * (mat_t)some_quat
Following this approach makes it much easier to reason about your code, because you don't need to consider anything except the code under consideration. Exactly what a given function or operator does isn't important, the properties it has are.

Thoughts ?
User avatar
VolTeK
Member
Member
Posts: 815
Joined: Sat Nov 15, 2008 2:37 pm
Location: The Fire Nation

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by VolTeK »

childOfTechno wrote:Brendan's demeaning and insulting tone irritated me more than usual. I think he's more than deserving :)

None of which was directed toward you. Think a little more before you speak like that to a moderator of this forum. To anyone else in fact. When you respond to a thread, do it in mind of the subject the original poster has presented, and not judging others responses or insulting them.
childOfTechno
Member
Member
Posts: 28
Joined: Fri Feb 24, 2012 5:10 pm

Re: Functional Programming (was Pitfalls of lacking a MMU)

Post by childOfTechno »

None of which was directed toward you. Think a little more before you speak like that to a moderator of this forum. To anyone else in fact. When you respond to a thread, do it in mind of the subject the original poster has presented, and not judging others responses or insulting them.
One: the fact that he's a moderator is completely irrelevant (and shouldn't even be mentioned.)

Two: I just made an assessment, you're entitled to disagree. I think he was behaving in a pretty uncivilised fashion, showing a lack of understanding and no desire to learn (do you not agree?) People with no desire to learn annoy me and I am more than happy to express my opinion of them. And colourful language is the spice of life :)

I don't think my position as a bystander has any bearing on this.

Anyway, this thread is dead Jim ...
-~ Beware the turing tarpit, in which everything is possible but nothing of interest is easy ~-
Post Reply