<div dir="ltr">Thank you all for your valuable suggestions. I will try to be social and practice more.<div><br></div><div>Thanks again,</div><div>Ben</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 1:29 AM, Joe Gilray <span dir="ltr"><<a href="mailto:jgilray@gmail.com" target="_blank">jgilray@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ben,<div><br></div><div>If you want to practice and need some fun problems to work on, I recommend going to <a href="http://projecteuler.net" target="_blank">projecteuler.net</a> and solving problem #1. Then read the forum to see how others solved it. Solve problem #2... rinse and repeat.</div> <div><br></div><div>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.</div> <div><br></div><div>Regards,</div><div>-joe</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Sun, Jul 21, 2013 at 10:34 PM, Ben Duan <span dir="ltr"><<a href="mailto:yfefyf@gmail.com" target="_blank">yfefyf@gmail.com</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Neil,</div><div><br></div><div>Thank you very much for your explanation of the terminologies and your suggestions.</div> <div><br></div><div>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.</div> <div><br></div><div>Recently I realized that I was wrong, and started doing some small projects.</div><div><br></div><div>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?</div> <div><br></div><div>Thanks and regards,</div><div>Ben</div><div><div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 12:20 PM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ben Duan wrote at 07/21/2013 10:25 PM:<div><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br> </blockquote> <br></div> "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.<br> <br> "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.<div> <br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I have read some commonly recommended books like:<br> </blockquote> <br></div> 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...<br> <br> 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.<br> <br> 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.<br> <br> 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.<br> <br> Neil V.<br> <br> </blockquote></div><br></div></div></div></div> <br></div></div><div class="im">____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> <br></div></blockquote></div><br></div> </blockquote></div><br></div>