next »

[JWki]

In case the above discussion hasn't scared you away from the concept and you still want to try it, here's something I found, which at least to some extent seems to adopt a philosophy more along the lines of what was suggested above:

https://github.com/bakpakin/tiny-ecs

I don't know Lua and haven't used the library, so you'll have to ponder its usefulness for yourself. p:

Trying to fit new unique problems into patterns is bullshit.

I agree with this fundamentally, but I also don't think that makes ideas with names unjustified—the core philosophy of any given methodology can always be the spark of a variation on its fundamental idea that does work well for any particular application, and surely if there's terminology to give others an inkling of one's direction that can be helpful, since after all most ideas are variations on others and not completely unique. At least to me, terms like OOP and ECS are a bit fluffy and don't describe anything exact (C structs with associated functions to me are as much OOP as the C# model)? Just my thoughts on it! c:

I think an issue that causes a lot of extremism on the other side is that, often with programmers that have been taught using OOP as primary philosophy, first of all they assume that OOP is the "nice" way of doing things, locking them into thinking it's the only proper way. When presented with a problem, the pure "Object Oriented" approach is to try and formulate a solution in terms of objects that work together to solve the problem. This way of doing things tends to lead to overly complex solutions to rather simple problems, creating architecture where none is needed. Just look at UE4 for example - it is EXTREMELY object oriented in each layer, and trying to follow the application and data flows is nearly impossible to do as a result because everything is decomposed into classes in a granularity that scatters the program logic across hundreds of files.
Ofc another concern often expressed by the anti-OOP side is that OOP thinking can lead to less performant code because it promotes lots of small dynamic allocations and cache unfriendly data structures (node based structures come to mind with nodes being individually allocated on the heap).

So yeah as always this issue can be summed up by stating that the most important thing should be not to lock yourself into any methodology, keep an open mind when approaching problems and solve each one individually in a way that suits the particular problem best.

[oahda]

Agree with all of that.

I guess we've started repeating ourselves at this point.

[JWki]

Yes it's a discussion that keeps popping up for some reason, not only here but everywhere.
I used to engage in these quite enthusiastically and be a rather fanatic proponent of either side of the argument at different points in time but neither has really helped with my productivity because I do tend to get quite locked into a way of thinking myself so I'm trying to find a spot where I feel really comfortable. I know classical OOP isn't for me because that's what I've been doing for the longest time and I've always felt somewhat discontent with all my solutions to problems and could never think of why that was. When I started doing more rapid prototyping with complete disregard to structure and focus on rapidly adding features, I started feeling way better about my code. I'll see how I feel with a bigger project once I have the time to start one again which should be soon hopefully.

[ProgramGamer]

tl;dr

use the appropriate design pattern for the given problem.

I think there's an acronym for that; KISS (keep it simple stupid!)

[InfiniteStateMachine]

Fairly sure c structs with free functions is pretty cut and dry procedural. Member functions is one of the defining traits of OOP.

[oahda]

Seems like such a weird thing to get into a heated debate about in general, as if there was an objective truth to be found and always applies, heh. Only really makes sense to discuss within a team that's actually supposed to work together on the same, particular project. Seems unnecessary to be bothered by or invested in the way someone else chooses to work on their own project that one won't have to work on anyway.

[JWki]

Humans have the tendency to get ideological about their views.

[ProgramGamer]

Fairly sure c structs with free functions is pretty cut and dry procedural. Member functions is one of the defining traits of OOP.

But they both achieve the same thing, don't they? Even public and private functions could be implemented with #defines and #ifdefs. Plus, the question isn't about what qualifies as a certain paradigm, it's more about when to use certain design patterns, no matter the language.

[JWki]

Fairly sure c structs with free functions is pretty cut and dry procedural. Member functions is one of the defining traits of OOP.

But they both achieve the same thing, don't they? Even public and private functions could be implemented with #defines and #ifdefs. Plus, the question isn't about what qualifies as a certain paradigm, it's more about when to use certain design patterns, no matter the language.

It's more about avoiding to think about patterns actually

[qMopey]

Fairly sure c structs with free functions is pretty cut and dry procedural. Member functions is one of the defining traits of OOP.

Funny you say -- it seems a lot of people tend to think that's what "OOP" is. I mean that's what I thought for a while.

https://twitter.com/christerericson/status/387615254152114176
https://twitter.com/christerericson/status/476904937528369152
https://twitter.com/christerericson/status/400420141097160704

But then I saw this guy yelling at various people, and long story short now I hate acronyms and apparently OOP is something specific that doesn't mean "member functions".

Seems like such a weird thing to get into a heated debate about in general, as if there was an objective truth to be found and always applies, heh...

Heh good point. However, the heat still comes. For example people come onto my blog and do this (see comments). As silly as it seems people can find way to get all heated. Especially when it looks clear certain beliefs are the cause of lots of bad code one has to sift through, like maybe at work for example.

[oahda]

I guess Poe's law comes in. I'm not really seeing a difference in tone between your OP and the comments TBH, while you yourself knew what tone specifically you felt like you were writing in, so the comments might look different to your eyes. Plus I agree with some of the points brought up in the comments, so maybe they come off as less confrontational to me as well? Difficult thing, psychology! Blogs are a bit finicky too—are you just keeping a personal diary, or are you inviting discussion on an open platform with comments?

[qMopey]

Oh I was intentionally being inflammatory. But I was also expressing my true opinions. Don't get me wrong, I *am* heated about a lot of topics 

[zilluss]

I just leave this here: http://wiki.c2.com/?DefinitionsForOo
For anyone interested in an introduction of a clean OOP style, I recommend ISBN-13: 978-0321503626 (You can even skip the testing stuff). It's very suitable for very high level code, not so much engine stuff.

[JWki]

Oh my I didn't pay attention to the comments when I originally read that blog post.
As we're being grumpy already, I'll just go full out on this one even though I wanted to be more moderate in the future.

So first of all, I find myself guilty of overusing auto - I really like it though, I just need to use it less in places where it does actually cause some ambiguity.

Now, that being said, there's a lot of points that the comments raise that I find hilarious.
Just picking examples in no specific order:

- Using auto where an API is "documented in terms of 'unspecified types' - if an API goes and does that, fuck that API, seriously. std::bind is a horrible thing and shouldn't exist. Lambdas though I like and use, however without any capture mostly so I could explicitely write out the type because I know it.

- "it could be doing anything" referring to operators - yeah that's one of the things that's fucking wrong with c++ programmers, that they have operators do anything. Really the only places where operator overloading makes any real sense is maths code. Smart pointers maybe if you're being sensible but even that's dangerous.

- "unmaintanable mess" as in "non-generic, C-like code" - that's really a bad understanding of unmaintainable mess.

- "can't believe it is not obvious to you muc more generic [...] the code with auto is" yeah like that's always a good thing

- "even better and more idiomatic version of this code" -  "better" and "more idiomatic" is a dangerous correlation there

- "suggest you to watch Bjarne's lates keynotes" yeah no sorry fuck right off I watched both of these several times and I really tried being open minded but no

- "unkown ownership rights" - ownership should be expressed in more of an application wide scope, keeping track of "ownership" on a per-object basis and passing that around like cake on a birthday party is almost never a good idea

- "what if inputs are std::strings" the callee better know how to call c_str() then

- "after you write enough C++ [yadda yadda]" - I agree with those examples actually that's how I tend to use auto a lot

- "abhorrence that fills me [horrendous template thing here]" yeah well fair point but that's really the fault of the STL

- "I think  what you really want is to write in C" well yeah that usually results in code that's easier to read

I'm done.
Take this with a grain of salt I'm not in the best place right now and I'm tired and frustrated.

[gimymblert]

This discussion remind that post I made on unity's forum about a similar debate but with a bigger scope than just programming.

Hello!

I'm not a programmer, when I started i was over confident because I could implement features easily. I even get cocky because sometimes you see things in game and you are like "I could do better, why don't they do this?" Then I go and implement it and it works! But like someone told earlier, coding is not software engineering, I collapse badly when I tried to make everything works together (I'm a game designer).

Things that non coder overlooked, such as sorting, menu and interruption are damn harder to figure out correctly on your own!  Coding architecture is not the same as features, features are self contain puzzle, coding has little to do with it as it's basically the interface to implement it, architecture is more about "logistics" and less of a puzzle, there is no inherent optimal state but trade off. At least in my worldview as a non coder who have only little experiences.

So I was tempt by modularity and start to learn about architectural concept like event driven design, object oriented design or component design, but to me they seems to always make things more complex by moving the difficulty elsewhere.

I end up eschewing modularity somewhat! if you think about it, the core of what you want to do is specific, you have a specific idea, a specific feature in mind for a specific project. Modularity generally make thing generic enough so everything can go with everything, the metaphor is "lego".

But let's say you want to make a specific car in lego or the taj mahal ... at best you will have a blocky approximation because lego are block, their quality imprint the final design! but what if you want specifically to have the roundness of taj mahal dome? bad luck! That's the same problem with kitbashing, if you have anything specific in mind you will only end up with an approximation, and that approximation depend on the quality of the "primitive", so going modular is figuring out and designing primitive.

It's everywhere, pixels, voxels, textures, polygon, shaders, instruction are all primitives. But they never end up generic enough so you always have competing model that works with trade off on some domain better than other, it lead to an explosion of framework, and the model themselves are extended ad infinitum.

To stay with the lego metaphore, if you want to make a car, you need to introduce wheel part which is a specific part, and to make wheel works with the system you need axle brick to interface with other brick, so genericity is down. It's the same with language where instructions need to be added continually to cope with new problem etc ...

That's why I eschew thinking in generic modula pieces and start thinking more about containing the specificity in a manageable way, the metaphor I come up with was the "circuit board" or "frame". Basically it's a way to separate the features from the architecture. Basically in a project how things are assembled is the specificity of that project.

SO features where self contain and agnostic, they take input and give output, I plug them in a circuit board that handle all the "links" and routing of data and the subscribing (instead of having the features subscribing themselves) when necessary. SO I had all the necessary code in a single place too look at, and frame can be embedded into each other through input and output, so I could separate domain easily. Now I could test and create features and architectures separately with less headaches.

HOWEVER

Modularity can be embraced, it's just a very different set of problem it is solving. Another way to work is not to start against the primitive by having specific idea to approximate (top down approach) but to think within the quality of the primitive given (bottom up) which can also lead to surprinsing results and less headaches. The reason kitbashing works is not because we want something too specific but because we works toward a broader goal. And this exploratory way of creating stuff with stuff can lead to surprising discovery and new quality height!

[InfiniteStateMachine]

Fairly sure c structs with free functions is pretty cut and dry procedural. Member functions is one of the defining traits of OOP.

But they both achieve the same thing, don't they? Even public and private functions could be implemented with #defines and #ifdefs. Plus, the question isn't about what qualifies as a certain paradigm, it's more about when to use certain design patterns, no matter the language.

Sorry my quote was in response to Princessas post. I think I left my browser open and didn't realize like 5 posts went in between when I wrote that and when I pressed submit.

As for achieving the same thing. I think you can achieve the same thing pretty much no matter the paradigm but the "quality" of the implementation will be different.

[JWki]

Very grumpy rn because for some reason win32 refuses to set a title caption for my windows.
There MUST be some character set mismatch somewhere but I'm explicitly using the ASCII version for each procedure that has multiple versions so that should be consistent.

EDIT: AHA so, should you ever want to handle WM_NCCREATE messages in win32 - make sure to not just return TRUE but hand them over to DefWindowProc afterwards because if you don't your titles will go missing.

[diegzumillo]

Had a quick power shortage (less than a second, just enough to restart the system) and it corrupted the file I had opened. It's just code I can write again but it was pretty damn tricky to get that working. I never had this problem with Monodevelop, I wonder if Visual Studio has any blame. Guess I'll just use notepad ++. I don't use any fancy features anyway.

I'm way too old and grumpy right now. I'll just put my little project in a little drawer and go do something else for the next several weeks.

 

[gimymblert]

I think I'm definitely not a programmer, being able to do something and actually grinding to do it is not the same  it's fucking exhausting to redo a bit a code you understand but you just can't track everything at the same time so you overload 

[oahda]

I'm sure we've all been there. But sometimes it's better to tackle the problem without writing any code at all at first! c: