53 replies to this topic

[Orwell]

ChunLing, on 09 January 2013 - 07:44 AM, said:

Method. Interaction methods. And yeah, that's the exact sticking point for me.

Its not clear to me anymore which point of view your defending. But methods are per definition object oriented.

There are people with authority in the field that swear by procedural programming and don't want to know about OOP. Alexander Stephanov, the creator of the STL library in C++ once stated this:

Quote

"I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work."

[RunasSudo-AWOLindefinitely]

EDIT: An extract from Head First Java about OOP vs POP: http://bit.ly/UMUMIv

ChunLing, on 09 January 2013 - 07:14 AM, said:

that's not how I view humans

How would you represent, let's say a Human and a Pig in a data structure? Your code should be able to do anything my code can do.
My (loose) Java code follows:

Animal[] dataStructure;

abstract class Animal {
  final void speakData(String data) { print(data); }
  void speak() {}
  void move() { x += 3; }
}
class Human extends Animal {
  void speak() { speakData("Morning Guv'nor!"); }
  void walk() { move(); }
}
class Pig extends Animal {
  void speak() { speakData("Oink!"); }
  void trot() { move(); }
}

Edited by RunasSudo, 10 January 2013 - 01:51 PM.

[ChunLing]

The point is that I wouldn't represent a human at all. Or a pig. Not in any way that made a fundamental, categorical distinction between the two at the level of how I should deal with a particular instance of either. I don't know whether that's "philosophically unsound" or not, it's just that I wouldn't...or perhaps I simply can't. It's not a point I'm defending so much as a complaint I can't address to anyone in particular, because I wanted to say something complementary about the very good opening post but the topic is just one that doesn't sit right with me. In programming, even more than in real life, the imposition of a particular and rather irrational conceptual framework is...an unpleasant reminder of something unpleasant that I will not share anymore than can be divined from what I've already said.

On an unrelated note, Alexander Stephanov might be an authority in his field, but he should avoid making careless statements about mathematics. I don't believe it inexcusable for programmers to be somewhat ignorant about mathematics, but there are limits to what one can and cannot say without trespassing the bounds of complete nonsense.

[theoriginalbit]

ChunLing, on 09 January 2013 - 05:53 PM, said:

the imposition of a particular and rather irrational conceptual framework

you know I was just thinking. Even other professions use classifications that can be thought similar to OO. For example Biologists classify living things by categories like mammal, marsupial, insect, etc... For example a monkey is a mammal, and a biped, a human is also a mammal and a biped, however a Platypus is a mammal but not a biped. Now if i was representing those animals in code, they classifications/modules would remain the same.

EDIT: If I were to attempt this in procedural programming.... well I wouldn't, I'd go for OO in a heartbeat...
I do understand that some people don't like OO, but in the end, sometimes it is better to use.

Edited by TheOriginalBIT, 09 January 2013 - 06:04 PM.

[ChunLing]

I don't mind classifying things, the part that gets me is restricting the methods available for use by the class of "object" you're dealing with. Humans are notably different from pigs/insects/trees, this doesn't mean that there are no particular cases where it would be most appropriate to interact with one in a manner that would be more usual for the other. And being restricted from doing so is galling when that situation arises.

[theoriginalbit]

ChunLing, on 09 January 2013 - 06:37 PM, said:

the part that gets me is restricting the methods available for use by the class of "object" you're dealing with.

To put it back to a real life context... What would happen if someone could just walk up to you and change anything about you, nothing about you is private, nothing is hidden, they have access to everything. What if they swapped your liver and stomach, then you tried to live and couldn't because someone had messed with you. Encapsulation is the prevention of people messing with stuff you don't want them to, because sometimes, if people do, then problems arise. And I quite like OO for this reason!

[immibis]

ChunLing, on 09 January 2013 - 05:53 PM, said:

The point is that I wouldn't represent a human at all. Or a pig. Not in any way that made a fundamental, categorical distinction between the two at the level of how I should deal with a particular instance of either. I don't know whether that's "philosophically unsound" or not, it's just that I wouldn't...or perhaps I simply can't. It's not a point I'm defending so much as a complaint I can't address to anyone in particular, because I wanted to say something complementary about the very good opening post but the topic is just one that doesn't sit right with me. In programming, even more than in real life, the imposition of a particular and rather irrational conceptual framework is...an unpleasant reminder of something unpleasant that I will not share anymore than can be divined from what I've already said.

You're writing Minecraft. Humans and pigs are both entities. They might not share a lot, but they both have a position, need to be synced with clients, need to be saved and loaded, etc. How would you do that?

[ChunLing]

Well, java is object oriented, so of course I'd have to use classes.

But I wouldn't like it.

Also, IRL, the way I live it, having people come up and decide to rearrange my anatomy so as to discontinue my life processes is...one of those things I've learned to live with (not sure if that counts as a pun).

Edited by ChunLing, 10 January 2013 - 08:52 AM.

[Orwell]

ChunLing, on 10 January 2013 - 08:51 AM, said:

Well, java is object oriented, so of course I'd have to use classes.

But I wouldn't like it.

Also, IRL, the way I live it, having people come up and decide to rearrange my anatomy so as to discontinue my life processes is...one of those things I've learned to live with (not sure if that counts as a pun).

You're kind of avoiding the question. How would you implement what Immibis asked in C++ without OOP? Or even better, how would you go about implementing that in C, which practically has no OOP?

[billysback]

immibis, on 10 January 2013 - 01:08 AM, said:

You're writing Minecraft. Humans and pigs are both entities. They might not share a lot, but they both have a position, need to be synced with clients, need to be saved and loaded, etc. How would you do that?

make a function which copies an array containing the data of both entities, changing the entity data that is required to change, have template arrays for each entity so that when you wish to run the function you can give it the template in one array and the relevant data in another, the function can then combine the two arrays in a sensible way and return you the result, you could then improve this to allow multiple templates, the templates at the front get the highest priority in the array listings. This way you could have a pig inherit "entity" "livingentity" and "pig" as well as the relevant information such as its location.

to sync it with clients encrypt each array in to a string then send the string off to the client, the client un-encrypts it and packs it back in to an array, if it already exists in the client send the entities ID and the changes encrypted.

to save and load encrypt and write each entity's array.

EDIT:
by the way, I don't really understand what this argument is about, is chun ling arguing that OOP is unnecessary or that it is almost insulting to strip down real world entities such as humans in to simple methods and variables, which to him are an unfair representation?

[nitrogenfingers]

immibis, on 10 January 2013 - 01:08 AM, said:

You're writing Minecraft. Humans and pigs are both entities. They might not share a lot, but they both have a position, need to be synced with clients, need to be saved and loaded, etc. How would you do that?

Interfaces. Humans and Pigs share common fields and methods, exactly as you say, but inheriting from a superclass limits flexibility in both implementations. Pros and cons though, Interfaces retains polymorphism and has that flexibility, though you will usually have to write more code.

That's my main gripe with the OO paradigm, being restrained to the rules defined by the parent. If you want to insert something that fits the paradigm but not the implementation you have to either modify the superclass (opening back doors or possibly destabilizing other child classes), restrict what you want your new class to do, or start afresh. I guess OO works for much more detailed, strictly designed software, if you in SE and follow the waterfall or something, but most of us are agile programmers and I don't find the paradigm conducive to that design methodology.

Of course that's just an opinion, and it's an interesting subject for debate but I think this sort of thing is quite subjective.

[Orwell]

Interfaces are abstract classes and thus are per definition OO as well. My impression from the thread is that people are holding to strong to representing physical objects with OO. I got an exam on my course 'advanced programming' next week, so I got a lot of the theory fresh in my head. According to my text book, an object is defined by behavior, state and identity. When you are decomposing a problem and you can easily arrange it to concepts that define these 3 conditions, then OO seems like a wise choice to me. Those don't need to be physical objects, it can be vectors and points to do affine calculations for example. Also, in most cases, when working on larger projects, OO keeps things much more manageable. For smaller projects, like most CC programs, this hardly matters. (though, CC API's are often used in a OO way as well, like the term, fs and http api).

But in the end, it all starts at the problem decomposition. When it's easier to decompose it into smaller sequential problems, then the procedural paradigm is certainly a wise choice. I encounter this mostly with algorithms. On the other hand, when you can model the problem using concepts and types, OO would be the only smart choice. I'm working on Bounding Volume Hierarchies and GJK at the moment, I wouldn't know how I could ever implement that without OO.

A last note: While typing this, I realize that even in procedural programming in Lua, we are bound to use OO in some extent. File handlers for example are objects and I'm sure there are other objects you use in most programs.

[RunasSudo-AWOLindefinitely]

I just feel like pointing this out again:
http://bit.ly/UMUMIv
An extract from Head First Java about OOP vs POP.
Highlights the fact that some (but not all) programs just simply are less complicated in OOP.

[ChunLing]

See, I'm not opposed to having different types of data that are basically treated in different ways. I do sometimes want to turn strings into numbers and vice versa, but as long as I can I don't mind that strings and numbers are fundamentally different. In fact, I think that my fetish for maintaining type on a variable in Lua is somewhat unusual, judging by a lot of the samples I see.

So I don't have a problem with using classes to represent highly abstracted data objects, as long as there are methods that allow me to get/set (directly or indirectly) all the data in it's basic forms.

But the whole point of object oriented programming, what makes it different from normal use of arrays of data to represent things, is that you implement methods that are restrictive of what you can get or change (and how you can change it). Which may very well be a practical necessity in large projects to avoid having a poorly written section of the code screw things up for everyone else (and here we really are talking about people with markedly different skill levels all coding on the same project), but the fool-proofing....

Reminds me of some things that I'd as soon not talk about. I guess that makes it a bit of a conversational dead end.

Yes, there is also the issue of sheer elegance, unrestricted access to program data just lets you do things in a cooler way, generally and in many particulars. So we'll pretend that's what I'm on about and call it a day. Objects impose a clunky limitation on flexible data access, and the absolute benefits are limited (in pure computational theory, they don't exist at all, objects are purely drawbacks).

[immibis]

ChunLing, on 10 January 2013 - 08:44 PM, said:

See, I'm not opposed to having different types of data that are basically treated in different ways. I do sometimes want to turn strings into numbers and vice versa, but as long as I can I don't mind that strings and numbers are fundamentally different. In fact, I think that my fetish for maintaining type on a variable in Lua is somewhat unusual, judging by a lot of the samples I see.

So I don't have a problem with using classes to represent highly abstracted data objects, as long as there are methods that allow me to get/set (directly or indirectly) all the data in it's basic forms.

But the whole point of object oriented programming, what makes it different from normal use of arrays of data to represent things, is that you implement methods that are restrictive of what you can get or change (and how you can change it). Which may very well be a practical necessity in large projects to avoid having a poorly written section of the code screw things up for everyone else (and here we really are talking about people with markedly different skill levels all coding on the same project), but the fool-proofing....

Reminds me of some things that I'd as soon not talk about. I guess that makes it a bit of a conversational dead end.

Yes, there is also the issue of sheer elegance, unrestricted access to program data just lets you do things in a cooler way, generally and in many particulars. So we'll pretend that's what I'm on about and call it a day. Objects impose a clunky limitation on flexible data access, and the absolute benefits are limited (in pure computational theory, they don't exist at all, objects are purely drawbacks).

You don't have to make all your fields private. And you'd still be using OOP if you didn't.

[ChunLing]

Yes and no. Yes, you're still using an Object Oriented programming language, but no you're really not using it for object oriented programming anymore if you bypass the essential difference between object oriented programming and non-object oriented programming. But it's not exactly like trying to eat soup with a knife and fork, or steak with a spoon.

[immibis]

ChunLing, on 11 January 2013 - 01:50 PM, said:

Yes and no. Yes, you're still using an Object Oriented programming language, but no you're really not using it for object oriented programming anymore if you bypass the essential difference between object oriented programming and non-object oriented programming. But it's not exactly like trying to eat soup with a knife and fork, or steak with a spoon.

Just because you're not using every feature of OOP doesn't mean you're not using OOP. In the pig/human example, you'd still be using inheritance (both extend Entity to get the common behaviour of entities) and polymorphism (if you call ent.save() it saves all the relevant data, including the inventory of a player or the breeding cooldown of a pig).

It'd be more accurate to say you're not using encapsulation than to say you're not using OOP.

Edit: As far as I care, if you're using objects, and your methods are inside your objects (eg you have Entity.save instead of a global save_entity) you're using OOP. Even Wikipedia doesn't have a precise definition of what is OOP and what is not.

[ChunLing]

Sure,, it's a gradient. And on one end is "I can program naturally in this model" and on the other is "why the heck can't I get/set this value?".

[RunasSudo-AWOLindefinitely]

ChunLing, on 12 January 2013 - 04:03 AM, said:

why the heck can't I get/set this value?

If something is set as "private" or "protected", there's usually a good reason for it (validation, need to keep track of stuff, etc) and you can usually get it in some form or another through some method. But, if you reealllly want to...

Object getPrivate(Object obj, String field) {
  Field f = obj.getClass().getDeclaredField(field); f.setAccessible(true);
  return f.get(obj);
}

Other languages probably have a better way of doing it, but whatever.

EDIT: Derp, spent so long in Lua I forgot the semicolons. And I wrote "function". And I forgot the return type. And I wrote "end".

Edited by RunasSudo, 12 January 2013 - 01:26 PM.

[Orwell]

RunasSudo, on 12 January 2013 - 01:15 PM, said:

ChunLing, on 12 January 2013 - 04:03 AM, said:

why the heck can't I get/set this value?

If something is set as "private" or "protected", there's usually a good reason for it (validation, need to keep track of stuff, etc) and you can usually get it in some form or another through some method. But, if you reealllly want to...

Object getPrivate(Object obj, String field) {
  Field f = obj.getClass().getDeclaredField(field); f.setAccessible(true);
  return f.get(obj);
}

Other languages probably have a better way of doing it, but whatever.

EDIT: Derp, spent so long in Lua I forgot the semicolons. And I wrote "function". And I forgot the return type. And I wrote "end".

Not that many languages support something like reflection. I sure as hell know that C++ doesn't. But well, you just make a getter and/or a setter where needed and only where needed.