Learning D

[H. S. Teoh]

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