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 <[email protected]>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. > >
____________________ Racket Users list: http://lists.racket-lang.org/users
