I found that when implementing complex algorithms for the first time it is usually much faster to guess the solution and debug it, rather than actually spending loads time thinking about how to solve it correctly on first try (never works).
1 2 3 4
works ? goto 4 : goto 1 again using some information gained by debugging
Especially those for which I do not have any pseudocode or recursive algorithms.
It turned out that with some practise I became pretty good guesser.
What are your opinions on this? Do you start programming right away or solve the problem without programming first (pseudocode, flow charts, recursion trees, whatever)?
I did a lot of guessing when I started programming. It worked quite well in Java because it tells you if something goes terrible wrong. When doing more complex things guessing is not that easy.
If you invoke undefined behaviour in C++ it might still appear to work, but it might fail in certain cases or make other parts of the program act strange. These bugs can be really hard to find. Staying away from undefined behaviour is very important and requires that you know what you are doing.
If you are getting good at guessing I think that means you are getting better at knowing what you are doing so you are actually doing less guessing. I'm not always 100% sure that what I write is correct but I always have a hunch. If I'm not confident that something is correct I make sure to test that something until I am confident before moving on.
I think that it is better to try to write correct code from the start. Otherwise it's easy to end up with a big piece of code that doesn't work and you don't know where the problem is, or you end up with something that you think work but in some rare case it does not work and you don't know this. Fixing the problem by guessing is not only hard, there is also a big risk that you introduce new bugs while doing so.
I sometimes writes pseudocode. It is very useful if I don't know how things should be done. With pseudocode I can think on a higher level about the things that are relevant and ignore the exact implementation details.
I agree entirely with Peter87, that is easy for me because I am very sure that he knows vastly more than me!! If I could add my 5 cents worth.
When a project is larger - imagine you need 20 classes or more, I would think that planning & design would be essential. Now imagine a project with 200 classes .....
You have to think in detail about all kinds of things like how all these things are going to interoperate, what design patterns would be best, data base connectivity, the user interface - the list goes on & on.
Of course you can work from the outside in (General to specific), but if you don't design & plan this, then the whole thing could easily turn into a big mess.
I have seen this "guessing" approach before - normally with students whose longest (well written ) programs were 200 -300 lines long. The reality in business might be programs that are 100,000's of lines long, or even getting up to 1 million lines. Of course that project is not going to be completed by one guy, but when lots of money is involved then planning & design becomes absolutely critical.
I think it's better to use a systematic approach. Fill in the blanks, look at the bigger picture; consider the parts you know you will need. When you surround the problem, it's often becomes much easier to solve.
If a problem is complex, doing a bunch of coding without thinking can leave you in an unorganized mess from which the confusing or difficult parts might only become more difficult.
Just to comment on your guessed algorithm for multiplying two square matrices. It will only work for matrices where n is a power of 2, so two square 3x3 won't work. Even though you aren't saving on any multiplications (there is an algorithm which has these restrictions but manages to reduce the number of operations) you can't do a multiplication of a n*m A matrix and a m*r B matrix. It would be more efficient to then just do the multiplication with no recursion and easier to follow. It also calculates the outer product, not sure if this is intended but easily fixed. It is a good idea to document these things as a comment for the function or class.
make other parts of the program act strange. These bugs can be really hard to find.
Yeah, this has happened many times... Unfortunate side effect of my approach.
or you end up with something that you think work but in some rare case it does not work and you don't know this
This almost sounds like mathematically proving that algorithm is correct for every expected input...
I was mostly refering to implementing algorithms in this post, but when it comes to designing big programs, I agree with L B ( http://www.cplusplus.com/forum/lounge/81518/ ). Biggest program I have ever written is 6.4k lines big(according to ohloh, they exclude comments and newlines), and it looks nothing like the design idea I had when I started writing it. It doesn't even look like itself 2 months ago... Too many times I have figured out how to improve design/performance while writing the program. IMO it is impossible to take everything into account before you actually start writing it.
I am aware of limitations of that algorithm. It is merely solution to exercise from a book. Purpose of index calculations is to prevent creating new matrices to represent submatrices
I disagree. I've done it both ways. "Guessing" only works if you have a pretty good idea of how it works to begin with, but, often as not, the guess leaves out important corner cases (and sometimes entire sections of main cases as well).
Of course, most industry works by the guess first and debug approach. Which, in my opinion, explains a lot of the crap out there.
Taking the time to understand the problem and work through the proper solutions at the outset saves significant time, headache, and money later. That's been my experience.