Spring RTS Engine

HATE. Really, its the most anoying thing ever. The planning of software is fun. The coding is pure joy. I wish the Halting problem would be solved, and a machine could do this most shitty job of all ...

But instead.. i step and echo, till im dead.


INB4 LEARN TO CODE BETA(R); //NOOB

Debugging is an integral part of programming.

And the main reason it always takes longer than expected.

zwzsg wrote:Debugging is an integral part of programming.

But sometimes i wish it would just float away...

Imagine a world without it.
A program comes and chops your software up, and tries every part seperated, and every time it yields no result... oh, thats not possible.

PicassoCT wrote:A program comes and chops your software up, and tries every part seperated,

That's called Unit Test.

But it takes work to put it into place, and doesn't catch every bug.

My clock is broken, it is a large heap of cogs and wheels. I tried writing unit tests for each part, and it appears all the cogs and wheels are perfectly formed, yet my clock refuses to work, what's wrong?

Yeah, yeah, and even if you wrote a program that could build clocks from pieces, it still would have to watch the clock for all eternity, never able to finnish deciding if that thing is fully fuctional, or stuck in a endless loop.

Im aware, that i have to do it, still dont liek it.

It's fairly easy with Eclipse, the best possible feature would be a rewind tool though that could let me figure out how the bad data got into the system in first place.

You don't need to watch the clock for all eternity, just as long as it seems reasonable and if it still breaks after a looooong time (even longer than your QA division checked for) then the users can file a ticket for that. Though honestly very few errors only happen after a long time of usage (and if they do it's probably a memory leak and you can spot those much earlier with a profiler). Most are triggered by specific actions in a certain sequence and can be reproduced in seconds once you know the necessary steps.

KDR_11k wrote:the best possible feature would be a rewind tool though that could let me rewind time once the bug is fixed

fixed.

best would be a learning algo that is connected through out the intertubes, and once i pinpointed a bug, i hit the point in history were i produced it, and the failure is added to the database. Once its there, and the gramar check deduces the same phail approaching at somebody elses project it can start posting warning signs. Its would be the ultimate open source approach because no company could participate in this... simply because they cant reveal what they write to the algo.

AF wrote:My clock is broken, it is a large heap of cogs and wheels. I tried writing unit tests for each part, and it appears all the cogs and wheels are perfectly formed, yet my clock refuses to work, what's wrong?

You forgot to wind the weights, duh. Lern2program noob!

Debugging is a form of problem solving. Problem solving is fun.

there are lots of other testing methods besides unit tests.
what AF talks about, is most likely a validation test scenario (spring already has some of those, thanks to abma!).
https://secure.wikimedia.org/wikipedia/ ... re_testing

to find where/when a bug happened, make a test-case that triggers it, and run an automatic bisecting process through your SCM history.
... as you already wrote a test-case, you can keep that, and thus ensure the problem does not reoccur.
all of this is really easy and streamlined in Java.
probably unmatched anywhere else.

AF wrote:My clock is broken, it is a large heap of cogs and wheels. I tried writing unit tests for each part, and it appears all the cogs and wheels are perfectly formed, yet my clock refuses to work, what's wrong?

You got an integration problem :p

(for which you have integration tests of course )

hoijui wrote:all of this is really easy and streamlined in Java.
probably unmatched anywhere else.

Many non-Java post-C++ platforms also have quite decent tools. (e.g., ruby, python, .NET)