It seems a bit large though -- roughly 600 lines of code, average. So that suggests a project of about 200 lines would probably be nearer optimal for learning.
I do the same thing, I find it's a great way to compare the differences in implementing similar designs and functionality across platforms and languages. Highly recommended.
I prefer to try something new each time a start with a new language. I don't see the reasoning behind recreating when you can try something new. New language, new idea. Kill two birds.
1. Borrow an introductory guide that is targeted at people who've programmed before, and read the first 2-3 chapters. Return it to whoever you borrowed it from.
2. Sit down at computer and start to write code. If you get stuck, visit reference manual, and follow it through until you are un-stuck.
3. (For C/C++ programmers) Assume there is somebody constantly looking over your shoulder at whatever you're doing, and telling you that there's a really simple library call that will do all of whatever you've just done, but in one function call. Then assume this notional person is right, and go and find it.
4. GOTO 2
Do:
- Find, learn your way around and generally become quick at using some kind of computer-based reference manual that is full-text-searchable and well-indexed, because you'll end up using this a lot.
- Familiarize yourself with relevant code browsing features so that you can quickly visit source code for runtime libraries and (where applicable) VM. Then use it a lot to visit the implementations of things and just generally have a look round. This is handy for various purposes, but I mostly use this to find more things to search for in the documentation.
- Ask stuff of people who are familiar with the language or whatever. If they offer you code, put it somewhere where it won't get lost, but don't look at it.
- Locate a copy of the language spec, or what passes for one, and figure out how to read it, so that when something perplexing happens you can tell whether it's official that things should be this way.
Tastes differ, but I avoid doing all the following, so I might be so bold as to suggest that others should avoid hem too:
- Looking at source code other than for runtime library/VM/compiler/etc.
- Copying code from other people, including from runtime library
- Reusing framework code, wizard code or other such junk
- Paying much attention to non-specific advice given on Stack Overflow. (Specific answers to specific, direct questions are fine. General advice... usually ignorable.)
This all probably sounds a bit odd, but it seems to have stood me in good stead.
Try to learn the topic top down rather than bottom up.
If you reach for a technical book about some new language, chances are that it will be broken down into chapters, each of which goes into a lot of detail about some specific area.
By reading material like this, you can come away with a lot of specific memorized details, but without feeling like you've learnt anything about the overall topic or are able to put it into practise.
Instead, I like to start at a really high level, asking what problems the technology solves, what is the sales pitch for it, where should it be used and where isn't it appropriate. Understanding things like this give you an angle to learn the technology from.
I'll then drill down a little and try to understand the main concepts. I'll make a few diagrams at this stage, identifying the main components in the technology, and start to question why it works in the way it does.
After that it might make sense to drill into specific areas as and when I need or for reference.
I think it's really important to see the wood for the trees when learning technical topics. The reference details are a Google search away. It's understanding the concepts and making the mental leaps that are the real meat of the learning.
Wow! Lots of great suggestions here. I especially liked @fogus' suggestion on maintaining a list of pet projects that you work out in each language. This way, you don't struggle with the domain any more - you just have to fight one learning curve.
With that said, I believe there is a term used in swimming, and one that I use to explain how I learn new languages - "Total Immersion".
Here's how I do it - open up your favorite reader, and subscribe to a couple of blogs that talk/explore the language that you are playing with. There are usually a few "gurus" that you can follow. Another way to find good people is to put a search for a particular hashtag in twitter. Or join the Google Groups page (if your language has one).
Then every day spend an hour or so reading - initially none of it makes any sense (at least no to me anyway :D) - but I have learned that over time my brain latches on to these "snippets" of wisdom, little tricks in the language that you can eventually "grok" as you learn more about that language. It's these "Ah! That's what xyz was talking about" that really make things interesting.
Furthermore, you could attempt to partake in the conversation (even if you lurk, like I do). People ask all kinds of questions on google groups or twitter - even if you are not confident enough to respond, you can attempt to find an answer on your own. What this does for me is that sometimes it's a small enough question that you can start to delve into and get a better understanding of one particular aspect of the language.
For e.g. recently on the Clojure user Group someone asked "Pretty-print with metadata?" [https://groups.google.com/forum/#!topic/clojure/5LRmPXutah8] - I had never thought about it, but it is an interesting problem. So I sat down to see if I could find a way to do it out of the box. No cigar. So then I wrote a small function to make it happen. Needless to say, my solution was no where nearly as elegant as the ones posted in response, but then I got see where I went wrong :)
For a language, once it has grabbed my interest, I read the reference manual or something fairly close to it (Stroustrop instead of the ANSI C++ spec)
Some languages and most frameworks do not have a reference manual. For those, the challenge is to decide what source is authoritive, whether it is up to date, etc.
I rarely start working with a technology before having read or at least browsed a few hundred pages. Reason for that is that, for me, reading a reference is a more efficient way of getting a feeling of what a language can do than trying it out. Also, if the reference does not exist, chances are it isn't technologically interesting and/or it will not get popular. In either case, the technology isn't worth learning about.
I use that language/framework to create something. For me I don't retain information from reading a reference manual cover to cover. I need to actively work with the language/framework in combination with the reference manual which helps give it a context. I find this helps me retain and understand the things I am trying to learn.
When i decided to learn PHP, i went to the php.net and started learning the "syntax".
And then i started "memorizing" the functions. But it turned out i was just wasting my time. Ok, i learnt some stuff of course, but just peanuts.
I decided to change my way.
I set a goal; "to make a website". Then started to coding.
In the beginning, on every line i stucked.
I asked myself & Google "I need to do this. how can i do it?"
For almost every line, i googled for something.
By time goes on, it started to take place in my mind.
On every step, i set another goal. When i ask myself "i want to do something like this, how can i do it?" , I started to (had to) learn something on CSS, JavaScript, Jquery.
For me the steps to learn are;
1. Set a goal. Make it hard! While getting to that goal, you'll learn lots of things.
And finally when you reach that goal, set another one, more harder.
I'm early in the stages of learning Clojure, so here's what I've done so far and what I plan to continue doing.
- I recently joined a local Clojure group on meetup.com and started attending meetings.
- I know the main web sites for the language, including a great searchable documentation site I use.
- I already know Scheme and Common Lisp, so my focus is on grasping the differences with Clojure.
- I just completed the Clojure koans I forked from GitHub.
- I started reading a Clojure book.
- I have played around with the REPL.
- I have started using a serious development environment including Leiningen.
- I will look into a testing framework to use as I experiment further.
- I have some specific tasks I want to try to implement in Clojure involving concurrency to get a feel for what I can usefully get out of this language.
- I'll look at people's code, of course, to get an idea of good and idiomatic practices.
3. Google[insert favorite search engine] for code in your language that does kinda what you need.
4. Move the code around until you get what you need done/working.
5. Repeat 2-4 until you have done your project.
6 Repeat 1-5 on three projects.
7. Read blog articles about how to write properly in that language.
This is basically the formula I used since childhood. The other way around of learning syntax is too boring and tedious. Starting out with projects means at the end of the process you have something to show, and the syntax has contextual clues for easier memorization. Additionally, you incorporate other people's programming habits that took years to develop[you wouldn't get all, but you would get some] .
What I've found to be the most efficient way of learning new programming languages..is not by using it. While is it true that you need to use it to gain mastery. It is best to learn new language as simply as a programming language. That means studying its features rather than syntax and grammar. Is the language object oriented, functional,or multi paradigm? The point being that syntax and grammar changes all the time from languages to languages, but programming paradigm rarely changes. Truly grasping the idea of a programming paradigm will make you learn new language a lot faster..and new programming languages emerge almost every year.
Open source code. Tutorials, screencasts, books, they teach you /how/ to code, they don't actually get you to do it. You can get to the end of a book and have memorized all the code samples but still be without a flying fuck how to write a program or fix a problem.
Keep a reference manual open in a background tab and dive in.
Go to a popular project on Github, go to the issues tab, pick a random issue and try to fix it. This will give you more insight into the ups and downs of a language than anything else. "Pet projects" are stupid as they have no real world use and you already understand most of the logic behind them, solve problems and make things happen.
I usually start with a small project, sometimes something I've implemented before. The first thing I do is start from a Hello World example, and then expand that with features to get to the program I want. I do these features from examples, and I manually type the examples over. This way I get my fingers and eyes used to the syntax quickly. Once this abomination of a program that consists of bad structure and examples from the web is done, I track down some proper examples of complete programs to see how things should be done and investigate the differences between that and the approach I've picked up so far.
I read just enough about it that I can get a "Hello, World" program written and running. I then try a few things to modify that program to learn more about the language. In particular, I'll often try breaking it in several different ways. If I know what I broke, then I can learn how to interpret error messages.
Once I've done that, it's time to start on a small project. I just start coding and looking up what I need to know. I know in advance that my code will be bad. In fact, the more often I encounter some piece of documentation that leads me to say, "Oh, I should have done it that way", the more I learn.
I subscribe to podcasts and watch a couple video presentations.
The idea is to quickly get an understanding for the concepts behind the language, when you dive into the topics you already have a mind map to file them under. This also gives you a feeling for the community.
Next I read the top questions on stack overflow and join the IRC channel on freenode.
By learning from the common pitfalls made by others this saves me from a lot of startup frustrations which would otherwise prevent me from actually using the language.
I found writing some complex data structures is great way to learn basics of language. And then you can iterate and improve your data structure to make the code more idiomatic and/or faster.
I grasped Common Lisp with writing `Hash Array Mapped Trie` data structure(one of the data structures lie within some of Clojure's persistent data structures). It helped me understand both the particular data structure and the language.
I find this question especially interesting in terms of, that it is not the first language you learn. You don't want to spend time on a book, that is reintroducing common concept to you, this is just boring. I have, however, still the desire to buy a book for this purpose and read it from beginning to end including all exercises, but thinking rational about this, that is utter nonsense.
I used to just start poking around in it. Now I combine putting the reference manual in to Anki (although any Spaced Learning System should work) while I do it. This way you remember and learn all the edge cases, so they're there right in your head as you're learning to flow program it.
My first thought was "Hmm it may be useful for learning nongui languages, but what would happen if I try to learn ExtJs with it..." Then it occured to me, you have to put a gui to present results.
I usually just redo a set of projecteuler.net problems, until I get enough context of the language to feel like I don't have to look up every single language construct.
My preferred method is to find the equivalent of K&R for that language, read it, and then start trying to program, supplemented with internet searches if I run into something that it turns out I didn't understand, or to find neat libraries.
Unfortunately, few books approach K&R's quality. I don't like books that are written under the assumption that I will be sitting at a computer as I read them, and expect me to be typing in code and running it for everything they cover.
If I can't find a satisfactory book, I'll cobble together something from what I can find on Safari Library, free online books, and assorted internet searching.
A while back I tried an interesting experiment. I needed to learn some Lua, because I wanted to write some add-ons for an MMORPG I was playing (Warhammer Online). Lua has pretty good documentation, but I had recently read that famous article on digital natives vs. digital immigrants, whose theses was that digital natives (people who grew up in the digital world) have a fundamentally different understanding of technology than those of us who grew up in the pre-digital age and immigrants to the digital world. The natives are multitasking do-ers, who want to learn things as they need them. They aren't, supposedly, like the immigrants, who think the way to learn things is to read a book, then start doing.
I decided to take a more native approach with Lua to see how that worked out. So, instead of reading the Lua documentation, I downloaded and looked at a few Warhammer Online add-ons to see how they were structured and get a feel for what Lua code looks like. I looked at the Wikipedia article on Lua to get an idea of what kind of things the language had.
Then I started coding. Whenever I wanted to do something that I knew the language could do, but didn't know how, I Googles. So, for example, the first time I wanted to initialize an array with literal constants, I'd Google for that.
This actually worked. I don't know if my Lua code is any good, but comparing to what I see on other people's add-ons, it seems in the same league at least. I would not put "Lua programmer" on my resume just yet--I'll wait until I actually read a complete manual before doing that. I did a similar experiment with JavaScript, with similar results.
I'm not convinced, though, that the "native" approach is actually good. Yes, I got satisfactory results, but I think much of that has to do with the fact that I've been a professional programmer for 30 years. That has given me good filters for recognizing bad code, so when I'd Google for how to do something and get back and answer that turned out to not be a good way to do whatever it was, I'd sense that and keep looking. Someone with just a couple years or less experience would probably have incorporated a lot more things from the bad examples on the net.
There are a bunch of things you need to be able to do in any programming language for it to be useful for real work, e.g. get parameters from a command line, connect to a database, read and parse a file on disk, send a message to syslog, etc etc. I start by implementing a trivial program that does these things, and in the process pick up the syntax, and overview of the libraries, and end up with a framework on which to actually build my first real program in that language on.
