3 ms·

I learn by modifying. I think just about every language I have mastered has been because I started learning it by hacking on someone else's code. (mastered = k

I learn by modifying. I think just about every language I have mastered has been because I started learning it by hacking on someone else's code. (mastered = know well enough to implement projects from scratch with ease) I would say I 'know' probably a dozen or more languages enough to read/write useful code, but have only mastered maybe five... and all of those because I spent a lot of time dealing with existing code, so I learned by toying with it. Sadly if I don't use something for quite a while (like Scheme, which I used to live and breathe, but haven't used in probably three years), I become pretty rusty with it, but I suspect this is normal. My current languages of choice are probably Ruby, JS, and Arc (for the fun factor). I actually learned ruby because I didn't like Rails, and tried for a while to write my own framework, before discovering Merb and tinkering with it instead. JS always scared me for some reason, but I finally picked it up because I wanted to use jQuery and ended up tracking down bugs in their UI stuff. Arc I am learning currently, just by playing with stuff submitted by others. So in short, I learn by modifying other code, and eventually get comfortable enough that I can just write from scratch. I actually like the book examples, because they put the finished code online. I don't even bother reading the chapter where they explain the code... I just load it up and start tinkering and learn from that.

xirium 19y ago
Leveraging existing code is an undervalued skill. It gives satisfaction when you're learning. It also gives immediate benefit to the programmer and other users. "Hello world" is great for set-up of your development environment, but after learning a few basic structures, you'd get great benefit from just wading into an open source project. Should you learn more theory before you get overwhelmed by the size of a codebase? No. Nowadays, many paid programmers are unaware of recursion and quicksorts but it doesn't stop them earning very good salaries.
- Xichekolas 19y ago
  As far as learning languages go, I agree, knowing how to write a quicksort doesn't help you learn Language X. When people talk about learning languages, I assume they mean learning the syntax/idioms. For that, it makes sense to look at a lot of existing code (to me at least). When it comes to actually implementing something substantial (once you are past the tinkering and learning stage), I find it sad that so many programmers can actually get away with not knowing basic things like recursion and how a quicksort works (and I have worked with quite a few like this in the past). I had a guy argue with me that his sort (which was basically a selection sort), was faster than the quicksort/mergesort I was suggesting because "it is fewer lines of code and therefore fewer machine operations". Apparently to him, being able to read and understand it faster meant the computer would likewise do less work. Sadly, he was my boss, and I knew then I should be moving on. Most languages today will do mundane things like sorting for you, but I still argue that knowing why Tail Recursion is the preferred way to recurse and how nesting loops can get out of control are vital to do anything useful. I would rather interviews ask theoretical questions like this instead of silly "can you regurgitate the syntax to do Y in Language X?" questions.

xirium 19y ago

Leveraging existing code is an undervalued skill. It gives satisfaction when you're learning. It also gives immediate benefit to the programmer and other users. "Hello world" is great for set-up of your development environment, but after learning a few basic structures, you'd get great benefit from just wading into an open source project. Should you learn more theory before you get overwhelmed by the size of a codebase? No. Nowadays, many paid programmers are unaware of recursion and quicksorts but it doesn't stop them earning very good salaries.

Xichekolas 19y ago
As far as learning languages go, I agree, knowing how to write a quicksort doesn't help you learn Language X. When people talk about learning languages, I assume they mean learning the syntax/idioms. For that, it makes sense to look at a lot of existing code (to me at least). When it comes to actually implementing something substantial (once you are past the tinkering and learning stage), I find it sad that so many programmers can actually get away with not knowing basic things like recursion and how a quicksort works (and I have worked with quite a few like this in the past). I had a guy argue with me that his sort (which was basically a selection sort), was faster than the quicksort/mergesort I was suggesting because "it is fewer lines of code and therefore fewer machine operations". Apparently to him, being able to read and understand it faster meant the computer would likewise do less work. Sadly, he was my boss, and I knew then I should be moving on. Most languages today will do mundane things like sorting for you, but I still argue that knowing why Tail Recursion is the preferred way to recurse and how nesting loops can get out of control are vital to do anything useful. I would rather interviews ask theoretical questions like this instead of silly "can you regurgitate the syntax to do Y in Language X?" questions.