[fleitz]

The reason OO exists to the degree it does in my mind is that it makes it easier for Enterprise Architects to write code in Visio, this also lends itself to directly modeling the domain so managers don't have to think. Which leads to public class Money { public string Currency { get; set; } public float Price { get; set; } }

"The money class is the root of all evil"

[derefr]

OO models exist because they reflect how we describe things when not talking to computers. "This is Spot. Spot Is-A Dog. See Spot.run(). Spot.runs == :fast."

They're a crutch for people who can't (or don't have the training to) think in terms of sets, mappings, graphs, combinators, etc.

[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.

[IgorPartola]

Sometimes an object is exactly the right tool. Also it makes the syntax nice and clear: xyz->foo() is sometimes much clearer than foo(xyz). But yes, wrapping any bit of data into a object is silly. Some things are just not objects. Others make for very awkward objects. My personal favorite is a result of an SQL query that JOINs multiple tables. Do you make each type of joon its own type or do you just dynamically extend the existing type a la JavaScript? I tend to do the latter but that does not work well in a lot of languages and goes against their intent at best.

Lastly, OOP need != class based inheritance. Thus JavaScript is a very viable OOP environment any is very widely used, so no OOP is by no means dead.