[racket] Where to learn advanced programming skills?

Ben Duan wrote at 07/21/2013 10:25 PM:
> In this mailing list, I can always find some concepts which are not 
> familiar to me. For example `monad' and `parameterize'. I don't know 
> how to learn about these kind of advanced programming skills 
> systematically. So I'm asking for your suggestions on where I can go next.

"Monad" is a concept from pure functional programming that is almost 
never used in Racket (although people have implemented monads using 
Scheme and Racket).  If and when you decide you want to learn pure 
functional programming, I suspect you'd take a detour from Racket at 
that time, and spend at least a couple months working through a book and 
language designed specifically for functional programming, like Haskell.

"Parameterize" is both a generic term you'll find in discussions of many 
languages, and "parameterize" is also the name of a special syntactic 
form in Racket that has very narrow meaning, compared to the generic 
meaning.  Here's one practical view of Racket parameters, being 
imprecise with terminology... A Racket parameter, in the sense of 
"make-parameter" and "parameterize" (you can look them up in the 
searchable Racket documentation) is a way to implement a mutable 
variable that is global and/or has dynamically-scoped bindings.  Changes 
to these variables can be scoped dynamically within a "parameterize" 
context, and also scoped within threads.  Use parameters for mutable 
global state that you don't want to keep passing around as arguments 
between procedures, and for thread-specific state that you don't want to 
keep passing around.  Use "parameterize" when you want to establish a 
new dynamic scope for a mutable variable, such as for thread-local 
state, or if you with to temporarily override a value within the same 
thread.

>
> I have read some commonly recommended books like:

You've read a lot already.  I don't know how much practical programming 
experience you have, but this reminds me to make a suggestion for anyone 
reading this email who is learning programming and doing a lot of reading...

If someone has access to a computer, then my suggestion at this point is 
make sure that they are spending more time practicing programming than 
they are spending on reading.

By reading books and doing problem sets only, and reasoning about 
programming in their head atop that, then someone might be able to 
understand programming theory as a mathematician might.  But if they 
want intuition and insight into how to build and evolve sustainable 
systems in the real world, then I'm not aware of any substitute for 
practical experience in programming.

Also, when you're getting programming experience, my suggestion is *not* 
to do it as rote practice, like trying to master just the mechanics of 
playing a particular piece on a musical instrument.  Instead, I suggest 
doing programming as experiments in method, like a creative performer or 
an innovative composer, and pick up experience with the rote mechanics 
along the way.  You will wind up with mistakes, but you will learn from 
them, and you will also wind up with wins you would not have if you did 
not experiment.  Programming has a lot less material available to learn 
via books than, say, medicine does, and you can experiment without 
killing any patients (just delete the patient's file, quietly, and no 
one need know).  This is all hand-wavy, but I think it's a way to think 
about programming that results in a greater mental toolbox.  It beats 
treating programming like a clerical skill, or pretending that 
programming is understood by anyone better than it is.

Neil V.