OOP Criticism
category: general [glöplog]
So approx. 10% of coders are actually worth their salt. This kind of checks out from what I've seen in professional environments. And while 10%-20% might seem like a small percentage, in absolute numbers it's still a considerable force well capable of publishing papers, opinions and whatnot. And that's how potentially useful stuff gets a good market share.
quick braindamage. programming is like climbing an infinite ladder. When you finally think you got it, you reach the next level and knows nearly nothing.
stijn:
I am not sure I can agree with that. In my experience, procedural programming is easier to grasp and even if people can screw it up, they are less likely to screw it up all over.
Quote:
Because any given programming tool/paradigm will be misused by at least 90% of the programmers.
I am not sure I can agree with that. In my experience, procedural programming is easier to grasp and even if people can screw it up, they are less likely to screw it up all over.
neoneye: with experience comes humility
FUCK I CAN'T STAND THAT LOUIGI DUDE.
I am going to make a demo about it.
I am going to make a demo about it.
well at least he reduced the amount of useless topics he opens a bit recently...
...nevertheless, the selectively ignorant arguing-for-the-sake-of-arguing style employed is annoying as fuck
...nevertheless, the selectively ignorant arguing-for-the-sake-of-arguing style employed is annoying as fuck
it would be less useless if this weren't a discussin that has been had a million times before in different communities, often yielding the same arguments :)
Quote:
with experience comes humility
true wisdom.
EOF.
Quote:
...nevertheless, the selectively ignorant arguing-for-the-sake-of-arguing style employed is annoying as fuck
I understand that actually trying to figure out something can be annoying to some people, who are used to just come to forums for a bit of entertainment and no academic discussion, lots of which they perhaps have at a college or work.
Well, I am sorry, but if an argument presented does not stand up to critical thinking, I am pointing it out. After all, I do not force people to discuss something with me. If you are not interested - just pass along. 0 replies to a thread is a clear signal to the thread starter that forum members are not interested.
Quote:
it would be less useless if this weren't a discussin that has been had a million times before in different communities, often yielding the same arguments
Lots of things were discussed a million times. I personally never discussed OOP before. Maybe some topics you talk about I have had a lot of experience with - but I am not going to every "useless" topic and say that it's useless to me. What I do is just don't take part in discussions which are not interesting to me.
Also, with software development situation always changing, raising such a topic from time to time can bring in different arguments and actually reading discussions which I found on the web and which are dated 2002 and such, I can see that today the thinking about OOP has changed in some ways.
Quote:
Well, I am sorry, but if an argument presented does not stand up to critical thinking, I am pointing it out. After all, I do not force people to discuss something with me. If you are not interested - just pass along. 0 replies to a thread is a clear signal to the thread starter that forum members are not interested.
a forum =/= the oldskool pouët.net bbs
it takes some audacity to label this discussion as 'academic', louigi
Quote:
Lots of things were discussed a million times.
this thread is now about impulse tracker!
i think impulse tracker is bad since 90% of the tunes made by it are crap.
impulse tracker > fast tracker, since actually doesn't have any hair-pulling "features" that result from badly written ASM code and that are a pain in the ass to emulate.
emulating IT has had its share of troubles for comparable reason
(i've got the IT asm code in a dusty corner of my hd somewhere)
(i've got the IT asm code in a dusty corner of my hd somewhere)
Quote:
*chuckle*i think impulse tracker is bad since 90% of the tunes made by it are crap.
FooLman- Oh, cool.
blala- No, I didn't know about algebraic data types, because I don't know much about functional programming, other than the basic concept. It's very difficult for me to understand that article. Do you have a specific thing to say about it?
_-_-__- Do you actually use all of those BRules all the time when you are programming? I thought only Dr Steve Brule followed BRules Rules.
blala- No, I didn't know about algebraic data types, because I don't know much about functional programming, other than the basic concept. It's very difficult for me to understand that article. Do you have a specific thing to say about it?
_-_-__- Do you actually use all of those BRules all the time when you are programming? I thought only Dr Steve Brule followed BRules Rules.
Quote:
emulating IT has had its share of troubles for comparable reason
Most things are straightforward to implement when you follow ITTECH.TXT at least. Tremor is not really straight-forward indeed, but just try to implement the normally fucking simple Arpeggio command in FT2 style and you will go nuts. Not even Milky does it get right yet. Another good example would be the combination of EDx and volume column or note offs. It's just plain stupid.
@yesso: my point was that having "user-defined types" has nothing to do with OOP or OOP-style classes.
Algebraic data types are actually a very simple but quite powerful concept. If you ask yourself, "what is a (singly linked) list?", you may come up with the following answer: a list is either empty, or it has a first element and the rest of the list (which is a smaller list). You can translate this recursive definition to "computer language" almost word-by-word (using Haskell syntax):
Similarly, you can ask yourself, "what is a binary tree?". A binary tree is either a leaf, or a branch with two smaller binary trees on each side:
You can very easily write functions to work with these structures, using pattern matching; for example here is a function which concatenates two lists:
Note that this is actual working code, not some kind of pseudecode, and it is working with any type "a". We didn't have any kind of OOP here, and we have pretty advanced types. You can probably do the same with C++ and templates, still without OOP, but that will be much uglier...
--------------
hmm i then realized that this is pouet, so i must follow the pouet discussion standards:
Algebraic data types are actually a very simple but quite powerful concept. If you ask yourself, "what is a (singly linked) list?", you may come up with the following answer: a list is either empty, or it has a first element and the rest of the list (which is a smaller list). You can translate this recursive definition to "computer language" almost word-by-word (using Haskell syntax):
Code:
("a" is the type of the elements of the lists, and "cons" is the traditional name for this operation of prepending an element, coming from the lisp era. "List a" is the type of lists with elements of type "a", and "Empty" and "Cons" are constructors).data List a = Empty | Cons a (List a)Similarly, you can ask yourself, "what is a binary tree?". A binary tree is either a leaf, or a branch with two smaller binary trees on each side:
Code:
data Tree a = Leaf a | Branch (Tree a) (Tree a)You can very easily write functions to work with these structures, using pattern matching; for example here is a function which concatenates two lists:
Code:
and one which flattens a binary tree in left-to-right order:concat :: List a -> List a -> List a
concat Empty ys = ys
concat (Cons x xs) ys = Cons x (concat xs ys)
Code:
flatten :: Tree a -> List a
flatten (Leaf x) = Cons x Empty
flatten (Branch left right) = concat (flatten left) (flatten right)
Note that this is actual working code, not some kind of pseudecode, and it is working with any type "a". We didn't have any kind of OOP here, and we have pretty advanced types. You can probably do the same with C++ and templates, still without OOP, but that will be much uglier...
--------------
hmm i then realized that this is pouet, so i must follow the pouet discussion standards:
Quote:
i would say more like 1%...So approx. 10% of coders are actually worth their salt.
Quote:
it takes some audacity to label this discussion as 'academic', louigi
Quote:
but audacity is crap independently of how many percent of the tunes made with it are crap!!1i think impulse tracker is bad since 90% of the tunes made by it are crap.
Quote:
It seems other people starts with classes, as if there was a way to create them completely out of thin air, and proceed to write the algorithms afterwards on top of that.
That is a valid principle, though. Algorithms are an implementation concern, i.e. they're the low-level stuff. In many projects that has a very low priority next to what interfaces classes present to each other (i.e. what the high-level structure of the program looks like). I'd say lay out as much of the class definition as you can before you worry about any "functional" code at all.
blala- I didn't mean to suggest that OOP is the only way to have user-defined types. It's not that user defined types implies OOP, but that OOP implies user-defined types.
But thanks for explaining algebraic data types. It seems like an interesting concept, though I'm still not sure how it would scale to a full application. It seems there are some full-scale apps written in Haskell though. I'd have to study it a lot more in-depth.
But thanks for explaining algebraic data types. It seems like an interesting concept, though I'm still not sure how it would scale to a full application. It seems there are some full-scale apps written in Haskell though. I'd have to study it a lot more in-depth.
yesso, not really, since it's very strict. However I do take cues from such (or the LSP) to judge the quality of a design. It's not about getting everything perfect, rather about finding a balance between robustness -- make it as hard as possible to create new bugs --, performance -- the design fits the runtime constraints --, maintainability -- easy to add predictable changes --.
doom, I guess you must be one of those people. I won't argue whether Nouns are superior to Verbs or the reverse, however some old guy with a beard once said "In the beginning was the verb."
Basically it's hard for me to ascertain the quality of a design that does not serve any computation or operation.
As for your remark that "algorithms are an implementation concern." Algorithms can be as high level as you make them to be. At the design stage they don't even have to be described in terms of the minute operations that they are performing it.
(Algorithms are more abstract and generic than classes)
For example, if I say:
Nowhere here did I bother to tell which sort algorithm to use for the sorting. Neither did I say how the triangles would be rasterized.
As an aside, I introduced the "triangle" noun here. Would that make it a candidate to be a class? Would that be good design?
doom, I guess you must be one of those people. I won't argue whether Nouns are superior to Verbs or the reverse, however some old guy with a beard once said "In the beginning was the verb."
Basically it's hard for me to ascertain the quality of a design that does not serve any computation or operation.
As for your remark that "algorithms are an implementation concern." Algorithms can be as high level as you make them to be. At the design stage they don't even have to be described in terms of the minute operations that they are performing it.
(Algorithms are more abstract and generic than classes)
For example, if I say:
Quote:
Let T be a set of triangles.
Let i be an image
T is sorted into ST according to midpoint z view-space coordinates.
For each triangle t of ST, rasterize t into i
Nowhere here did I bother to tell which sort algorithm to use for the sorting. Neither did I say how the triangles would be rasterized.
As an aside, I introduced the "triangle" noun here. Would that make it a candidate to be a class? Would that be good design?
hmmm. a simple off-topic "real-world" language question:
do you say
"for each element in an array" ..
or
"for each element of an array"
According to Google Fight, there seems to be an equilibrium.
any native english speakers, here ?
do you say
"for each element in an array" ..
or
"for each element of an array"
According to Google Fight, there seems to be an equilibrium.
any native english speakers, here ?
@ Hermes
When we say:
"for each element in an array" we mean that the effect applies to every element contained in an array.
When we say:
"for each element of an array" we mean that the effect applies to each element in array, and individually only to it.
@all
WTF, has the oldscholl pouet bbs become a forum for tech geeks where they judge scientifically other sites? Or they argue about the best web browser or sth?
When we say:
"for each element in an array" we mean that the effect applies to every element contained in an array.
When we say:
"for each element of an array" we mean that the effect applies to each element in array, and individually only to it.
@all
WTF, has the oldscholl pouet bbs become a forum for tech geeks where they judge scientifically other sites? Or they argue about the best web browser or sth?
I think that's a fitting example of a case where you don't want to be tied down by algorithms, even a high-level choice like sort-and-rasterise. E.g. working with modern hardware, sorting and rendering a triangle at a time are two things you mostly don't want to do. In a software engine, per-pixel z-buffering may or may not be faster than sorting if the number of triangles is large enough, and some meshes can't be sorted at all.
And what good is a set of triangles? If you're researching algorithms or experimenting with a demo effect that's the sort of construct you might work with, but I think anywhere high-level design becomes a big issue (like a 3D engine say) the more relevant concept is one of a "3D object". The relevant verbs aren't "sort" and "rasterise" but more like "place yourself into this scene", or "scene, please accept this 3D object".
Sure, somewhere at a fairly low level in the engine you may have those "sort" and a "rasterise" verbs, but that's the "algorithm level" I'm talking about, way beneath where the important decisions are made. If you start at that level it can be a very steep climb upwards, and many of the choices you make may cause frustration later on because they force you into design patterns that aren't suited for the overall program.
Since you ask, though, yes, I think triangle is a good candidate for a class (even if it's still little more than a datatype, consider the varieties of triangles there might be: flat, textured, shaded, etc.), as is the set of triangles, and the image.
For that matter, the set of sorted triangles is a good candidate for a sister class to the unsorted set. After all if what you're looking for is a sorted set, sorting an unsorted set is just one way to get there. Let's say you're doing marching cubes over some scalar field, you could just align the sampling grid with view space. Thinking in terms of a rasteriser class that can do "whatever" is helpful:
Further abstraction would get rid of the triangle set, or, make it derive from a "shape" class (and you'd have to turn that around slightly to do it in C++ anyway). But the point is with that higher-level structure there's a much clearer description of what you want to do, as opposed to how you want to do it. The framework should reflect firstly that you're trying to render a shape, and secondly that you have a way of doing it.
A better solution would be a renderer that's aware of whole objects and makes decisions on how to construct the final sorted set of triangles (or unsorted, or DX buffer object, or whichever fits the situation) with a broader awareness of the overall scene. That's one of the places where OOP and "interface first" thinking really shines, I think. I've done enough 3D engines the other way around to never want to do it again. ;) Nowadays I prefer to have a scene class, a hierarchy of classes for stuff that goes into a scene, then I have a renderer that attaches to a scene, and so on. And I'm happy to write class definitions for days before anything even compiles, because it really pays off in the end. I think. :)
And what good is a set of triangles? If you're researching algorithms or experimenting with a demo effect that's the sort of construct you might work with, but I think anywhere high-level design becomes a big issue (like a 3D engine say) the more relevant concept is one of a "3D object". The relevant verbs aren't "sort" and "rasterise" but more like "place yourself into this scene", or "scene, please accept this 3D object".
Sure, somewhere at a fairly low level in the engine you may have those "sort" and a "rasterise" verbs, but that's the "algorithm level" I'm talking about, way beneath where the important decisions are made. If you start at that level it can be a very steep climb upwards, and many of the choices you make may cause frustration later on because they force you into design patterns that aren't suited for the overall program.
Since you ask, though, yes, I think triangle is a good candidate for a class (even if it's still little more than a datatype, consider the varieties of triangles there might be: flat, textured, shaded, etc.), as is the set of triangles, and the image.
For that matter, the set of sorted triangles is a good candidate for a sister class to the unsorted set. After all if what you're looking for is a sorted set, sorting an unsorted set is just one way to get there. Let's say you're doing marching cubes over some scalar field, you could just align the sampling grid with view space. Thinking in terms of a rasteriser class that can do "whatever" is helpful:
Code:
class unsorted_triangle_set ...
class sorted_triangle_set ...
..
Renderer::please_render( unsorted_triangle_set UT ) {
sorted_triangle_set ST = UT.produce_sorted_set();
please_render( ST );
}
Renderer::please_render( sorted_triangle_set ST ) {
for each t of ST, rasterise t ...
}Further abstraction would get rid of the triangle set, or, make it derive from a "shape" class (and you'd have to turn that around slightly to do it in C++ anyway). But the point is with that higher-level structure there's a much clearer description of what you want to do, as opposed to how you want to do it. The framework should reflect firstly that you're trying to render a shape, and secondly that you have a way of doing it.
A better solution would be a renderer that's aware of whole objects and makes decisions on how to construct the final sorted set of triangles (or unsorted, or DX buffer object, or whichever fits the situation) with a broader awareness of the overall scene. That's one of the places where OOP and "interface first" thinking really shines, I think. I've done enough 3D engines the other way around to never want to do it again. ;) Nowadays I prefer to have a scene class, a hierarchy of classes for stuff that goes into a scene, then I have a renderer that attaches to a scene, and so on. And I'm happy to write class definitions for days before anything even compiles, because it really pays off in the end. I think. :)