Fine, you wanted it, you'll get it (But warning, I am deeply in Party Law today, so don't be shocked when I start to sing my clubs anthem while typing this):
'I know that you can, with insane effort, even write complete applications in assembler': Reductio ad absurdum. I know that you're making a parallel here, but it's just wrong to compare the effort of writing an application in an extremely high-level language (more abstract than most mainstream languages today) with the effort of writing the same app in assembly (BTW, assembler is the app that assemble assembly, no pun intended).
Oh, my fault...in German, the language is assembler as well. Must do this error often.
It is more than that, it is a matter of : The right language for the right task. You can't write a Real-time system in Visual Basic, so why try it? And how to develop a full application for a complex task in a function oriented language, when this task negates nearly all advantages of functional programming?
'I don't want to do larger projects in a function oriented language', 'and that is the problem for current function oriented languages: They are too theoretical for being irreplaceable': You use your opinion as stated facts. NO feature is irrepleaceable, as long as it's still possible to do something in language Q. Feature are extras, and a language that forces a vision of the world based on them (which is the case of, for example, Java) is, IMO, not needed and even harmful.
No, that is not just an opinion, see above. And Java is just another object-oriented language. Same kind of dogma as functional programming or imperative programming, not worse, not better. But still, you have abilities in each dogma, that makes them suited better or worse for a special task. Just try to model events in a purely functional task, where imperative languages have better reactions.
'the function orientation, which is nice for multi-core optimization', 'at least, they have more purpose than closures, which is a nice pattern that can be replaced by about one dozen alternatives, unless you are limited to function oriented programming': Those two statements show your complete lack of understanding of functional programming, which may be the base of the complete hatred (as it seems to me) of any language which implements it.
Don't assume, because you make an ass out of U and me. I had likely seen more functional programming in my life than you did, and if I would really hate it, I wouldn't see great uses for it, especially inside applications like Orbiter, where control loop processing and autopilots are crying for function orientation.
And please: Show me one semantic feature of closures, that can't be implemented in object-oriented or imperative languages without using a closure.
'Especially it shows that you have yet to understand what object orientation means and why it was invented': Yes, I do know most of the things needed to know about OOP. I know what's an abstract class, static class, polyphormism, heritance and the like. I also know when to use it and when to not, but the latter is far more important.
'
And "full of superfluous classes" is a statement that only shows in my personal opinion, that you are only talking hot air here.': Superfluous, in the case of Java, because everything needs to be a class, even things that, in the vision of a programmer without it's mind closed on Java, shouldn't, like the entry point. The need of the use of objects give raise to 'placeholder classes', where some other paradigm may be better suited to solve a problem, and
OOP masturbation.
So, you think that structuring programs by inheritance, having encapsulation of data or have code representations of formal software design tools is superfluous?
Also, "OOP masturbation" is a good reason more to doubt your experience with OOP. I don't need harsh words against functional programming, because I can talk about it without hate speak. Programming languages are just tools, and I have no sexual fetish for my tools, maybe you should ask yourself how much professionalism you have. I know that I can develop the same pseudoreligious zeal against managed code, but then, I at least remember which brainless coding makes me hate people who think they can let their programming language do the thinking for them.
To wrap up, and to not make this post longer than it should be (no need for [RANT][/RANT]
), it seems to me, Urwumpe, with all due respect (and I really mean it), that your mind is closed on 'Design Patters', 'Goto Considered Harmful', 'Java for Entrerprise' and the like. As far as I'm concerned, this isn't a problem as long as you don't use some of their flawed arguments. There are literally hundreds of ways of solving the same problem, and another thousand of ways of representing that solution. Imperative, OOP, C/C++ and Java are just as definite solution as functional, raw binary, Lisp, Haskell and everything else are.
You have forgotten to mention my Djikstra shrine. And of course, I should be known for burning Microsoft Press books.
And yes, I really love "Design Patterns". I experienced its power at work and learned quickly to appreciate the approach of having meta-code snippets additionally to the usual heap of code examples. Unless you can show me now a rational reason why it is bad, and which concept can replace such an useful architectural tool, I would happily try it.
Now...in the final analysis: Can you tell me any rational argument in your post? You are only ranting on the emotional level, really like a fan boy. Emacs is good, MS word (which is more powerful on the software development level and has much more "Apps" than Emacs) is bad. When the hype praises Haskell, Haskell is great. When people realize, that, just like with Lisp, it doesn't leave its theoretical niece and remains a toy for fans, it will be forgotten, just like many other hyped programming languages in the past. I remember how somebody said that Modula-2 will be the new standard and how Oberon will be the new standard when Object-Orientation came along.
The problem with hypes is, that coding according to hypes does not bring software. It means selecting a hammer for sawing wood, because its hammertime. Call me cynical, but that is the way it is. In the beginning, when you are young and unexperienced you are enthusiastic about knowing something so esoteric like Brain****, that you forget how useless it is. After many failures, you'll find out that the oldest languages are still around. Ada is not dead yet. Even Fortran is still around. C++ will likely survive D. Java has been talked dead every second year, only to be celebrated the next year. Javascript was hated as security hole and battlefield of browser incompatibilities, now it is standardized and replaces many other hyped proprietary browser extensions for dynamic websites.
And when you are really veteran in the IT business, you will know why it is so. Real programmers are deeply conservative in their work. You have many hackers and free-time coders, who claim the greatest art of their work. But the real mastery comes from silent, conservative, hardworking coders, who sit in the back rows of the xxC3, don't brag about every multi-dimensional recursion, drink aromatic coffee with a saucer under their cups, wear (often black) shirts and ties, have often bald heads instead of thinkgeek shirts, and concentrate in irish pubs at night, instead of the darknet. Most of the real coders of the world think Haskell is a whiskey brewery.
---------- Post added at 12:52 AM ---------- Previous post was at 12:17 AM ----------
BTW, if you really want to do proper OOP masturbation, the code will look like that:
Code:
#include <iostream>
#include <functional>
using namespace std;
template<class T> struct sum : public binary_function<T, T, T> {
T operator() (const T& a, const T& b) const {
T result = a + b;
cout << "The result is " << result << "." << endl;
return result;
};
};
main() {
sum s;
s(1,1);
}
At least for replicating the OOP masturbation example in proper C++ code.
Not only is this one absolutely by the current standards of the programming language. It is also still perfectly useless. No sane C++ programmer would write such code. It is still using the Harrier for the weekend shopping. Why should you? The OOP masturbation article is a plain flat insult against OOP, with exaggerated examples for showing how beautiful functional programming can be compared to a completely flawed interpretation of OOP. Now, that was too easy.
How would a octtree look like in a functional language? Not that it would be a simple task in OOP. But that is not the question. The question is: How long does it take in functional programming, to get the solution, implement it and read it again, if you have no idea on what it is? In OOP, it is pretty simple, even if you would use maximal optimizations and turn it into an array of nodes.
And how would a cheap RTS look like in functional programming? Can you do that without catching yourself imitating OOP by having lists of functions for each entity?
The proper C++ answer BTW for just this example, would be:
Code:
#include <iostream>
inline void sum(int a, int b) {
std::cout << "The result is " << (a+b) << "." << std::endl;
}
main() {
sum(1,1);
}
Why use a harrier for the weekend purchases?
Such function objects make sense when you want to do such operations on containers, by using algorithms. when the direct object orientated solution would become unreadable, which can happen pretty easily.
The OOP solution should btw be exactly the same object file as the pure functional solution in C++. If I would remove the "inline" in the second version, the second version could even be slightly slower, since the single function call might not be optimized away.
.
