Neil and Ben, greetings, On 2013 Jul 22, at 05:20, Neil Van Dyke <n...@neilvandyke.org> wrote:
> 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. Very much so. My own practice with respect to new languages, and unfamiliar concepts within them, is to dabble enough to get the point -- what is the bit of special sauce which that language or concept brings -- but not go much further. That way, when I come across a problem which could benefit from that magic I can (i) recognise that, and (ii) go into the documentation properly, with a concrete problem to solve. This presumes, of course, that the context is friendly -- in terms of collaborators, time and risk -- to the idea of experiments. I've been dying to find a problem which _needs_ Haskell for a few years now; and it was a year or so ago that I discovered Racket 'units' were exactly what I needed for puzzle within a project then (before that I was aware of them but thought 'what's the point?'; after running into this problem, I read their documentation properly, with a particular goal in mind). Another example: I popped up earlier in this thread with the request for an example of monads in Racket. Like you, Ben, I've 'read the book' (in this case a rather abstract/formal description of monads). and understood it in formal terms. When I've fully digested Matthias's and Joe's excellent examples, I anticipate that I will 'get' monads and their application, but I won't at that point start working through exercises or search my code for places where I can retro-fit monads, and nor will I feel able to teach anyone else about them. But before long, I expect to run into some problem where I want to use something like global state; I'll think about make-parameter, and then I'll think '...or, hmmm, a monad', and at _that_ point, I will be Enlightened. A book I can recommend in this context is "Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages" (Bruce A. Tate, Pragmatic Programmers, 2010; <http://pragprog.com/book/btlang/seven-languages-in-seven-weeks>). That leads you through the dabbling in seven very different languages (namely Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby). The chapters on Scala and Ruby left me cold, the minimal Haskell there I already knew, Prolog will probably remain a curiosity for me (though who knows), Erlang is now on my looking-for-a-problem list, Clojure I learned properly for a project last year, and Io I considered and rejected for a project a couple of months ago. We're all still learning how to learn. All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK ____________________ Racket Users list: http://lists.racket-lang.org/users
