Programming by guessing?
closed account (10oTURfi)
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).
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)?
EDIT: As example of really hardcore guessing is index calculations in this one: https://github.com/krofna/Algorithms/blob/master/square_matrix_multiply_recursive.cpp
I don't think I would ever figure it out without guessing...
|
|
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)?
EDIT: As example of really hardcore guessing is index calculations in this one: https://github.com/krofna/Algorithms/blob/master/square_matrix_multiply_recursive.cpp
I don't think I would ever figure it out without guessing...
Last edited on
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.
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.
Last edited on
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.
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.
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.
closed account (o1vk4iN6)
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.
closed account (10oTURfi)
@Peter
Thanks for your opinion.
Yeah, this has happened many times... Unfortunate side effect of my approach.
This almost sounds like mathematically proving that algorithm is correct for every expected input...
@TheIdeasMan
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.
@xerzi
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
Thanks for your opinion.
| 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...
@TheIdeasMan
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.
@xerzi
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 find i would be learning by guessing if it wasnt for you guys and this forum, i think with your help i learn faster...even if its just advice on how to learn and problem solving
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.
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.
Topic archived. No new replies allowed.