What do you code first to learn a new language, library, or framework? [closed]

Question

Every language, framework, and library has its own syntax, quirks, and pitfalls.

---

What Program, Game, etc. do you code in order to learn these unique characteristics?
How do you decide on what previous programming experience is applicable?

---

I'd imagine that the task would have to be complicated enough to force you to use applicable programming techniques and idioms, but simple enough that it wouldn't take a ton of time.

Answer 1

I don't have a single approach, because I generally learn a new programming language to complete a project, and the project existed first. However, I'll try to remember the first program (sometimes, nontrivial program) I wrote in each language to give you an idea of how things worked out for me. I'm not sure how useful you will find the list, but it's the closest thing to an answer I've got. Note that the list is more or less chronological.

1. BASIC (1982): lots of programs from the tutorial that came with the ZX81. I think my first independently-written trivial program was PRINT "HELLO", A$ but the first nontrivial one I don't remember. Maybe a program for printing casette tape inlays.
2. FORTRAN (1989): this was the language in which first-year Physics undergrads were taught to write programs. Fortunately, I've never had to write anything non-trivial in FORTRAN. Though I did write a C program for editing FORTRAN at one point. I don't think I've ever used FORTRAN for anything nontrivial.
3. Pascal (1990): I only ever wrote one Pascal program. It was someone else's homework...
4. 6502 machine code (1990): various bits of OS-call code for the BBC Micro. I think the first nontrivial one I wrote stuffed characters into the keyboard buffer of a remote machine.
5. C (1991): I forget the early stuff, but probably the first nontrivial programs I wrote were work-alikes for the APPLY and NOT programs from the tools which accompanied PC-compatibles from Zenith Data Systems. APPLY was more or less like xargs (which I work on these days, in an odd coincidence).
6. Shell/awk/sed (around 1992): I forget.
7. The Kermit scripting language (around 1992): automation for making money in a MUD by just walking around.
8. Make (around 1992): configuration for building student projects
9. 68000 assembly language (1992): a student project for drawing monochrome 3D graphics.
10. Perl (either 1992 or 1993): maintaining a Plextor configuration (it was an early web server), a system for converting TeX equations embedded in HTML into GIF representations of equations in the same HTML, and then a script for doing garbage-collection in a text dump of a database (which was badly written by someone else).
11. C++ (1993): an educational game based around estimating the statistical properties of a bunch of data displayed on a graph.
12. LISP: for maintaining my .emacs file, though subsequently I've written a mode for a specific config file syntax I think the first non-trivial code I wrote as a program to solve a problem in elisp was a transformation of a C program to add function header comments in order to comply with a stupid style guide. The program was useful because the code was tens of thousands of lines (in fact it was the mail-merge program I mention below).
13. ARM assembly (1996-7): boot code for an embedded system based on the SA-100 CPU.
14. Autoconf (1997): to make GNU CSSC buildable on a number of systems other than my own.
15. x86 assembly (1998): boot code for a 386-based embedded system.
16. TCL (probably 1998): I think I initially used this to write small GUI programs. I think the first one was an almost-toy program for controlling modem dialup on some now-ancient version of Red Hat Linux. But probably the first large body of code was in the DejaGnu dialect and was written much later for doing regression tests of findutils.
17. SQL (1999): code for performing data extraction from a database (the result was used for mail-merging; yes, this is not exciiting). The SQL was embedded inside a C program.
18. MetaPost: generating an animated GIF to use as an icon on LiveJournal
19. PHP (2000): a trouble-ticketing system (this is the only time I decided to learn a language and then looked for a project to work on in order to learn it).
20. m4 (2003): autoconf macros for building findutils.
21. Java (2004): a simulator for the Connecting For Health system's Spine. At the time, Java was probably the easiest way to do processing of XML.
22. Python (2006): because it was the standard scripting language for my current employer. I began with tweaks to existing code, I think the first nontrivial code I wrote in it was a decision support system.

I've subsequently learned also a number of proprietary languages at my current employer, but as a side effect of needing to get other things done. I also didn't bother to include a number of languages I read about but never used to build anything useful up to now (for example, Forth, Prolog, PostScript, XSLT, Scheme, Haskell).

Answer 2

I'd like to read unique characteristics one by one. Then write a smallest case to test them. Something like 8-queens.

Answer 3

A video game.

Because I love making games, and also because most games are more complex than they seem and touch almost all the kind of libraries you need to know. In particular, it makes you understand how to make interactions while the application is running, that might be hard to understand in some programming languages.

Answer 4

Whatever needs doing at the time.

I find the best way to really learn a new language is to apply it to a real world problem. Textbook samples and small canned examples typically gloss over too much since they're usually designed to make on particular point.

I find the best way to learn is to build something you need for your own purposes or if possible, something a client needs from you.