<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">&lt;<a href="mailto:jgilray@gmail.com" target="_blank">jgilray@gmail.com</a>&gt;</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">&lt;<a href="mailto:yfefyf@gmail.com" target="_blank">yfefyf@gmail.com</a>&gt;</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">&lt;<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>&gt;</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&#39; and `parameterize&#39;. I don&#39;t know how to learn about these kind of advanced programming skills systematically. So I&#39;m asking for your suggestions on where I can go next.<br>



</blockquote>
<br></div>
&quot;Monad&quot; 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&#39;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>
&quot;Parameterize&quot; is both a generic term you&#39;ll find in discussions of many languages, and &quot;parameterize&quot; is also the name of a special syntactic form in Racket that has very narrow meaning, compared to the generic meaning. �Here&#39;s one practical view of Racket parameters, being imprecise with terminology... A Racket parameter, in the sense of &quot;make-parameter&quot; and &quot;parameterize&quot; (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 &quot;parameterize&quot; context, and also scoped within threads. �Use parameters for mutable global state that you don&#39;t want to keep passing around as arguments between procedures, and for thread-specific state that you don&#39;t want to keep passing around. �Use &quot;parameterize&quot; 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&#39;ve read a lot already. �I don&#39;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&#39;m not aware of any substitute for practical experience in programming.<br>



<br>
Also, when you&#39;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&#39;s file, quietly, and no one need know). �This is all hand-wavy, but I think it&#39;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>