61–70 of 123 posts
Earlier quoted context omitted.
Whats wrong about the above code? Does it not do what it means to do? Is your personal feeling for how this construct should be written syntactically any measure of intelligence?
It can be written: return (NULL != lpDataPointer)
return p;Earlier quoted context omitted.
The article pulls a Fallacy fallacy, otherwise known as an "argument from fallacy". Basically what he says is "none of the arguments against me are correct, because fallacy X". I simply ignore such statements, because they make discussion impossible.
Oh, so what happens if all the arguments against him are actually fallacious? You realise that you would have ignored him based on the fallacy of the Fallacy fallacy?
Earlier quoted context omitted.
It can be written: return (NULL != lpDataPointer)
I know, it can also be written in many other ways. What decides which one is more correct if they are all semantically equivalent? Is it less characters? Is it using exactly as many 'e's as 'a's? Is it the unnecessary braces?
As someone who is more familiar with OOP, I would love to see examples/hear more alternative approaches to organising code. Let's say that you want to design a CRUD app, but you're not going to use OOP. What are some of the ways you could choose to structure your code? Would you still use a pattern like MVC?
Earlier quoted context omitted.
One of the major points of the article is the "no True OO Programmer" fallacy: this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I compl…
The article pulls a Fallacy fallacy, otherwise known as an "argument from fallacy". Basically what he says is "none of the arguments against me are correct, because fallacy X". I simply ignore such statements, because they make discussion impossible.
> Above, I have, with some humor, suggested that proponents of OOP tend to indulge the No True Scottsman fallacy when arguing for OOP. On a more serious note, some proponents of OOP might try to defend themselves by suggesting that we are facing issues of commensurability: proponents of the pure-logic paradigm, or the functional paradigm, or the OOP paradigm, talk past each other because we can not understand the axioms on which each other’s arguments rest.
> I am willing to believe that this issue explains some of the disconnect between some of the more thoughtful proponents of the different styles. And yet, there has to be something more going on, since the empirical evidence is so overwhelmingly against OOP. Proponents of OOP are arguing against reality itself, and they continue to do so, year after year, with an inflexibility that must have either non-rational or cynically financial sources.
What OO brought to The table (and what many advocates of FP are forgetting) is context sensitivity, that is, functions/methods are brought in scope by the owning object rather. Typing dog.bark() is a thousand times more powerful in terms of tooling than bark(dog) or SomeDogPackage::bark(dog). I prefer the FP style of coding but I can't see average devs giving up on Java/C# style tools. Sure OO brought a lot of little…
In the article and elsewhere Clojure is often used as an example of an anti-OOP language, yet by either Alan Kay's definition (quoted in my previous comment) or by Bertran Meyer's definition^1 Clojure uses the object oriented paradigm. Clojure is more object oriented than PHP or C++ which only provide some OO-inspired data abstraction mechanisms, but are not based around them. ^1 «Object oriented software constructio…
What OO brought to The table (and what many advocates of FP are forgetting) is context sensitivity, that is, functions/methods are brought in scope by the owning object rather. Typing dog.bark() is a thousand times more powerful in terms of tooling than bark(dog) or SomeDogPackage::bark(dog). I prefer the FP style of coding but I can't see average devs giving up on Java/C# style tools. Sure OO brought a lot of little…
The good parts of OO aren't exclusive to it though. For example, Clojure provides protocols ( http://clojure.org/protocols ) and multimethods ( http://clojure.org/multimethods ) which result in far more flexible polymorphism than a language like Java.