Question C++/Template specialization

[MeDiCS]

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):

Good, something I can work on and get real results .

Oh, my fault...in German, the language is assembler as well. Must do this error often.

No worries, it's an awfully common mistake.


Now to the counter-arguments, starting from the more 'emotive' ones:

Can you tell me any rational argument in your post? You are only ranting on the emotional level, really like a fan boy.

Really? Where?

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.

Yes, I was a bit over the line here, and I'm sorry. My point in including this is that so much focus on a single feature or paradigm makes you think it's the only way to do it and it's possible to sometimes overdo it, and that all the other possibilities are plain wrong.

I at least remember which brainless coding makes me hate people who think they can let their programming language do the thinking for them.

Wait, what? That's the whole point of abstraction, to hide some details from the programmer, or, in other words, 'do the thinking for them'.

So, you think that structuring programs by inheritance, having encapsulation of data or have code representations of formal software design tools is superfluous?

Of course not. I think that this kind of complex structure is sometimes superfluous. I really wouldn't like use OOP just to print 'Hello, World!' as I'm forced to do in Java. And I surely wouldn't use OOP for symbolic processing.

maybe you should ask yourself how much professionalism you have.

None. Programming is hobby for me and I don't have some pesky boss trying to force something on me. That's why I'm exploring the possibilities.

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

Of course you have, which actually doesn't mean anything. It's just that functional programming != better paralelization. Saying that, because of function purity, today, is like saying that functional programming may be better because of garbage collection, while still disregarding it as a theoretical 'toy'.

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. [more rant about hyped languages]

Hell no, it's not a hype, at least not for me. Neither functional languages (Lisp and Haskell) are new, actually Lisp is the second-oldest language still alive (~50 years old, or something like that), and Haskell is ~20 years old. Those are only two of the languages that I'm learning/using, and I really don't regard a language or programming paradigm as a religion, which seems to be the contrary of what you're doing with OOP. Yes, OOP is perfect for solving a class of problems, but it's not the definite answer. The whole point of this series of posts is for me to know why you disregard functional programming. The closest answers I got are these:

both are nice for theory, but effectively useless for praxis, since more than a few algorithms with them is impossible, since the reality is not that function oriented

I don't want to do larger projects in a function oriented language, not even with something like Scala, because other languages are far more better suited for the task - the function orientation, which is nice for multi-core optimization, can also be reproduced in other languages, with more effort. and that is the problem for current function oriented languages: They are too theoretical for being irreplaceable.

(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)

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?

Just try to model events in a purely functional task, where imperative languages have better reactions.

And please: Show me one semantic feature of closures, that can't be implemented in object-oriented or imperative languages without using a closure.

For me, those are you opinions, as I haven't read a line justifying those affirmations. Which may be better for some tasks: pooling for events every X seconds, or passing first-class function to be called when the event triggers? The second presents one of the characteristics of functional programming: function as data. I already see a point here for functional programming. Oh, and BTW, show me a OOP feature that can't be implemented in a purely procedural language. I take you already know Glib, and it's OOP implementation for C called GObject? And CLOS for Lisp? Unless the language is not turing-complete, you can implement any features you want in it, which makes this kind of argument pointless. Just because I have objects in C, does it means I'll never program in C++/Java?

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?

You're basically saying that functional programming is not the right tool for any job, right? If so, there's a contradiction:

And Java is just another object-oriented language. Same kind of dogma as functional programming or imperative programming, not worse, not better.

Imagine you have a function which takes the derivative of another function. Is it better to implement it in a functional paradigm, or using OOP?


There are a bit more I want to say, but I not finding a good way of expressing it. This post is long enough though. I'm waiting for you answer :thumbup:.

 

[Urwumpe]

Imagine you have a function which takes the derivative of another function. Is it better to implement it in a functional paradigm, or using OOP?

Of course it is a function that does represent a function best. What a surprise. Maybe you should apply for the Turing Award with this realization.

But how about objects? And now don't tell me that objects can be always represented by lists of lists of lists and function variables can be used for implementing virtual methods and... suddenly you are imitating OOP. Maybe I have not been clear enough on the topic yet, for reaching your sensors, but here it comes again, in a higher amplitude:

Since all programs are executed by pretty much the same computers (Turing completeness, von Neumann architecture, etc), all programming languages will of course be able to imitate the other to an extend. That is never the question. But what about the ability to read such programs? Would a dialog implemented in functional programming as series of lists and function objects be easier readable than the same in OOP? Really? Could you implement encapsulation features in a language that doesn't support encapsulation properly? The answer is yes, you can. But at a price - you would have to imitate the other programming language compiler in your program at the source code level. What the OOP compiler will do for you, will have to be done by you.


Programming is also an hobby for me, even before I decided to earn my money with it.

Now I still do it as hobby...but got some experiences from the front line, that I wouldn't have made while playing around. It is a difference if you solve problems for fun or because your salary depends on it. If I solve problems for fun, I can afford chasing for the most beautiful and cool solution (as you can see too often in SSU..... ). If I have to do it for work, a 90% solution in 10% of the time for the 100% solution becomes the standard. If you do it for work, you also can't reinvent the wheel every week, in the best case, you are even expected to bring your solutions into the companies "code pool"/standard library for future use. And you start to learn that the bad things of programmings are actually the good side of the force:

• Documentation is annoying, but necessary.
• Writing tools is no waste of time, that can be delayed until doomsday or delegated to the new guys.
• Communication while programming is better than having discussions when things have broken down.
• Debugging starts before you write the first line of code.
• Extreme Programming might be a bit crude, but it has some truths.
• What doesn't work on the paper/whiteboard, will not work as code. Don't think you can fix things by trail and error.
• Design patterns are great for reducing the effort for explaining your code to other developers. Did you think they are made for something else?
• If you can't read your own code after two weeks anymore, you have failed. Yes, gotos are not bad. But they are indeed harmful.
• Night shifts are not something to be proud of, because they mean that you have lost time sometime earlier in the development. Getting home for dinner everyday during a critical project and finish it right on the money is something to be proud of. And its really hard to be achieved.
• Don't fear that somebody else might be able to do your job, if you write readable code and document it well. The software design is more than just programming, and much better paid.

 

[MeDiCS]

I'm beginning to wonder if it's still worthwile to continue reading posts in this thread, and to write and post here. It's both confusing and frustrating.

Confusing because there seems to be two Urwumpes: one says 'use the right tool for the right job', while the other says 'OOP is the right tool for any job, except taking a derivative'. It's your right to defend your point of view, but please do it with real arguments. Saying that functional programming is bad because it doesn't mirror how our world functions is not a real argument. Programming is not about reality, but about abstractions. You say that complexity negates all the possible advantages of function-oriented programming. You say that events are better moddeled by imperative languges, and by extension, object-oriented approaches. You say that it's imperative to represent any non-trivial program as a collection of objects, and that encapsulation by OOP is the only way to archieve true encapsulation, that functional programming is inherently theoretical, and not ready for real-world use. You also say that code redability is directly related to the use OOP paradigms.

Why? How? Those the real questions here.

No, no, please don't answer saying that to implement F feature, OOP is obviously the best way to do it, as you've done several times. Have you never used a function pointer? Also, please, try not mixing characteristics of specific programming languages with characteristics of functional programming. If I want to represent state, I'll go imperative. If I want to represent functionality, I'll go functional. Lists are a way to represent data, as are hash tables, trees and any object. I sure wouldn't use an associative array to store sequential values, and I sure wouldn't use Ada to write a text-manipulating app.

No, I would not write an RTS in a purely functional approach, as there are lots of states to be stored. May I suggest you to apply for the Turing Award for this marvelous discovery? If we're lucky, we can share the prize.

Frustrating, because instead of a real answer, I get irony. I get an OOP evangelist which accuses me of being a fanboy for not seeing the obvious, for 'defending' hyped approaches to problem-solving, for saying that there are different, even better means of getting to the final goal.

Frustrating because I never said anything against using OOP, only if you overuse it, which is true for almost anything in life. Still, you keep hitting the same key over and over. The best 'answers' I got was those included in your last post's list. Most isn't anything new, and the rest is oriented to professional developers. Still, it's the best I could get out of you.

I really do think your mind is closed on specific topics. It's one of the reasons I said you were reading 'Design Patterns', because it's useful, but it's awfully common for people to think that those are the best, or in the most severe case, the only approaches for any type of problem-solving.

Really, I'm beginning to doubt your capacity as well. Overuse of reductio ad absurdum and irony is hardly a good way to express solid opinions. Even with that said, I really don't expect a reply without those.

[/RANT]

 

[Urwumpe]

Overuse of reductio ad absurdum and irony is hardly a good way to express solid opinions.

Then stop it and show that you are better than I am, at least in this context. I didn't need to quote dogmatic pamphlets like "goto should be considered harmful" or "OOP masturbation" here. It is you here, who relies on hyperbolas for forming your opinions.

And again - don't assume. You do that strangely more, the more I tell you to stop it.

PS:about the two Urwumpes: There are only three kinds of people in the world. Those who can count and those who can't.

 

[Hielor]

Frustrating because I never said anything against using OOP, only if you overuse it, which is true for almost anything in life.

If it's true for almost anything, then what is the point of saying "this is true for x"?

It's possible to misuse *any* construct in programming, including functional programming paradigms. Of course OOP is no exception.

 

[MeDiCS]

Ok, then, but I'd prefer you to say simply write 'I won't answer' or something like this sooner. Respect and time are close to impossible to recover.

If it's true for almost anything, then what is the point of saying "this is true for x"?

My bad there, I forgot to include 'but you act like I'm personally attacking it'.

 

[Urwumpe]

Ok, then, but I'd prefer you to say simply write 'I won't answer' or something like this sooner. Respect and time are close to impossible to recover.

Remember, I was out of this thread before you insisted on me answering your rants. I gave you your chance, so don't complain now that I didn't give you a second one after I wrote what wouldn't have been necessary in first place.

We could just have agreed to disagree.

 

[MeDiCS]

Remember, I was out of this thread before you insisted on me answering your rants. I gave you your chance, so don't complain now that I didn't give you a second one after I wrote what wouldn't have been necessary in first place.

Look, Shall I really answer something now, or can I just leave the thread and go laughing? :rofl:

I had read it all, but really, it was summarizing your competence pretty well, and I thought it is now a good point to stop this discussion before you get more chances to loose your face here. I am evil, but I am not mean.

I'd hardly consider those answers the same as 'I won't answer', 'I won't reply', or to simply ignore me.

We could just have agreed to disagree.

Again, do as you please.

 

[Enjo]

It doesn't matter who's right or wrong in a discussion, but hell it matters who's got the last word.
That would be me now, hah!