LÖVE

raidho36 wrote:You're still adhering to arbitrary guidelines.

There's nothing "arbitrary" about guidelines when you decide to follow them for a reason.

You may have faster, cleaner, more efficient solution that breaks it, but instead you'd use a pattern just because it's a pattern.

What, like using the object pool pattern all the time for no reason?

You see where I'm going with this?

In circles?

Well I didn't literally mean that someone says your code breaks some conventions

Of course you didn't literally mean that. You never said that.

Come to think of it, in such situation it's still the same isn't it? Instead of doing something good and efficient you're doing what you're told to.

You have it backwards. You are using a known solution to a problem that is proven to be good and efficient. Are you going to stop using object pooling now that you know it's a pattern? No, you can use it if you need to. That's code reuse.

I don't know about that, people have pretty arbitrary ideas about "code elegance"

So what? That was your word, what did you mean by it?

I didn't think you're trolling because I disagree with you, I thought you're trolling because you seem to be advocating shitty code, and at the same time contradicting yourself, and padding that out with pure gibberish. Maybe I was giving you too much credit.

Positive07 wrote:if clean code wasn't important there wouldn't be so many articles in the web explaining why it's good, major projects wouldn't have contributing guidelines and design patterns as part of their goals, languages wouldn't have nice syntax that can be easily parsed by humans, we would still be writting assembler which is faster and more performant, but here we are writting Lua a really high level language, because it is simple and can be read and understood easily, because it's clean.

That pretty much sums it up.

Gee that's some serious company of strawmen and their pals, I don't even know how to approach it. Maybe I just shouldn't?

Well please do, if you have better arguments that is, you seem to be lacking information and experience.

Something that called my attention is that you said that if you make a game and then you want to add multiplayer then it's harder than putting multiplayer from the ground up.

That's a TOTAL LIE, it is way easier to write your game and then add multiplayer that design multiplayer from the ground up, it boosts your productivity because you get something working faster, you fix errors as you go and when you add multiplayer you already have a solid codebase and you only need to fix the multiplayer part.

That is, if you write clean code, and reusable code, if you didn't write code that can be easily adapted or changed you will end up rewriting the whole damn thing as you stated. So most likely you don't even know what clean code and reusable code is.

Performance tights things, memory expensive stuff, libraries that have to adapt to multiple scenarios, even multitude of platforms, expanding projects. All benefit from clean code, code reusal and stricts programming patterns. I can tell you this and if you don't believe me then you should read.

Also if you want to write code that runs with the best performance and with no code pattern or caring about clean code I recommend you code in Assembler, Lua is really slow compared to it, and won't let you access all the features you may get from Assembler, you will be able to get your totally needed DPI and all those things GameMaker provides, you will also write code that executes super fast and does exactly what you want at memory level, you won't need to care about object pools and ECS or such things. I think it is exactly what you want.

LÖVE uses objects, is coded in C++ and your code is written in Lua so it isn't as fast, it doesn't provide direct access to memory nor direct hardware access, it forces you to use objects like Images, Fonts, Sounds and such, it is coded with clean code and not that much of performance in mind, it has some guidelines so many features you may find in other environments like DPIs on GameMaker aren't available and won't probably be added, because LÖVE tries to be minimal

I don't make multiplayer games so I wouldn't have first hand experience, but I read a lot of blogs of people who made those and it's a general consensus that if you didn't started it as multiplayer, it will be very difficult to make it such. And I don't find it hard to believe that adding net sync and whatnot to a fundamentally single player game isn't a simple and straightforward task. Same as with designing code to run fast, not optimizing it as an afterthought. There's only so much you could do without rewriting the whole problematic source. Then again, maybe they all suck and we gentlemen here are so much more skilled the than that.

As a side note, why should I or anyone really address fallacies other than pointing them out?

raidho36 wrote:As a side note, why should I or anyone really address fallacies other than pointing them out?

You haven't actually pointed out any fallacies, you've just made vague accusations with no real substance. Here, I'll show you how it works.

- Your premise is that everyone else is wrong about code reuse being useful, and you are right about it being harmful.
- You say that Microsoft software is poorly written.
- You say that Microsoft's code is reused a lot.
- You conclude by implication that code reuse must be to blame for the poorly written software, thus supporting your premise.

That feeble and disingenuous argument is an example of the post hoc fallacy. Your faulty logic hinges on the idea that a relationship exists between code reuse and poorly written software at Microsoft, and that the relationship must be a causal one. Anyone unfortunate enough to be subjected to your rambling and nonsensical argument will notice that you've provided absolutely no evidence for the existence of such a relationship.

Not too hard, right?

All right; in both above posts you grossly misrepresent my opinions, possibly intentionally, in order to make them look extreme to absurdity. That constitutes a strawman fallacy. It's so blatant in fact it could pass for a personal insult almost.

There you go! Easy right? Now I'd appreciate if you could argue without resorting to that and otherwise being unproductive in respect with discussion.

raidho36 wrote:All right; in both above posts you grossly misrepresent my opinions

I don't think I misrepresented anything, I was just stating my opinions. I think you are grossly misrepresenting my opinions about your opinions.

in order to make them look extreme to absurdity.

I think of them more as "extremely absurd," but you didn't need my help to make them look that way.

That constitutes a strawman fallacy. It's so blatant in fact it could pass for a personal insult almost.

I'm still not sure which of your opinions you think I misrepresented.

There you go! Easy right? Now I'd appreciate if you could argue without resorting to that and otherwise being unproductive in respect with discussion.

Actually, you could have stayed out of the thread entirely, the conversation was basically over until you come in trolling with fuck design patterns, fuck paradigms, fuck a team, just bang out code for the user and basically fuck software design. Then when you get called out on your bullshit you take that personally, so now you want to frame me up as the guy who's being unproductive, right? Or am I misrepresenting you again? Would you take it personally if I said I'd appreciate if you'd crawl back under whatever bridge you came from?

If you keep having to say "you are misrepresenting my position" and also "that's not what I meant", there is chance that instead of "you are all making strawmen arguments" this is a simple case of "I seem to be bad at expressing what I mean". This does, however, require you to seek the fault on your own end.

Madrayken wrote:

airstruck wrote:Off the top of your head, how would you answer these questions?

What are the advantages of OOP over procedural programming? Disadvantages?

Advantages are (theoretically) reusable code (i.e. less repetition enabled by extension of base classes), clarity of what data your functions are designed to work on.

@undef Thanks for the prods on scoping, environment and namespaces. I'll be doing some tests on using these more effectively.

OOP is still procedural, no matter how you perform your mental gymnastics. As for the myth that it is 'reusable' I am laughing right now. I have worked on several production code bases and team projects; I would classify NONE of their code writing in OO was 'reusable'. Oh wait, apart from that one guy who wrote a maths library as a set of functions in a class (to wit my point, it wasn't even OO). Granted, they were generally lazy and wrote shit OO code, which seems to be a common trait amongst the fanatical initiated. This mostly seems to have been originally instigated by the 'NetBeans' people, and their laughable breach of OO's encapsulation; which has now infected millions of programmers with their public getX() and public setX() lunacy.

Also, in defence of all other procedural code, a library or '.lua' file full of functions is reusable in a direct sense -> call a function, or a meta sense -> copy/paste function to where you need it. A function calculateDistance(x1, y1, x2, y2) is by it's own creation a reusable thing.

A class Monster, with a method monster:calculateDistanceToAnotherMonster(Monster otherMonster) is by it's own creation not reusable in any way other than a program that uses the Monster class and presumes to know what the heck is going on inside it.

This for me a huge clash what OO claims to solve, which is the problem of designing code without knowing what is under the bonnet (as far as I am aware). So then some smart dood will pipe up and tell me to put the distance calculation in another class (Math?), then linked to that class by assigning and creating the math object inside the Monster. Is this 'clean and tidy' code? You have created in several steps what I have done in one. You're still trying to connect components together, I'm already coding the AI system or doing something else entirely.

I mean, look at this shit. Flipping look at it:
https://en.wikipedia.org/wiki/Compositi ... nheritance

What is that, ~19? classes to make a duck flap and quack? You think this is 'clean and tidy' and 'well organised' code. I'm dying.

I like small doses of object type definitions, I'm not a huge fan of people creating entire applications with OO design; which to me fails in many areas of common sense. I've worked on JAVA projects in the workplace, and I feel that most of my time is spent putting up with programming bureaucracy and I actually personally feel that forcing OO definitions for everything in a program actually makes very messy code.

I have always married OO and pure procedural Data Oriented Design together, which feels far more efficient use of one's toolbox.

Also, a lot of people a talking about 'design patterns' here. The only reason these things exist is because of Code Smell and lack of features in the language or OO paradigm itself:
http://c2.com/cgi/wiki?AreDesignPattern ... geFeatures
http://c2.com/cgi/wiki?LanguageSmell

There is a good article by a guy who goess through the Design Pattern book and one by one explains and shows how the problems occurs from the language/OO, I will try to find this.

"Creating the math object inside the Monster" is definitely not clean and tidy. That's coupling the Monster to the math object. Dependency Injection exists to help make sure classes really are reusable.

And the "getDinstanceToAnother" is also not a proper method for a Monster class. That one should go in an Area class of some sorts. Which should have a method calculateDistanceBetween() which should accept something more global than a Monster, more like a SpatialEntity. (Which a Monster is, based on its components or inheritance or whatever you're using to assign behavior.) That way, Monsters don't need to care whether they are on a playing field or what that looks like; only about the things that make them Monsters.

The function calculateDistance(x1, y1, x2, y2) is only reusable in a 2d-environment, by the way. The function coordinate:calculateDistanceTo(coordinate) works for anything, but you'd need a coordinate class to make this happen.