On Fri, Jun 07, 2013 at 01:01:54AM +0200, bearophile wrote: > H. S. Teoh: > > >The way to improve your coding skills is just to write > >lots and lots of code. The more you write, the better > >you'll get at it. > > Doing lot of exercise is not nearly enough. You also must do them > "smartly". And it's far from obvious what that means. And most > schools, movies, TV and most friends don't give you an idea of what > that "smartly" means. [...]
You're right. My statement is predicated upon being able to learn from your mistakes and progress, but when it comes to coding, it's not always obvious what's a mistake unless you have some outside input. For example, I first started coding in the ancient Applesoft FP/BASIC, and cut my teeth on writing spaghetti code (the few industrial examples I've seen at the time didn't help either -- that was the way people wrote code back in those days). It wasn't until I picked up a book on -- of all things -- assembly language programming on the PC, that I learned about modular programming and code reuse -- because without a logical modular decomposition, assembly code QUICKLY gets completely out of hand and unmaintainable. Code reuse was also necessary to make writing non-trivial applications in assembly language tolerable. However, it was only when I started learning C in university that I first really learned about functional abstraction -- even in my previous modular code, there were tons of globals everywhere and function interfaces were ad hoc and not well-planned. With C, I began to learn how to encapsulate chunks of code in functions. Of course, university CS courses also helped me with learning proper abstractions (y'know, avoiding globals, goto's, etc.). In my later years in university, C++ first made its mark on the industry, and that was when I first learned OO programming. Around that time I had cut my teeth on writing ray-tracers and B-trees, so I guess you could say my education helped a lot, even if much of it was impractical things like uncomputability theory -- certainly an interesting subject, but it's a bit sad if a CS graduate knows more about uncomputable problems than computable ones! (I have actually seen people like this.) In grad school I wrote a compiler in an elective course, and a decompiler for my thesis (haha, the irony). By then I had learned several other languages, including Concurrent Clean, Perl, Java (the earliest versions), and a bunch of others. Then I went into the workforce, and that was when I first encountered a "real" software system... and saw all of the infelicities that goes into making a commercial product alongside the ingenius ideas. That really drove me to reflect deeply about maintainability and proper software design. Ultimately it would drive me to look for a better programming language that would be both practical, encourage proper programming style, and still retain close-to-metal performance. Eventually this led me to D. :) T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
