Proceural Programming vs. Object Oriented Programming

[SilverWarior]

Hey guys! I think we are being unfair to Jimmy Valavanis myself including.
We acused him of using bad programing approach, of making ineficent code, of spending more time coding somethink that we belive it could be done faster in our way (OOP aproach) and we done all this without any relavent facts. We haven't seen any of his coding. What gives us right to judge him in the way we do?
So why don't we alow him first to prove himself solving a real problem in practise and only then judge him.
I will present problem below (the problem can be easily solved using OOP aproach) and I hope Jimmy would be so kind to take some of his time to show us how he would solve it. Maybe we will even learn something from him. Isn't that the purpose of our comunity - to learn.
Now Jimmy if for some rason you don't want to publicly participate in this I still hope that you take some time and send me solution for the problem below using your approach. I would realy like to see how it can be done in procedural way becouse I cant imagine how myself. Maybe I will learn something.

The problem is as folows:
Lets say you are creating a strategy game. In this game there are several different unit types. Your goal is to write a code wich will define these unit types as specified below.
For the sake of simplicity lets say that the gameworld is respresented with two dimensional array (tiles). These are defined like so:
0 for unpasable terrain
1 for land terrain
2 water terrain
3 for deep water terrain

Unit types are like this:
1. Land unit capable of atacking other land units
2. Land unit capable of atacking air units
3. Air unit capable of atacking other air units
4. Air unit capable of atacking land units
5. Air units capable of atacking submersible units
6. Naval units capable of atacking other naval units
7. Naval units capable of atacking submersible units
8. Submersible units capable of atacking other submersible units
9. Submersible units capable of atacking naval units
10. Submersible units capable of atacking land units.

Your code also need to make sure that these units can move properly (prevent ilegal moves)
1. Land units can move only on land
2. Naval units can move only on water
3. Submersible units can only move in deep water when submerged
4. Air units can move anywhere

Naturally each units have his health so this should also be covered in your code.

If you wish I will show you all how I would solve this problem myself using OOP aproach. I could also try to explain the benefits of using OOP in this case.

[SilverWarior]

Why not start another thread about Object Oriented Programming vs. Procedural Programming? :)

I will wait Jimmy's response for now. Afterwards I will move all the posts relating to this matter to a new topic as you sad.

[Eric]

Lets say you are creating a strategy game.
...
If you wish I will show you all how I would solve this problem myself using OOP aproach.

I'm not sure exactly how the constraint you enumerated would favor an OOP approach on their own, as they're basically boolean truth tables.

That said, such a game certainly favors a modular approach (to handle the various actions and movement cases), a database approach (to hold the zillions of parameters that would describe the characteristics of all the units in an easily editable fashion) and a scripting approach (for general AI and all scenario-specific behaviors about where/when things should move, what/how they should prioritize in their attack, etc.).

On the other hand, I've known this kind of problems to be a good trap for "by the book" class hierarchies, as the best way to approach that problem with OO is IME not the one obvious to beginners. The common errors being not to differentiate actions from behaviors, and implementing those as methods of the entities rather than as distinct class hierarchies.

[SilverWarior]

Hey Eric you are free to present me with a third option for solution. I'll be glad to see it and study it. I bet I could learn something from it.

[Ñuño Martínez]

Why not start another thread about Object Oriented Programming vs. Procedural Programming? :) I think there's no difference with "C Vs. Pascal" or "Windows Vs. Linux Vs. Mac" threads, a "religious war" that doesn't benefit nobody.

[Eric]

I think there's no difference with "C Vs. Pascal" or "Windows Vs. Linux Vs. Mac" threads, a "religious war" that doesn't benefit nobody.
Quite likely...

[pitfiend]

Come guys, why you need to be that strict? As I see it, there's no sacred war here, the proposal is to learn from different aproachs on the same problem. Any of us can come with a brilliant solution to it, don't you think? Let's work on enlightment instead of senseless fight between us.

[LP]

The conversation becomes religious when people start to take things to the heart and personally. I think everyone should be aware that it's just a conversation between developers, to help each other with advice and share opinions; it is not an award/diploma/social_status/recognition contest.

In certain occasions I've mentioned Unskilled and Unaware (http://www.damninteresting.com/?p=406) article, but it wasn't to say that someone's stupid, but because it's an interesting read and a useful study that says that we should be careful, especially in areas where we feel more confident in. It has numerous applications, not only in programming, but in life in general: in economy, politics, sports, car driving, gaming and even women!

Procedural approach has its uses, especially in low-level frameworks, and I was not trying to prove that OOP is an answer to everything. However, while developing typical applications, starting from hello world and ending with large enterprise software, OOP is typically used. In fact, some languages would not allow you to work otherwise: C#, for instance, is very class-driven and working strictly procedural can be difficult.

I've seen people, especially those who grew in Fortran age, to incline more into procedural ways and be wary of any modern programming techniques and tools. I myself have worked in procedural and even in assembler quite a lot, but I think you shouldn't fear to leave your comfort zone and try to learn something new. Who knows, you might even have some fun. ;)

[pitfiend]

I've seen people, especially those who grew in Fortran age, to incline more into procedural ways and be wary of any modern programming techniques and tools. I myself have worked in procedural and even in assembler quite a lot, but I think you shouldn't fear to leave your comfort zone and try to learn something new. Who knows, you might even have some fun. ;)

That for sure. Some months ago, I find myself explaining the benefits to use an rdms instead of flat tables, my customer grown up working with isam files in times of mainframes, cobol and punched cards. When I show him the virtues of visual development and sql language, he was in shock. Right now (6 months after) he still wonders about why he didn't have this nice tech on his time.

Learning is a continual process. No matter if you are 80 years old, if you stop learning, you're dead and wasting our time. Sorry if it sounds rude, truth is rude, life shows no mercy for the weak.

This non-sense is going weird.

[Eric]

That for sure. Some months ago, I find myself explaining the benefits to use an rdms instead of flat tables
Same level of shock happens IME when you're trying to explain "NoSQL" and "eventual consistency" to RDBMS users. ;-)

[User137]

Unit types are like this:
1. Land unit capable of atacking other land units
2. Land unit capable of atacking air units
3. Air unit capable of atacking other air units
4. Air unit capable of atacking land units
5. Air units capable of atacking submersible units
6. Naval units capable of atacking other naval units
7. Naval units capable of atacking submersible units
8. Submersible units capable of atacking other submersible units
9. Submersible units capable of atacking naval units
10. Submersible units capable of atacking land units.

Your code also need to make sure that these units can move properly (prevent ilegal moves)
1. Land units can move only on land
2. Naval units can move only on water
3. Submersible units can only move in deep water when submerged
4. Air units can move anywhere
I do not see how this couldn't be done in non-OOP way very easily. Anything that programmer tries to justify by objects, the non-OOP programmer can explain with pointers. Your list of 1-10 is irrelevant, your unit can simply have like:

unit: array of TUnit; // TUnit record containing all different kinds of units, and target indexes
Movement can simply be a comparison between unit type variable and land grid at its location.

I mean, the example above is hardly enough to light up a "war" between the approaches, as it is too simplistic :p

[SilverWarior]

Maybe I haven't chosen the best example.
Currently I'm workning on a code for a strategy game I might develop sometime. In my game units will be made from various parts (drivetrain, chasis, weapons, shields, utilities, etc.). I'm using OOP approach becouse it alows me to change some units parts just by changing pointers to point to apropriate clases wich represent various parts. Also this way I gat the ability to have some custom methods wuch are being used by this methods (different way of calculating defense for various unit types - some have uniform shield others have directional shields).

[LP]

I do not see how this couldn't be done in non-OOP way very easily. Anything that programmer tries to justify by objects, the non-OOP programmer can explain with pointers.
Indeed, you can transform one approach into another and vice-versa. In fact, when program is compiled, both procedural and OOP are converted into primitive instructions: CPU itself knows nothing about objects and/or records. So this is not very relevant here.

The argument is about qualitative attributes between different approaches when used in typical applications.

Actually, an interesting topic is that in both Delphi and FreePascal you can use units as if they were objects: they have public (interface) section, private (implementation) section, constructor (initialization) and destructor (finalization). This makes the language somewhat unique, since the entire project is divided into object/namespace hybrids (units) that may have other objects inside.

[Jimmy Valavanis]

I wrote some prototyping code to solve the above problem, it's the text attachment. I didn't use OOP

[User137]

Hmm, that looks way more complicated than i had in mind. Also pay attention to memory usage! Do you have 2 billion different terrain types, or could you decide texture by just that terrain type instead of separate variable? Is the collision list required?

terraintile_t = record
texture: integer;
terraintype: integer; // 0(unpassable), 1(land), 2(water), 3(sub) - Also could be set as a compination of FLG_xxx flags with 0 as unpassable for easier checking using bitwise or
blocklist: unit_p; // colision list linked with unit_t.nextsamatile
end;

I would plan something like this:

const
MAX_UNIT_TYPES = 10;
MaxLandW = 256;
MaxLandH = 256;

type
TUnitType = (utLand, utAir, utNaval, utSub);

TUnitInfo = record
ut: TUnitType;
attLand, attAir, attNaval, attSub: boolean;
maxHP, movespeed, acceleration: single;
end;
PUnitInfo = ^TUnitInfo;

TUnit = record
info: PUnitInfo;
position, movement: TVector2f;
HP, rotation: single;
target: integer; // Target index from unit-array
end;

var
land: array[0..MaxLandW-1, 0..MaxLandH-1] of byte;
unitTypes: array[0..MAX_UNIT_TYPES-1] of TUnitInfo;
unit: array of TUnit;
uCount: integer;
...
Then just initialize by filling details to unitTypes for 10 ship types. Give pointer to needed unitType when adding a new unit. And i'm missing guns and stuff for now...

[Ñuño Martínez]

Come guys, why you need to be that strict? As I see it, there's no sacred war here, the proposal is to learn from different aproachs on the same problem. Any of us can come with a brilliant solution to it, don't you think? Let's work on enlightment instead of senseless fight between us. Actually I'm not so strict. I often mix procedural and object oriented in my programs (I call it "structured using objects"). But there are a lot of people "out there" that use the computer as if it were a religion. Specially if they're C++, C# or Java programmers.


Actually, an interesting topic is that in both Delphi and FreePascal you can use units as if they were objects: they have public (interface) section, private (implementation) section, constructor (initialization) and destructor (finalization). This makes the language somewhat unique, since the entire project is divided into object/namespace hybrids (units) that may have other objects inside. Good point. I've planned some projects that way. And it works.

Oberon goes away within the same concept. In Oberon there's no a "main" unit. All "units" are actually "programs" or better "objects" with public and private "sections" that may or may not depend to each other. When you executes an Oberon program you actually "loads" an object "instance" and calls a method. Much like Small-Talk but different.

[Colin]

OOP in most cases is going to produce slower code, so its a weigh-in between speed of development vs performance of the finished application.....the fact that Mr. Valavanis can code without an influence of an OOP approach is commendable, and in-fact it is an advantage over others, I would personally hire such a programmer.

[Ingemar]

So why don't we alow him first to prove himself solving a real problem in practise and only then judge him.
I will present problem below (the problem can be easily solved using OOP aproach) and I hope Jimmy would be so kind to take some of his time to show us how he would solve it. Maybe we will even learn something from him. Isn't that the purpose of our comunity - to learn.
Now Jimmy if for some rason you don't want to publicly participate in this I still hope that you take some time and send me solution for the problem below using your approach. I would realy like to see how it can be done in procedural way becouse I cant imagine how myself. Maybe I will learn something.

The problem is as folows:
Lets say you are creating a strategy game. In this game there are several different unit types. Your goal is to write a code wich will define these unit types as specified below.
For the sake of simplicity lets say that the gameworld is respresented with two dimensional array (tiles). These are defined like so:
0 for unpasable terrain
1 for land terrain
2 water terrain
3 for deep water terrain

Unit types are like this:
1. Land unit capable of atacking other land units
2. Land unit capable of atacking air units
3. Air unit capable of atacking other air units
4. Air unit capable of atacking land units
5. Air units capable of atacking submersible units
6. Naval units capable of atacking other naval units
7. Naval units capable of atacking submersible units
8. Submersible units capable of atacking other submersible units
9. Submersible units capable of atacking naval units
10. Submersible units capable of atacking land units.

Your code also need to make sure that these units can move properly (prevent ilegal moves)
1. Land units can move only on land
2. Naval units can move only on water
3. Submersible units can only move in deep water when submerged
4. Air units can move anywhere

Naturally each units have his health so this should also be covered in your code.

If you wish I will show you all how I would solve this problem myself using OOP aproach. I could also try to explain the benefits of using OOP in this case.

I think this is a wonderful idea!

Actually, I recently proposed a slighly similar student project, although geared towards comparing languages. Same idea, stop bickering and get down to the facts, write some solid code for each case and compare, as objectively as possible (pun not intended). But your description goes a good step closer, by specifying pretty well what it should be, I like that. Maybe we should make a common base of graphics and sounds? And map? Same size, same data.

The big question is whether this is the right problem, but maybe it is. A few rules are missing though: Can there only be one unit in each space? Do you attack by moving into an occupied space? Are there hit points, strengths? What odds should there be? Winning conditions? Game menus, save files (should be mandatory or forbidden, no optionals)?

Of course, one of the biggest arguments in favor of procedural programming is performance, and we will get no difference for this case. We would need a problem with high complexity and large data sets for that.

I am tempted to write one or even two approaches to the problem. I think you need several. There is more than procedural-vs-OOP, there are several approaches in each, and it is perfectly possibly to write lousy code for both cases.

One more thing: The evaluation should preferably be positive and open-minded. That isn't very easy to do. It is so easy to flame the way that isn't "my own", but I think it is better to speak about advantages than pinning down what we think is bad. Objective, and absolutely avoid getting personal. But the way you state your intentions, I think you are on the right track already.

So what do you say, is the "tile-based naval game" idea the right one to try? I'm in if you want, just let's get a bit more exact on the rules so we write the same game.

[SilverWarior]

When I presented the problem I had no intention for making whole game. My intetntion was to present an opurtunity for Jimmy to show how he would solve this problem using his approach. This would then alow us to have some constuctive debate on comparison between OOP oriented programing and Procedural oriented programing.

[Ingemar]

When I presented the problem I had no intention for making whole game. My intetntion was to present an opurtunity for Jimmy to show how he would solve this problem using his approach. This would then alow us to have some constuctive debate on comparison between OOP oriented programing and Procedural oriented programing.

But I think it can be made, written, working, in reasonable time if the problem is well-defined and with precise limits. I can write that in, well, say two days. Maybe one if I can focus well and the specifications are strict and complete (and limited enough).

The question is, of course, if such a short project would produce anything meaningful.

[Ingemar]

Rats, I thought this sounded so nice and creative, but it went all silent. But I guess we all are thinking/coding the 2PGDC. OK, so there will be no closer-to-scientific comparison this time either. But I will take the ideas to the upcoming stundent project(s) and maybe we can do something there. (It will probably be C vs C++ then, because nobody here teaches Pascal. The whole CSc department sold out to Sun long ago. Another story.)

[SilverWarior]

But I guess we all are thinking/coding the 2PGDC. OK, so there will be no closer-to-scientific comparison this time either.

There won't be at the moment. But after the competition ends I do hope that it will come to that.

[Ingemar]

There won't be at the moment. But after the competition ends I do hope that it will come to that.
OK, we'll continue then. It could turn out to be interesting. Damn tricky comparison but it could be a better one than I ever saw before.

[Ingemar]

I have a meeting with a student in a few minutes, to discuss his diploma thesis. My initial proposal was to do a multiple game implementation to compare languages, but now I will discuss a different idea, OOP vs procedural, including DOD (data oriented design). I take the liberty to use ideas from this thread. :)

[Eric]

but now I will discuss a different idea, OOP vs procedural, including DOD (data oriented design). I take the liberty to use ideas from this thread. :)
Interesting, but I would rate doing both a procedural and an OOP version of the same thing by the same guy as "difficult": the ideas and approaches of both will bleed on each other, chances are you'll either get an OOP version that doesn't really leverages OOP, or a procedural version that mimics a poor man's OOP, depending on the writer or the order in which they're written...