New language features have a place in game code?

[LP]

Code should aid the programmer in their creations, not take them over. My advice is to be cautious when adding code to your game projects that are in-progress that is new to you. It's great to learn new things, but to actually finish a project, you need to pace yourself and don't over-exceed your knowledge with research beyond what is needed to complete your current project should you actually wish to finish it.

I agree, there is YAGNI principle that describes exactly that.

Let's imagine a fisherman: He uses a sophisticated trawl with a GPS, a super-tech radar to track the fishes and he is fishing with nets to gather as many fishes as he can to make the living, but during weekend he prefers his little boat and a simple hook because he likes fishing this way. He'll gather less fish, or he 'll need more time to gather many fishes, but he'll enjoy it!

In this case, OOP is the little boat and a simple hook, which later you can upgrade to GPS and super-tech radar. But, you are trying to fish with a fork swimming in an inflatable toy. Sure, it can be a fun sport, but you won't get much fish, if any.

P.S. Jimmy, please try not to get offended, there is no need to multi-quote everything and argue about what you don't know or don't fully understand (remember unskilled and unaware article). My suggestion to you was to try and learn new things, which could be fun and you might even get surprised.

The fact is, you can use OOP for the smallest applications and create elegant code, that later you can extend, modify and even reuse. If you "think procedural" and use OOP mostly as a data type (e.g. objects for data) or only because you have to, this approach is called anti-pattern. If you want to keep closed-minded about it, nobody is forcing you to try new/better ways, just keep using what you know.

[Jimmy Valavanis]

It's really difficult not to get offended when someone deliberately offends you

[Carver413]

Its time's like this when you wish there was an ignore button. don't let it get you down Jimmy some people just don't know when to quit.

[WILL]

I don't think that Lifepower meant to be offensive. I've seen him being offensive, this really isn't what I'd categorize it as. (Sorry Yuriy, it's sort of a defense though. ) He just has some strong opinions about code, which is fine, it's primarily a coders forum after all. OOP has it's benefits, yet learning new things does sometimes get in the way of progressing with active projects. Even news ones so I can see why you aren't crazy about the idea of taking up something new. There is validity there.

If you find you are able to do what you need with your own coding knowledge then stick with it until you feel you want to dig deeper into the rabbit hole. Should you want to learn a more advanced coding style, there is benefit in learning OOP. So when or if you become ready for such, Lifepower's suggestions would help you in that way. I think this is where he was going with it, not meaning to tear your skills apart and tell you you are doing it wrong. Just explain to you that it is an older way and there are much newer ones that have been developed since.

[LP]

It's really difficult not to get offended when someone deliberately offends you

Can you please send me a PM mentioning what parts of my post did you find offensive? I'm sorry but it was not my intention. I can erase my post, if you wish. In most cases I'm just trying to be direct and straight to the point. My intention was to help/recommend. However, it was not me who was flashing thesis works and books; I think you should put away the pride and chill.

[WILL]

As much as I like a good case scenario to try for problem solving, this is getting a tad off topic. Why not start another thread about Object Oriented Programming vs. Procedural Programming?

UPDATED: Ok I pulled the trigger on it. Sorry, but I had to move it to a new thread. New area of discussion, new thread that's how we roll at PGD. Sometimes small deviations are ok, but not huge full throttle shifts in topic completely. Yours was a doozy.

However here is the link to the new thread. We do believe in convenience. All are welcome to beat each other to a pulp there. ...just do it nice and politely or I'll send the evil Google preview after you.

[WILL]

Getting this thread back on topic however, I am interested to see what kind of new language features that Oxygene will bring as it continues to evolve into it's very distinct language.

Is there a feature you would like to see added to any of the existing Pascal-based languages or dialects?

[Eric]

At the risk of starting another flame war, I would say some form of templates could be very useful. C++-like templates.

Generics are all fine and dandy when it comes to containers, but beyond those, they quickly become quite messy & unwieldy. Also they favor bloat-ware/code complexity on the generated binary, which isn't very desirable for games.

For games, the downsides of templates (weird, hard to understand compile-time errors) would matter much less than their benefits.

For those that don't know the difference, it can be summarized by saying that a generic can be syntax-checked on its own (outside of any specialization), while a template is closer to a macro, that is syntax-checked on specialization.

For instance, suppose you want to add two "things", with templates, you can write just:

function Add<T>(a, b : T) : T;
begin
   Result := a + b
end;

It'll work for Integer, String, Double, or anything for which you overloaded the + operator (like vector records/static arrays).
And you'll get an error for things that don't support the + operator, like Add<Boolean>.

But it won't work for generics, as a generic type T can't always be added... so you'll get a compile-time error on the generic.
To make it work, you have to add an interface and a constraint:

type IAddable<T> = interface
   function Add(b : T) : T;
end;

function Add<T : IAddable<T>>(a, b : T) : T;
begin
   Result := a.Add( b );
end;

but then it'll only work for generic classes that implement the generic IAddable interface, it won't work for simple types, records or arrays unless you box them.

It also makes a simple generic sorter a creation of hideous complexity, as you'll need a generic IComparer<T> (cf. the RTL source...), while writing a template-based sorter can be trivial. Same goes for most algorithms. Soon enough, you find yourself piling up generic interfaces.

Now, all isn't rosy with templates, as templates can use other templates, so it's possible to get at the specialization errors that relate to a sub-sub-sub-template of the template you're using, with an error message that can be eminently cryptic because it bears only very indirect relation to what you were trying to do.

[LP]

At the risk of starting another flame war, I would say some form of templates could be very useful. C++-like templates.

Generics are all fine and dandy when it comes to containers, but beyond those, they quickly become quite messy & unwieldy. Also they favor bloat-ware/code complexity on the generated binary, which isn't very desirable for games.

I think the Duck Typing concept that Jason mentioned at the beginning is similar to the templates that you are describing. Even though you sacrifice maintainability and readability for a more compact code, I think they could be much more useful than generics. Also, you can do some weird things with C++-like templates.

[Eric]

I think the Duck Typing concept that Jason mentioned at the beginning is similar to the templates that you are describing.

Not really, duck-typing is a form of implicit interfaces (and that's how Oxygene implements them under the hood btw), the C++ templates are more of a form of restricted macros, which can recursively reference each other.

Another aspect is that templates are (as far as C++ goes) fully resolved at compile-time, while duck-typing can often be resolved only at run-time. So duck-typing is usually tied to dynamic typing, and for strongly typed languages, it involves some form of RTTI.