next »

[ProgramGamer]

Actually, I really like experimentation as well. I remember messing with my ludum dare entry's collision code for a while trying to find more eficient solutions, and I did! Pretty satisfying. I did find godawful ways of doing things too.

[oahda]

Best stack exchange ever: http://stackoverflow.com/questions/23749251/switching-between-a-gif-and-a-png-on-a-jlabel

[Photon]

Haha, yeah. I've been working more on the water waves and stuff in my games today. Still haven't checked out those cool algorithms for proper solutions based on true wave physics given to me in the Rain World thread, but just playing around and looking at the resulting visuals instead. It's a game. It doesn't have to be physically accurate. Just look good. And it's fun to play around with the constants and see what happens.

Not to say the water in Rain World doesn't look amazing but it's fun to be able to figure something working out from scratch, which I guess is your point!

Struggling through something can actually be more beneficial then just getting the answer outright or snagging the latest, shiniest way of doing things. Mind you, your situation may dictate which is necessary and good and I'm not trying to bash anyone's way of doing things with this post, but I feel like I'm learning that failure in some circumstances is OK. Code something and if works, BREAK IT. BAHAHA. 

OK, maybe I'm exaggerating just a smidge...

Anyway, I'm in the process of trying to "discover" my personal approach to component systems. I know there are some ECS paradigms already out there, but I haven't taken to them as well as I thought I would. Trying to work it out on my own has been sort of fun, and I feel like I'm slowly but surely getting through it.

[Sik]

Haha, yeah. I've been working more on the water waves and stuff in my games today. Still haven't checked out those cool algorithms for proper solutions based on true wave physics given to me in the Rain World thread, but just playing around and looking at the resulting visuals instead. It's a game. It doesn't have to be physically accurate. Just look good. And it's fun to play around with the constants and see what happens.

Movies cheat a lot with the lighting, why shouldn't a game? =O)

[Richard Kain]

Cleaned up some of my code last night. Went through all of the various classes and stripped out the unnecessary and testing-related bits that were hanging about. Then I managed to correct a fairly basic bug that was lingering in some of my code. All told it was a very productive evening.

[InfiniteStateMachine]

I spent some time a couple weeks ago spending a few hours writing a feature I thought I'd need in the future. Essentially ignoring YAGNI and it has just saved me days of work. Proof that there is essentially no such thing as an axiom in software development.

[ProgramGamer]

I succeeded in implementing an rpg battle system in Game Maker! :D
(See my signature for proof)

[Photon]

I spent some time a couple weeks ago spending a few hours writing a feature I thought I'd need in the future. Essentially ignoring YAGNI and it has just saved me days of work. Proof that there is essentially no such thing as an axiom in software development.

Funny, but I've been thinking about ignoring YAGNI too. There are just some things out there that I want to try like getting a basic dialogue system up and running, so why not?

[Layl]

I spent some time a couple weeks ago spending a few hours writing a feature I thought I'd need in the future. Essentially ignoring YAGNI and it has just saved me days of work. Proof that there is essentially no such thing as an axiom in software development.

It's almost as if... the world's not black and white! Oh no, I've been advising people wrong all my life! WHY WORLD WHY, WHY HAVE YOU HIDDEN THIS INFORMATION FROM ME FOR SO LONG!

[InfiniteStateMachine]

I spent some time a couple weeks ago spending a few hours writing a feature I thought I'd need in the future. Essentially ignoring YAGNI and it has just saved me days of work. Proof that there is essentially no such thing as an axiom in software development.

It's almost as if... the world's not black and white! Oh no, I've been advising people wrong all my life! WHY WORLD WHY, WHY HAVE YOU HIDDEN THIS INFORMATION FROM ME FOR SO LONG!

Post secondary dogma ?  

Seriously though, YAGNI & DRY. Those acronyms need to stop existing. Common sense is the way to go.

[Layl]

Post secondary dogma ?  

Seriously though, YAGNI & DRY. Those acronyms need to stop existing. Common sense is the way to go.

I think the reason they're useful is because they're good rules of thumb. I personally believe they do less harm than they do good, but of course it's important to use common sense.

[InfiniteStateMachine]

Perhaps the issue is that often they are presented as axioms rather than a good starting point for critical thinking.


Then again in regards to DRY. If you are copy-pasting a crapload of code over and over and don't have a feeling there's something you could do better then you might have bigger problems :D

[Garthy]

I think the reason they're useful is because they're good rules of thumb.

^
Pretty much sums up my thoughts on the subject.

IMHO such things should be treated as guidelines, which basically means:

- They're generally worth using, so you should favour their use.
- There are times where using them is the wrong thing to do. In those cases, disregard them.

On DRY and YAGNI specifically:

- DRY is one I tend to follow fairly closely as it is frequently valuable. Having said that, I ran into a case yesterday where I blatantly ignored it, as it was unsuitable for the problem I was solving.

- I do not value YAGNI highly as I feel it is frequently wrong. However, I do feel it is important to avoid pointless overengineering, which is in line with YAGNI. I also feel it is important to design a solution that factors in likely future occurrences, which clashes directly with YAGNI.

[Dacke]

KISS rather than YAGNI?

[Garthy]

KISS rather than YAGNI?

Yes. Let's go with KISS > YAGNI.

[Dacke]

I like KISS. It reminds me that I'm not as smart as I think I am and tells me to keep my shit together. But it doesn't force me to stick to any specific design pattern (unlike DRY, for example).

edit: Rather that DRY, I was taught to feel free to repeat myself two times. But if I found repeating myself a third time, I should consider doing something about it.

[InfiniteStateMachine]

I like KISS better too because the acronym in KISS 

[TheLastBanana]

Rather that DRY, I was taught to feel free to repeat myself two times. But if I found repeating myself a third time, I should consider doing something about it.

Yeah, that's usually what I stick to. If you have a few lines of code repeated here and there, it's probably not worth the headache of refactoring everything right away. More often than not, you'll end up coming back and changing one of the "copies" enough that, had you refactored early, you would need to, uh... re-refactor.

[Garthy]

Rather that DRY, I was taught to feel free to repeat myself two times. But if I found repeating myself a third time, I should consider doing something about it.

Just ran into this, seems strangely relevant:

https://en.wikipedia.org/wiki/Rule_of_three_%28computer_programming%29

It's got a name then.

[InfiniteStateMachine]

Rather that DRY, I was taught to feel free to repeat myself two times. But if I found repeating myself a third time, I should consider doing something about it.

Just ran into this, seems strangely relevant:

https://en.wikipedia.org/wiki/Rule_of_three_%28computer_programming%29

It's got a name then.

Weird, when I hear rule of 3 I think of the rule for implementing a copy constructor (also implement assignment and dtor)