Object Orientation is not a Goal

oh, and btw, the guys that develop LIBRARIES, do know much more than any average developer :) ... because, well, that`s what they do ...

Seems to me you mix different concepts in the same post.

Yes, we want to solve problems, and therefore we have to think about the best ways to achieve it.

However, as you mentioned, there are generally various technical contrainsts around a project (not to mention all the non technical ones, like financial and political aspects). Sometimes fast development is key, sometimes scalability will be more important, sometimes maintenability is a must. You cannot enforce all these constraints at the same time, so you have to prioritize them and then select the most appropriate concepts / language / tools / frameworks / libraries accordingly.

And yes, designers of languages / tools / frameworks are supposed to know better than most developers what is good, just because this is their business. And yes, sometimes they fail, as everybody.

You seem to oppose OOP, FOP, AOP. I see no reason to oppose them, then can complement each others.

You also complain about fully object oriented languages. There is nothing worst than a language mixing concepts. In an ideal world int should not be more efficient than Integer. Is it just a question on how the compiler has been implemented.

The same way there is no reason why you could not optimize raw binary data manipulation in an object-oriented way. Very often, optimization is a mostly question of design and algorithm rather than syntax. You should look at optimization at a global (holistic) level. Optimizing at the syntax - line of code - level is usually not as efficient as one might expect.

IMHO, if I have no specific constraint, top 3 qualities of source code are:

• readable,
• correct,
• efficient.

Being efficient is less important than being clear and readable. Even being correct is less important. You can do whatever you want with readable code: fix it, improve it, reuse it. Conversely, you cannot do anything interesting with efficient but cryptic code.
I do think, all in all, OO is one good way to achieve these goals, with the right priorities.

Just my 2 cents.
Best regards, Erix.

Scala isn't optimising behind the scenes, but right in your face. It's quite clearly documented that Int maps to Java's int type, Double to double, etc. Scala just doesn't make any distinction between primitive and reference types, which simplifies the language quite a bit. Regarding mutability, Int and Double are just as immutable in Scala as they are in Java. Doing it differently would necessitate a massive performance hit. You're not creating new objects every time you manipulate bits. It might be worth making sure you know what you're talking about before going out and calling everything lame.

Article first part is OK, but when it comes to Java, I can't agree with that. All parts of a software don't need to be object-oriented, for example databases. But in language context, it should be a goal. OOP is a proven technology. The mistake is to try to make every software artifact object-oriented. "C# team praise" in Javalobby is odd.

For instance, why is it that in 2010, Java still doesn't have unsigned primitive types? Whenever I find myself having to do bit manipulation, I get annoyed by this. Why have I not been given the choice of what kind of primitives to use?

Why is it that in 2010, Java still doesn't have fully functional goto? Whenever I find myself having to jump to another location in code, I get annoyed by this. Why have I not been given the choice of what kind of flow control to use?

Gee, Java doesn't even have line numbers that Basic used to have thirty years ago!

We develop software to solve problems, and whatever it takes to solve a given problem properly, is the "right" way of doing it.

You could make good with just a hex editor. Other than that, every platform imposes its own restrictions, and you have to just live with it.

Besides, not having some feature may be (and more often than you'd expect is) an advantage. Think of goto or pointer arithmetics - perhaps there are situations where they'd be the best tools to use, but they are so prone to abuse that it's simply better not to have them at all.

Tower of Babel. 500 crap languages built on an OS that doesnt work. Rather than 1 language that works on all.

Don't feel you have points

 

I don't feel you understood my comment.

I understand where you are coming from.  You are on a difficult project where a simple answer is to just pound it out and avoid an OO concept.  And for that, you are right.  You shouldn't be constrained from "fixing the damn thing" or finishing the project, whether that contraint is OO or DDD or whatever.

 

However, there is such a thing as too much!

If you go back many years and code without OO, you'll find a lot of work being redone time and time again.  These mythical 'all OO' or 'completely reusable objects' is a goal we strive for so we can write LESS code next project, because we have reuse.  Reuse means a lot, too!  It means readability, learning curve (use the same business logic in 5 different places, more people understand it, and there is no learning curve to try and code it yourself or use the logic again), and, believe it or not, reuse (the more reusable code you have in a project, it usually 'forces' you to make your custom code reusable as well).

So, while I agree with you, that you CAN avoid pie-in-the-sky design principles, and you SHOULD avoid them when it is a small problem you need to fix and doing it the 'good/right' way makes the job 50 times harder, you shouldn't abandon the use of them, entirely.  They were developed after decades of developers got frustrated with the way code was written.  Having said that last line, perhaps you are frustrated enough to come up with a new design principle or method that doesn't abandon what we've used for decades, but is built upon it to solve its flaws?