Thank you all for your valuable suggestions. I will try to be social and practice more.
Thanks again, Ben On Thu, Jul 25, 2013 at 1:29 AM, Joe Gilray <[email protected]> wrote: > Hi Ben, > > If you want to practice and need some fun problems to work on, I recommend > going to projecteuler.net and solving problem #1. Then read the forum to > see how others solved it. Solve problem #2... rinse and repeat. > > By the time you get to problem #60 you will have built a little toolbox of > reusable functions (admittedly mostly in the number-theory area) and been > exposed to many different ways to solve problems and many different > programming languages. > > Regards, > -joe > > > > > On Sun, Jul 21, 2013 at 10:34 PM, Ben Duan <[email protected]> wrote: > >> 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 >> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
