Avoiding OOP

[airstruck]

Adhering to some arbitrary programming patterns just kills creativity and damages productivity.

I don't think anyone was suggesting adhering to "arbitrary" patterns. I think the implication was that an appropriate pattern could be used to solve a particular problem at hand. Do you think Inny's suggestion to use ECS would kill creativity or damage productivity? If used properly, I think it would do just the opposite.

some jackass says this breaks a paradigm

Who ever says that? What does that even mean? If your code follows (for example) an OOP paradigm, nobody is going to tell you you're breaking some other paradigm, because it's clear that your code was never intended to be written in that style. In a multi-paradigm language, I really have trouble imagining who would even care. Use whatever paradigm best fits your design, nobody's going to complain. The only time I can ever imagine "some jackass" telling you this is if you're committing code to a project that explicitly follows a particular paradigm by convention and you're going in some completely different direction with your contribution (and if that happens, they're right to tell you that).

End user would be the last person on the planet to care about proper use of patterns, but you can bet your ass he'd be the first to care if it runs poorly, and no amount of "code elegance" will redeem the situation.

Who ever said the point of "elegant code" was to "redeem a situation" where the end user experiences poor performance? It's about avoiding maintenance nightmares, not about performance / user experience (and, of course, these things are not mutually exclusive). Of course the end user doesn't care, but you and the rest of your team should care, unless you're just writing tiny things you throw away after the latest LD.

When I code, I just concentrate on getting it to work properly, and then on getting it to work faster. That's all the end user would care for, and so it's all what I care for.

So you've never commented a line of code, or named a variable in a descriptive and meaningful way, or written a commit message? If you have, I suspect you care about more than you say. If you haven't, be ready when the guy who inherits your code comes for your head.

Keep in mind that overengineering is a bad thing. In physical hardware it just leads to expensive items with poor reliability outside of test conditions that are so complicated it's impossible to fix them. In programming it has similar effect.

And in your mind, what constitutes over-engineering? Does employing a design pattern to solve a problem constitute over-engineering? Does sticking to one paradigm in a particular section of code for the sake of uniformity and "least surprise" constitute over-engineering? Or were you referring to something else?

Also, I don't know why would anyone suggest that "properly written" code is reusable, as opposed to other code like it isn't.

But you do realize, it's pretty widely accepted that properly written code should achieve a high level of reuse, right? If you don't understand the relationship between "properly written code" and code reuse, maybe it would make sense to inform yourself rather than stating that "you don't know why anyone would suggest that." Being informed, at least you'll know why anyone would suggest that, even in the unlikely case that you disagree for some reason.

Just a reminder, using libraries = code reuse. Do you care what's in the library? Pretty sure not. Chances are you never looked into sources.

It is an example of one kind of code reuse. There are many more kinds, and from what I've seen, people who are educated about them generally don't make statements vaguely implying that reuse is not an important factor in "properly written" code.

I don't know if that was a troll post or what, but if it wasn't, I'd seriously consider some further reflection on your strange notions about software design.

[raidho36]

I'd agree with most, except for the fact that by "properly written code is reusable", they probably mean either of two things:
- the source code is readable in that it's not a nightmare to actually figure out what and how it does things
- the interfacing part(s) are not combining very differing schemes like getElement, but set_elem with elementreset etc...

It's a valid argument, but I must say that in my practice I never had to "reuse" code by copy-pasting fragments of it. Most often you might need something similar yet different, for performance reasons or anything else really, so you just re-write the whole thing anyway. Clearly that doesn't qualifies as "code reuse". But I do reuse code frequently by using libraries, frameworks and engines. And you may not think of it that way, but something as simple as a class file can already constitute a small library.

Do you think Inny's suggestion to use ECS would kill creativity or damage productivity? If used properly, I think it would do just the opposite.

You're still adhering to arbitrary guidelines. You may have faster, cleaner, more efficient solution that breaks it, but instead you'd use a pattern just because it's a pattern. You see where I'm going with this?

The only time I can ever imagine "some jackass" telling you this is if you're committing code to a project that explicitly follows a particular paradigm by convention

Well I didn't literally mean that someone says your code breaks some conventions, it was more of a figure of speech. 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.

It's about avoiding maintenance nightmares, not about performance / user experience

I don't know about that, people have pretty arbitrary ideas about "code elegance", and yes it often means they'd use single-liner over complete solution that works a lot faster and/or easily adjusted without complete rewriting just because it's a single-liner. The kind of people who care about "code elegance" are the kind of people that would never write fast inverse square root just because of how ugly it is.

what constitutes over-engineering

Designing a lot bigger and deeper stuff than you actually need. As per KISS principle you should be avoiding it to begin with, but, you know, making singletons scalable would increase your e-peen length by at least 5 inches, even though you'd never use more than 1 instance of it. Things like that.

it's pretty widely accepted that properly written code should achieve a high level of reuse

A lot of false ideas are pretty widely accepted. You have any idea just how poorly Microsoft software is written? You wouldn't see the sources to tell, but there are people talking about weird bugs and security issues, and some Microsoft employees talking on IRC shed some light on it every now and then. And for what it's worth, their code is reused a lot. Nearly every Windows game requires MSVC redist because it uses its libraries.
>types of code reuse
See above.
>people who disagree with me are trolls
Medium heh.

[Plu]

When I code, I just concentrate on getting it to work properly, and then on getting it to work faster. That's all the end user would care for, and so it's all what I care for.

I'm guessing you don't have any colleagues? Because they would probably care about you writing stuff they can read and understand easily, so they can maintain it in your absence. At the same rate; you must not do much long-term maintenance on your own code? Even when I do my best to make the code readable, it can be hard to get back into it after a year or more.

[Positive07]

Sticking to a paradigm in a section of your code, making code clean and understandable, easy to read is something that has WAY TOO MANY benefits, I have come across uncommented code, with akward variable names, even single characters that don't provide any information to what the code is doing whatsoever, and I can't read it.

I've been coding for many years alread (12 if I'm not wrong) yet it's not a problem of knowing how to code but sometimes it's hard to see why a programmer would make a decision, for example using a simple loop instead of a for ipairs loop, or using tab[#tab + 1] instead of table.insert, of course this are minimal, but once you have many of this, you can't understand what the programmer wanted to do with that piece of code.

Writing clean code is needed:
You need to write clean code to understand yourself better, what happens if you step down of a project you were writing and come back at it 1 year later? You probably won't remember what you tried to do and your code will be the only one helping you, or betraying you, and believe me starting from the ground up may not be an option. This has happened to me.

You need to write clean code so that other people can contribute to it, in open source projects you want people to understand your code, find issues in it and fix them, if you are gonna be an asshole and write poor code, no one will help you fix your problems.
Here is also important to stick with paradigms, one or a combination of them, and of course the one that better fits your task, this is so people can write equally useful code that can be as easily understood as your own. If all your functions are camelCased and then come someone that uses Another_type_of_naming it will probably call your attention, be distractive and also bring errors, you will remember the function name and you will try to call it but oh anotherTypeOfNaming is not defined, and that is because the person who wrote it used another naming convention.
On large code bases this happens a lot, what I pointed above is always minimal example but just think about what would happen if a function that you think may return an object actually returns a component's id? That would probably hard to debug, even more if the code is not clean and properly commented.

Again in small projects you may know and remember your entire codebase, but that doesn't scale.

Also about code reusal, using library is the most basic example of it, you probably don't even know what reusing code means. One tries to write code that can be easily used in multiple scenarios, this is so you don't have to write it all over again, as you said sometimes you want functionality to be a little bit different, if your code can handle that case too then you don't have to write it for the ground up, so you are not wasting your time, also it is easier to come and change what your code did.

Of course sometimes you have time limits and you need to get things done fast, but even then it is better to be clean so that when it comes the time of debugging you can easily find the errors in your code and know why they are happening. Clean and reusable code is not harder to write, nor does it take a considerable amount of time, it just takes a little bit of a different minset, clean code can be much faster than unclean one, because you can optimize it the most, because you can read it, and understand the inner workings of it with minimal effort.

I'm just pointing to minimal examples, and 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.

I don't know what makes you said that clean code is bad or has disadvantages, I don't know why you say that sticking to a pattern is somehow limitted but I think you should read and inform yourself, there are many articles about this stuff, and it may help, even more if this is one of your first takes at programming, seeing you come from GameMaker

[raidho36]

You got the wrong idea. I didn't mean writing like shit just so it works. I mean not to prefer california-tier hipster programming trends over basic simplicity, performance and maintainability. Both ends of the stick are exceptionally bad to deal with, except people who overengineer things absolutely sure they're writing exceptionally good code, so if you tell them that it's bad and need fixing they'd take you for enemy of the people Soviet Russia style.

Also, in my practice, when you get to really optimize code (especially in higher level languages) it tends to get progressively messy as it gets progressively faster. When you call a function or rely upon language syntax, you don't just execute one command with O(1) complexity, on top of internal overhead there could be weird quirks that you have to work around to get it to run faster. Sure "if ( foo.indexOf ( bar ) > -1 ) {" is a nice way to check if an object is in array, but it really depends on implementation and it could have O(N) complexity. Then having it as "if ( bar.isIn[ foo ] ) ) {" will run a lot faster, it's a O(1) complexity operation. Or in LUA specifically, text comparison operations are fast but any operations that generate new text are very slow, so you're better off with putting a bunch of extra fields in a table than creating a string that contains information about all those fields at once. And as with any garbage collected language, using pools is always preferable to creating new objects and then discarding them, even if it isn't nearly as clean and straightforward. Etc etc etc.

[Plu]

And as with any garbage collected language, using pools is always preferable to creating new objects and then discarding them, even if it isn't nearly as clean and straightforward. Etc etc etc.

Sounds a lot like premature optimization to me. Unless you're going to be using and reusing a huge number of objects, you're not going to notice the performance decrease from making and discarding the objects. You're definitely going to notice the performance decrease from needing more time to modify the code.

[raidho36]

Well sure if you only do a handufl then it might not be an issue. But you know full well I'm not talking about those few.

Also I would clarify, in case anyone is confused, that "premature optimization" refers to spending a lot of time optimizing performance of a code that is not yet even doing what it's supposed to do, not to designing the code to work fast in beforehand - that would be stupid. The "proper" way of getting results is first to sketch it, then to clean it up, then to optimize. You can write clean code to start with, similarly you can write fast code to start with. Setting up a pool and doing discard/recycle operations instead of new/delete will not impact your productivity but will improve performance, and down the line you won't have to rewrite the whole thing to use pools when it eventually comes to that. Putting it on as an afterthought will have you work great deal more to wedge it in than if it was designed with it in mind to begin with, and chances are you won't achieve good results. It's like multiplayer games - if you didn't designed it for multiplayer right off the bat, adding it in will be painstakingly difficult process and result will not be very good.

[Plu]

Premature optimizing also refers to the act of sacrificing legibility and maintainability to improve the performance of code that has not yet been shown to have unacceptable performance.

It's one thing if you can write code that is clean and also fast to start with, but you literally said that "using pools is always preferable to creating new objects and then discarding them, even if it isn't nearly as clean and straightforward", which means that you are saying it does impact your productivity as you're writing more complex, harder to maintain code in order to improve the performance for a piece of code that might not need it.

And I don't "know full well I'm not talking about those few"; you prefaced your previous comment with "always preferable". If you meant "preferable whenever you know you're going to use hundreds or thousands of these objects", then I'd probably have agreed that you should probably take the time to come up with a fast solution. Most code I find isn't that performance critical, though.

[raidho36]

Now you're just arguing semantics.

[Plu]

I'm a programmer. I take words like "always" very seriously