[racket] Where to learn advanced programming skills?

Neil,

Thank you very much for your explanation of the terminologies and your
suggestions.

Sadly, I’m just the person who has little practical programming experience.
I started learning programming seriously about a year ago. As I’m not
coding for a living, I don’t have to write much code. And every time when I
encountered some problems while coding, I thought that maybe I hadn’t got
enough knowledge to start real coding, and a new book might solve my
problems. So I just stopped coding and started a new book. Then I ended up
spending much more time reading than practicing.

Recently I realized that I was wrong, and started doing some small projects.

But I have a question here. If I hadn’t read these books, I would be just
doing the ‘rote practice’ you’ve mentioned, and write FORTRAN code for
every programming language because that’s how I was introduced into
programming. Then how can I know whether or not I could improve on some
aspect if I don’t keep reading and learning?

Thanks and regards,
Ben


On Mon, Jul 22, 2013 at 12:20 PM, Neil Van Dyke <neil at neilvandyke.org>wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130722/c50b449a/attachment.html>