Programming Paradigms and Lua/LÖVE

[Taehl]

Personally, I've noticed myself mixing paradigms pretty freely in my projects. Fortunately, Lua is perfectly happy with that. I generally end up making the "world" and the most time-critical code (such as player updates) in procedural style (for the best performance possible, and so I can control /exactly/ every step of everything), then add in some OO-style objects for less-critical elements (because OO stuff is generally a little easier to manipulate).

[clickrush]

I want to thank all you guys for your answers. So far I understand better when and why to use OO and I get now what functional programming actually means.

As for functionoal programming I see a very nice application for it:

Since they have to be mathematically true, they become completely harmless even if used globally and not as methods. Lets say we want to use pseudophysics:

Code: Select all

function movement(pos, speed)
 return pos+speed
end

function gravity(speed)
 return speed+2
end

--then in one object
(...)
player.hspeed = gravity(player.hspeed)

--in another object
(...)
enemy.hspeed=gravity(enemy.hspeed)

--etc.

This might look 'meh' but the cool thing is we don't have to worry about those functions as long as they are on the right side of '=' (an object cannot change the truth!). the gravity function can be very handy because you can pass it around everywhere you need it and you can simultaneously change the force (+2) for all objects.

If I can figure out a couple of those mathematically true functions then I would store then in a table so they are labeled. Like

Code: Select all

truth.gravity

. This goes very well along with one of the statements I earlyer made in this thread:

I believe in science and federalism. I believe that rightfulness is found in order with minimal hierarchy, as long as the beings or groups in that system seek for truth in a scientific way.

(It was the statement before robin advised to check out FP)

I believe the same could be done with collision checking. Collision response/resolution in the other hand is an 'inner' behaviour, a method, that you only pass around to children.

Personal note: With this approach my code feels much more natural without getting messy/dangerous. When I first started to notice what kind of ugly things I do while writing my code then I suddenly felt very intimidated to move on before I understand how to have an organisation that reflects my way of thinking. This is a huge step for me so thank you again everybody for discussing things here.

[kikito]

... lots of stuff ...

I'm afraid it's a bit more complicated than that.

Code: Select all

player.hspeed = gravity(player.hspeed)
enemy.hspeed=gravity(enemy.hspeed)

In a functional language, those two lines would give you an error, the second time you called them. Because you would be changing the value of variables, and that's just not possible in functional programming - variables, once set, are "constants". Like in math - when you resolve an equation, "x" is always the same number. As I told you it takes a while to get that idea "sink".

The obvious question is: how do you do anything with variables in functional languages, if you can't modify variables? Well, mostly you copy stuff around - you create new variables instead of rewriting the old ones. Then the language itself comes woith certain "tools" for common necessary things, like parsing lists, that don't require variable modification. That's it, rougthly. You will not be able to do functional programming in Lua, because it allows variable modifications and it doesn't have those "extra tools". The machine underneath is quite visible. To really grasp what functional programming is, I think you need to use a functional language for a while.

I would not call your way of doing stuff "functional", just "well organized imperative code". You are resolving small problems (i.e. calculating the effect of gravity) giving them names, and making them reusable in bigger problems ("calculate how a player or an enemy moves"). It's still a list of steps for a machine, not a bunch of logical abstractions. But that's nothing wrong

I'm enjoying this conversation a lot, but I will be taking a plane this evening and will likely not have access to a keyboard for a week, so if I don't answer to your next post immediately, don't take it the wrong way.

Regards!

[clickrush]

It would be fun to find out if and how you could make a game with a functional language. But that is not my goal anyway. I just extracted the part of the concept I like about it (mathematically true functions) to organise my code. I realize that the expression you quoted is imperative (and can be written in a OO fashion) but the function itself is the star here because I can use it everywhere without worrying about harm and OO (just as the math.something functions). This might be only a tiny obvious thing for others but for to me this is an awesome insight .

Here's what I learned so far:
- I see OO as a much more fluent concept. Now I see why and when poeple use it and even build classes.
- I like prototypes better up to this point, since I don't need classes for what I'am working on currently. The answers in this thread encouraged me to use degrees of OO as they are needed (=relief) and not just for the sake of it (which I couldn't stand!)
- I understand a part of functional programming is to have mathematically true functions (don't change state). I like this concept of a function because it is completely non-dangerous to gobally use them. The expression that embeds the function can often be imperative/oo as you explained above.

BTW: pls don't apologize for not being even nicer than you allready are lol. Having such a insightful discussion is a privilege for me.

[Robin]

In a functional language, those two lines would give you an error, the second time you called them.

What languages do that?

In those that I know, you have no variables, just functions, macros and constants. You can't have foo = x in a function, unless in a "let" clause, where redefinitions are perfectly fine, because they are not based on external state.

[bartbes]

I'd also like to mention that OOP is useful in other well-known programming principles, personally DRY comes to mind.
(DRY means Don't Repeat Yourself.)
DRY, as the name implies, means you try to not have duplicate code, and, in my opinion, classes can really help you out there. If a class is created "properly", it and its methods do something unique already, also, classes already are groups of methods, especially if you consider inheritance it is easy (for me) to see how classes can dramatically improve code re-use.

As an example I'll use DSM, one of my libraries made for state management, where everything that is an instance of either my State class, or one of its (user-defined) subclasses, is automatically a "valid" state, that then requires no extra work to "manage".

Another example is an entity system found in numerous (professional!) games, where every entity has a set of properties, like position and rotation, and a few methods (probably "die", move, that kind of stuff), everything that is a subclass of that, for example Player, can then just move without writing that movement code again, so, without the same/similar code to do the same thing.

EDIT: Well, that looks incomprehensible..

[clickrush]

well I don't have to understand the details to try to understand the concept. Basicly a code organisation/style has to be designed and there are different approaches to do so. OOP apparently helps to understand the program as a hierarchy/relationship of concepts such as the 'entity' example you made. I think DRY is pretty easy to understand but I have the suspicion that it's not so obvious to implement, as there can be alot of repetitions that may be hidden from a beginners perception. I think I understand why you say that OO helps in that regard, as the objects will look up things they need from others as long as they are properly structured.

In the other hand: Every higher level of organisation asks for a higher level of energy. I guess that can be said for programming paradigms as well? An obvious one would be recursion in functional programming vs for loops that change state. Another one is making a class-system in OOed lua. What kind of other inefficiencies do you encounter/know of and how do you evaluate them? (by energy i mean memory/cpu usage)

[kikito]

Hi, I'm back from holidays. Happy new year!

In a functional language, those two lines would give you an error, the second time you called them.

What languages do that?

You will get an error in reassignments in Prolog, Scala*, Erlang and Haskell.

*Scala throws an error if you declare the variables as "val". It also has "var" variables, which are just regular imperative ones. Scala plays in both fields at the same time.

What kind of other inefficiencies do you encounter/know of and how do you evaluate them? (by energy i mean memory/cpu usage)

The paradigm used, if well implemented and applied, adds very little overhead - in fact, in some cases it removes overhead instead. For example, Lua itself, in certain cases, is able to optimize recursive calls so they take no space in the stack.

Efficiency can ve viewed from lots of angles. My personal opinion is that a program clarity is much more important than efficiency. It's easier to optimize clear code than to clarify optimized code.

I'm very pragmatic regarding a program's speed: I ask myself is it "fast enough"? Meaning: Does it run at an acceptable speed in the target machine? If it does, job done. If it doesn't, I profile to see what parts need optimization, and I optimize those only. And then I profile again, to make sure that my optimizations are really optimizations, and I'm not just fooling myself. The most important improvements very rarely come from the paradigm used IMHO. If they do, you should notice when you profile your code. In the meantime, make it as clear as possible for humans.

[clickrush]

thank you for this link. This is interesting stuff!

I don't 100% buy what you're saying though . I assume you and other experienced programmers allready have habits that prevent slowness but you just don't think actively about them and you only actively make things more efficient when it's needed like you explained. But I guess this comes with practice? In the other hand I like your suggestion to put readability over efficiency when possible.