Thinking before coding
Author
One of the first things they teach you at Intro to CS courses is that when you have a problem to solve, you should not jump straight into the code.
First you should list the basic steps required to solve the problem, then you should write pseudo-code and only then translate that into code.
This sounds simple enough, but it is usually difficult for me to do this, even for relatively simple problems. When I think about the solution, it's hard for me to think about it in abstract terms and ignore the specifics of the programming language.
As a result, I usually jump straight into the code and spend a lot of time chasing bugs.
Basically my question is, are there any resources (books, articles, etc.) that are targeted towards training yourself to think before you code? Are there any tips you can give me? If you ever had this problem, how did you deal with it?
Any advice you can give me will be greatly appreciated.
Learn functional programming. For instance, Objective Caml or Haskell.
There are two advantages: the first is that unlike most imperative languages, if you start hacking in a functional language without planning ahead, you will get compiler error instead of runtime errors. This means that your code won't run until it's correct, which is a lot easier that having to look for bugs.
The second advantage is that you'll get used to solving problems in functional terms. This is, once you get the hang of it, much easier than solving problems in imperative terms, because you don't get bogged down in language details. You'll be solving the problems and then translating your solution to imperative terms, which will result in far less bugs.
There are two advantages: the first is that unlike most imperative languages, if you start hacking in a functional language without planning ahead, you will get compiler error instead of runtime errors. This means that your code won't run until it's correct, which is a lot easier that having to look for bugs.
The second advantage is that you'll get used to solving problems in functional terms. This is, once you get the hang of it, much easier than solving problems in imperative terms, because you don't get bogged down in language details. You'll be solving the problems and then translating your solution to imperative terms, which will result in far less bugs.
Author
That's a very interesting suggestion, and not at all the answer I was expecting - which makes it even more interesting. [smile]
Now, I started a thread about this a while ago, but which functional language would you recommend?
Take into consideration that I know nothing about functional programming, but I'm not new to programming in general (I'm familiar with C, C++ and C#, though I'm definitely not an expert in any of them). Also, what resources (presumably books) would you recommend for learning the language?
Now, I started a thread about this a while ago, but which functional language would you recommend?
Take into consideration that I know nothing about functional programming, but I'm not new to programming in general (I'm familiar with C, C++ and C#, though I'm definitely not an expert in any of them). Also, what resources (presumably books) would you recommend for learning the language?
Quote:Original post by Gage64
Now, I started a thread about this a while ago, but which functional language would you recommend?
My personal suggestion would be Objective Caml, but I am biased because I use that language far more than I use Haskell. One issue I would see with Objective Caml is that it's a bastard language that also allows the use of imperative features, meaning that you won't be coaxed into functional-only programming. This has some perks (for instance, as an imperative programmer, you won't be completely lost at first) but also some problems (you'll run the risk of trying to constantly use the imperative features).
As for books, the Objective Caml online manual is a fairly thorough exploration of what the language can do. Once you get the hang of it, the O'Reilly Objective Caml book by Chailloux et al. is a good follow-up.
Try sitting somewhere other than in front of your PC, and illustrate your complete solution on paper before coding anything out. The illustration then guides the definition of core concepts and behaviours, which then translate to API documentation (e.g. javadoc comments), unit tests, pseudocode and then code.
If you can't illustrate your solution, then it is unlikely that you entirely understand the problem and/or your proposed solution.
Sitting away from the computer helps to resist the temptation to start coding.
By 'illustrate' I don't necessarily mean a UML diagram - an annotated box and line drawing is fine. The idea is to put everything on paper in order to close the semantic gap between your mental pictures and the programming language.
If you can't illustrate your solution, then it is unlikely that you entirely understand the problem and/or your proposed solution.
Sitting away from the computer helps to resist the temptation to start coding.
By 'illustrate' I don't necessarily mean a UML diagram - an annotated box and line drawing is fine. The idea is to put everything on paper in order to close the semantic gap between your mental pictures and the programming language.
Author
Quote:Original post by ajones
If you can't illustrate your solution, then it is unlikely that you entirely understand the problem and/or your proposed solution.
Yes, that is my biggest problem. It's hard for me to "think in an organized manner" (for lack of a better term). That's basically what I need help with.
Quote:Original post by ToohrVyk
My personal suggestion would be Objective Caml
Somehow I knew you would suggest that... [wink]
A couple of questions:
1) I heard that Haskell is a pure functional language. Given that my goal is to learn a different way of thinking and not really a particular language, do you think that it might be a better choice?
2) I heard that F# is basically O'Caml minus a few features but is somewhat easier to work with (in particular, it's error messages are less cryptic). Do you think that would be a better choice? (again, for my purposes)
Finally, while learning functional programming sounds interesting, I'm sure it will be time consuming, so I would also like to hear some other suggestions.
Thank you both for your suggestions so far.
Quote:Original post by Gage64
are there any resources (books, articles, etc.) that are targeted towards training yourself to think before you code?
Programming Pearls by Jon Bentley.
Quote:Original post by ajones
Try sitting somewhere other than in front of your PC
Agreed, if I sit at the pc and try to think about a problem I get too tempted to just jump into code.
I find sitting somewhere else for a while and writing the problem on paper and working it out has resulted in some of my best code, Its surprising how smoothly the transition from pseudo code to code can go and its great when the solution works first time.
Also thinking of the problem this way will result in better code because you know exactly what you need when you start to write the code I can remember those early days with code littered with unnecessary variables and functions.
Author
Quote:Original post by DevFredQuote:Original post by Gage64
are there any resources (books, articles, etc.) that are targeted towards training yourself to think before you code?
Programming Pearls by Job Bentley.
Heh, I just borrowed that from my college library a while ago. I also already returned it.
I read the first few sections and while there were some interesting bits, I felt like the book was moving too fast and his explanations were very short and not always written in a clear way.
Then again, I think this book is aimed for someone with more knowledge of data structures and algorithms. I'll be taking a course on data structures in the next semester, so maybe I'll revisit the book after that.
Quote:Original post by BlackSeeds
if I sit at the pc and try to think about a problem I get too tempted to just jump into code.
I find sitting somewhere else for a while and writing the problem on paper and working it out has resulted in some of my best code, Its surprising how smoothly the transition from pseudo code to code can go and its great when the solution works first time.
Also thinking of the problem this way will result in better code because you know exactly what you need when you start to write the code I can remember those early days with code littered with unnecessary variables and functions.
I agree completely, and I've had the same experience several times, but I still feel like this is harder than it should be. Sometimes I need to think for like an hour before I see a simple solution, and when I finally find it, I wonder why the hell it took me so long to figure out such a simple thing.
I think it's because my thought process is not effective, so I'm looking for ways to improve it.
I took a course last semester on mathematical modelling, which might be somewhat along the lines of what you want. It basicly boils down to training yourself to expressing your problem in pure mathematics, which you then can solve with a computer using standard algorithms. We didn't use any book for the course, but the lecturer recommended First Course in Mathematical Modeling if we wanted a book about the subject.
I also second the suggestion of learning a functional language. I'd suggest learning Haskell rather than OCaml, as it won't be as easy to write bastardized imperative code in it, making it a better tool for learning functional programming. I also find Haskell's type-system more sophisticated than the one in OCaml, for good and bad. That said, I wouldn't find it surprising if OCaml/F# should prove more useful in practice. Of course, most concepts carry over between functional languages, so it should be easy enough to learn another, once you learnt one of them.
I also second the suggestion of learning a functional language. I'd suggest learning Haskell rather than OCaml, as it won't be as easy to write bastardized imperative code in it, making it a better tool for learning functional programming. I also find Haskell's type-system more sophisticated than the one in OCaml, for good and bad. That said, I wouldn't find it surprising if OCaml/F# should prove more useful in practice. Of course, most concepts carry over between functional languages, so it should be easy enough to learn another, once you learnt one of them.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
