[blub]

...or maybe FP is a crutch for mathematicians and purists. You're making a huge mistake: we shouldn't adapt our thinking to computers, we should adapt computers to our thinking and make them easier to operate. According to your logic, writing hexadecimal code is the holy grail of computer programming.

[loup-vaillant]

And you are making an equally huge mistake: that thinking in terms of sets, mappings, graphs, combinators, etc doesn't help. It does. And if a programmer is incapable of understanding those concepts, he should learn them.

The fact is, we shouldn't adapt computers to our thinking, nor our thinking to computers. We should adapt both to our problems.

[blub]

Sure it helps, but that's not what derefr said. He said that any other type of thinking is a "crutch" and that the ideal of thinking is "thinking in terms of sets, mappings, graphs, combinators, etc".

By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.

[loup-vaillant]

OK, I misread you.

That said, I tested both OO an FP, and my current opinion is that thinking more mathematically (in terms of sets, mappings…), almost always yields smaller designs, which are almost always more flexible and more efficient.

> By the way, "sets, mappings, graphs, combinators" is a pretty strange definition for a set. The element descriptions are vague and some of them seem unrelated to the others. That may be mathematically correct, but it doesn't make for a great argument.

I don't understand you here. Derefr didn't make any mathematical statement. He didn't described the concepts, he named them. The four items he mentioned are related. And why should they, anyway? The way I see it, Derefr just made a statement, not an argument.

[derefr]

Computers are theoretical constructs as well as practical objects. In order to work with the practical object "computer," you should first understand everything possible about the theory of the theoretical construct "computer." Then, when you understand it, you can code however you like.

To put it another way:

> Before I understood the Art, a punch was just a punch, a kick was just a kick. Then, while learning the Art, a punch became more than a punch, a kick more than a kick. Now that I understand the Art, a punch is a punch, and a kick is a kick.

Notice the removal of the "just"—now the underlying knowledge (the "more") is attached to the concept (it is not a pure concept, existing "just" for itself), but it is also understood that that the "more", learned while studying the Art, is perfectly described by the words "punch" and "kick"—that those high-level concepts are just abstractions for the low-level concepts learned while studying the Art.

It's a crutch to rely on concepts without understanding their foundations. (This is what I meant with my original conclusion, vague as it might have been.) However, having learned those foundations, you can decide for yourself, on a case-by-case basis, whether to think in terms of the high- or low-level concept, and indeed the high-level is sometimes the perfect tool for the job. But it's not the perfect tool for everything—and only studying the Art of Computer Science will show you why.