Programming Paradigms and Lua/LÖVE

[clickrush]

Ok I'am starting to understand OOP's concepts and it's usefulness, so I want to have a little discussion about this and any other styles that you guys use and why. Let us start with a survey kind of thing:

1. What I don't grasp yet is the need of classes. In PiL it says that OOP in Lua can be done with prototypes instead of classes. Up to this point creating a class system seems to be additional effort for the sake of what? Is prototype based OO worse? Who uses one of those/both paradigms and why?

2. I'am currently reading a Java book to get into OOP (since it seems to be the most used language with the OO paradigm). It looks like not even Java is 100% strict with the OO. C++ is a widely used language for programs that need to communicate more directly with the machine it's running on, such as game engines (as well as LÖVE). In the internet C++ is labeled as a 'hybrid-language'. In the java book (core java vol.1) I'am reading C++ is even considered as "...a bad dream of which you'd rather not be reminded." And on the internet I've even found descriptions like "warzone" and similar lol. Where does Lua stand in comparison? It seems that you can go for both extremes (purely procerudal and purely OOP). So a better question would be: How do most people program with it? Are there other paradigms that are widely used?

3. I've skimmed through some similar threads and apparently not all of you are very strict with OOP in their code. Where do you draw the line and why?

4. Especially LÖVE doesn't seem to promote OO and it's skeleton looks very much like a set of subroutines. how right/wrong is that observation and what do you think of that?

[Robin]

Basically, it all comes down to religion.

For a less wishy-washy answer:
OO is great for large projects that need a lot of architecture, like LÖVE itself. Games written in LÖVE, on the other hand, tend to be very small and rapidly prototyped. Class-based OO tends to require games like that to be overdesigned, whereas prototype-based OO tends to fit better.

You'll see that the trend among more experienced lovers is that the larger the game, the more it is written in an OO style, and the more often class-based OO libraries are used.

[clickrush]

So what you're saying is that I have to find my own belief? ok that is gonna be fun:

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.

translating this into programming: the scientific truth is easy to find here: math. The beings would be the objects i suppose and to keep the hierarchy minimal i would need to use the prototype based approach.

[/brainfart]

thx for your answer

I'am on a verge of a huge gap currently because I need to organise my code better, which goes heavily against my nature of just doing things as they pop up in my head.

My brain kinda works this way: let's say iam working on some chunk of code. during that time it rains ideas and solutions for other mb unrelated things and I have to switch to another chunk of code. My brain kind of switches between every aspect of the program constantly and everything I do is an inspiriation for something else. As if all parts of the code talk to eachother.

also I really don't like the way OO works as far as I understand it now. the methods seem to be part of the objects. But the way I like to see the program I'am writing is the methods/functions to be the forces that push objects around. like heat, wind and gravitation (functions) behave to the beings of the world (objects).

[Robin]

also I really don't like the way OO works as far as I understand it now. the methods seem to be part of the objects. But the way I like to see the program I'am writing is the methods/functions to be the forces that push objects around. like heat, wind and gravitation (functions) behave to the beings of the world (objects).

That sounds like functional programming. You should check it out. FP is awesome and Lua is a pretty good language for it.

[clickrush]

just a quick: thank you very much!. This hint is exactly what iam searching for and is very encouraging. Apparently one of the core concepts of functional programming is using first class functions which lua provides. Also the skeleton of LÖVE is just functions so this might weave well into it.

I'am so eager to investigate this further. This might be exactly what I need to organise my code in a way that it feels right for me!

[pk]

Yeah, Lua adopts a role-your-own view to OO. Having done a fair amount of JavaScript programming I prefer prototypical inheritance to sub/super/meta/classes.

Have you read http://lua-users.org/wiki/ObjectOrientedProgramming? In fact the whole lua-users.org website is a great read.

[kikito]

The way I see it, all programming paradigms help you divide problems into smaller ones. The difference is the tools they give you to do so.

Lua is an imperative language. It does what you tell it to do, one line at a time. There are ifs, loops and functions, if you want them. Imperative languages are syntactic sugar for humans on top of the underlying machine architecture, which has the same moving parts (GOTOS, GOSUBS and JMP instructions).

Prototype-based languages group state (or "data" or "variables") with functionality (or "methods") into "objects" (that's a name for "packet of data and functions"). Each object can have a "parent" from which they can "look up" functionality if they don't find it.

But Lua is not prototyped - at heart, it's just imperative. What happens, is that it can be very naturally "convinced" to behave as a prototyped language, given its flexible syntax and particular data structures.

Very often when you do prototyped-based programming you end up with some objects that "have lots of children", and then their children themselves. Object Oriented programming make this separation "official": they call the first group of objects "classes", and the second group "instances". This has some advantages; when you have those two kinds of objects, the code can be very implicit and few lines of code will give you a lot of functionality. The other side of the coin is when your data doesn't divide easily as a group of classes and instances, which happens sometimes.

Lua is a bit more difficult to transform into an object oriented language. The first transformation was mostly a conceptual one - "I can use tables as objects", but this one requires some more lines of code "This kind of tables are classes, this other are instances, and they are done like this". But the amount of lines to do so isn't enormous; a basic implementation can be done in ~10 lines.

Functional languages take a radically different approach from the rest; they don't reflect the machine underneath at all. They reflect the math involved instead. Variables work like mathematical entities, not like a machine register (which can be confusing at first). This way of attacking the problem has some advantages: problems that are easily represented in mathematical expressions are usually very easy to code in functional programming. On the other hand, other programs, are difficult to express in a functional way, while they are very easily done in an imperative way.

FP is awesome and Lua is a pretty good language for it.

I agree on the first part (FP is awesome), but respectfully disagree in the second. I think Lua can be used in a functional-ish way, given it's flexible syntax, but I don't think it's "good" at FP - mainly because it still has "register-like" variables.

Other than that, Robin's post was spot-on in my opinion. For small prototypes, (say, 300 lines of code or less), then using OOP, or even prototypes might be overkill; good old imperative approach might be just good enough. But if it keeps growing, you will have to put some order on it - groups of variables and functions will start to appear - "this group is an enemy" "this group is the player". If you give those groups a name, and put them in a table, then you already have a basic prototype. If you have several "types of prototypes" then probably a class is already there, "hidden".

[clickrush]

thank you kikito, your response helped me to understand OO in lua a tad better. Especially the comment with "hidden" classes opened a knot in my brain that I struggled with. I can see the OO approach in lua much more fluent which is a huge relief.

Just a quick question: when I organise my code into functions that push around/change tables then that is not really functional isn't it?
Look at this statement about functional programming from python docs:

"...Ideally, functions only take inputs and produce outputs, and don’t have any internal state that affects the output produced for a given input."

First I thought: Wait a minute isn't that the case anyways? My younger brother (who doesn't know programming) explained it like this: "A pig will allways shit after it eats, wether it's day or night it doesn't care." ok.

and then "Functional programming wants to avoid state changes as much as possible and works with data flowing between functions." What does this even mean?

[Robin]

The "external state" bit refers to that it doesn't change globals or things like that, so that you can prove that if now holds that (for instance) f(10)=16, then that will always be the case.

Just a quick question: when I organise my code into functions that push around/change tables then that is not really functional isn't it?

In "proper" FP languages, all objects are immutable, so instead of changing a table, you create a new one and return that. In Lua, that's not really easy, but if we're not interested in being "pure" and "proper", changing it is often good enough (it's usually faster and more memory efficient than to copy your tables every time you want to change something, although you always have to be careful to modify the right thing).

[kikito]

"Functional programming wants to avoid state changes as much as possible and works with data flowing between functions." What does this even mean?

Basically, in a "pure" functional language, this is not possible:

Code: Select all

x = x + 1

In an iterative language it's a completely natural thing - the "memory position" or "machine register" represented by "x" will increase its value by 1. But matemathically, it doesn't make sense at all! No mathematical variable can have a value x and a value x + 1 at the same time. A functional language throws an error if you try to modify a variable that way. You can't modify variables that way, because in math they don't change their values.

In functional programming, when you need to express that kind of relation between two values (x and x + 1) instead of writing a step to transform one into the other you write a function.

Code: Select all

function inc(x)
return x + 1
end

This is related strongly with your "pig" example. A function in a functional programming language always performs the same action given the same inputs. In an imperative language, it doesn't. For exampel, in an imperative language, such as Lua, you can do something like this:

Code: Select all

local increment = 1
function inc(x)
  return x + increment
end
inc(10) -- returns 11

increment = 2 -- This is the difference!

inc(10) -- returns 12

In a functional language, changing the value of increment, once it has been initialized, would have thrown an error. Variables in functional languages are not not "memory addresses" whose value can be changed by "anything" with access to the memory. They are "pieces of truth". And functions are operations performed over those truths. They always return the same value given the same inputs as a consequence of what they are: not a sequence of steps, but a group of operations over fixed statements.

Again, this comes with a cost. Iterative processes (do A, then do B, then do C, then do D), which are trivial in imperative languages, can be difficult to model in functional ones - (since B must "always be the same", no matter the inputs, it can try to be evaluated before A is evaluated).