Along the same lines, I suggest creating a set of small projects that you typically implement after you go through the basic samples associated with a given language's tutorials.
For example, here are a few that I try my hand at before I claim I'm proficient in a new language:
A Report Disk Status appropriate for the OS you're working on. For example, I do a "list all storage resources, including their status, drive type, total space, space available," and so on. In GUI environments, this gets thrown into a summary grid. In console windows (or STDOUT-style outputs), it's dumped as a report. A simple port of the Yahtzee game from Parker Brothers. Again, this is appropriate for the available interface (e.g. GUI vs console/STDOUT). A simple port of the card game known as "Red Dog" or "Acey-Deucy." (There's a story behind this, but I won't tell it here. Suffice it to say that the game helped pay for my first laser printer.) If the environment provides Internet services and related-interfaces like POP3, I do a quick-and-dirty polling device to report any new messages on my primary email server. A simple address book suitable for an unknown amount of telephone numbers, addresses, and/or email addresses. (This usually gets me into the available database tools pretty quickly, not to mention the reporting skills appropriate for the development environment.) A contact management application designed to track contacts (e.g. phone calls, email messages, etc) from the people listed in the above address book. (Multi-table techniques, queries, etc.) A Phone Message tracking system like the little pre-printed slips of paper. It also taps into the Address Book. An Employeer Roster/Callboard, e.g. "Who works here and are they in the office?" This was first written to support a consultancy I worked at, where everyone was in and out of the office on an irregular basis and we never knew how to respond to their phone calls, except by adding a new message to the previous application. A Personal Task Manager, e.g. "What do I need to do today and what did I forget to do last week?" (First created to help me submit accurate status reports when I was a project manager several years back.) A data import and analysis project based on one of my first "real-world" programming projects: a dBASE III (not Plus) system that imported telephone use logs, removed invalid phone numbers, and then summarized phone useage by department. It was considered a one-shot by my employer at the time, to help determine how much of the phone bill to bill back to the various departments, but it generated a lot of interesting data. I kept the original data files over the years and have gotten a lot of use out of them.
Again, this is generally for use with database oriented environments, but I've also used with native structures in in a given language, e.g. C's structs or Pascal-style record types.
A lot depends, of course, on the target language and why I'm learning it. However, I've found that by implementing these (and several other) projects that I already understand and have implemented multiple times, I find I learn the skills I really need far more quickly than I would by tackling solely through assigned tasks, e.g. employer tasks or client projects.
I wonder if anyone else does something similar. If so, care to share the pet projects you use to help make sure you're learning what you need from a new programming language or development tool?
--f
| [reply] |
You do keep yourself busy :) I have just a few things like that.
I usually go for the graphics first. I have a need for instant gratification so I write a pretty fractal generator. Mandlebrot, bifurcation or IFS. That tends to show me how much the compiler will get in my way for doing simple tasks (since fractals are essentially simple things).
In text mode, I used to enjoy writing banner and billboard style text tricks, which are handy to see how much the language's IO libraries suck (Perl sucks quite hard on that one).
Then onto the networking. Depending on the languages level I'll try something like a local network scanner or a client for something (exactly what depends on the mood). I tend to find this is the best indicator of whether a language is powerful or just a toy. Networking should be easy but so often isn't.
I'm also a pretty destructive, so I'll poke around the API and see how much I can mess with the system (at a low level), or toy with the user (high level graphics). Favourites are trying to get the server to thrash or lock up, or writing those annoying programs that hide the users mouse, or pop up a message telling the user that the computer has crashed.
____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
| [reply] |
When I mentioned that I had done something similar to this before at work, I got a lot of blank stares. I do think that going through the various problems in multiple languages is always a good idea. I actually keep track of the tough ones that I think I have a good answer for in one language, and make sure I try it out with the next language I have to learn.
I have to agree, however, that once your done, you need some small projects to work on. I also have my share of small projects that I use to make sure I know what's going on in a language. Some of the projects I do are:
- Reading and processing binary data files, like the wtmp log file in POSIX systems.
- Modules for processing CSV data. It seems trivial at first, but can be tricky depending on the language.
- Reimplementing several UNIX commands in the language. Not just the simple ones like env, but even ones like ps.
- A simple 'blog system.
- A simple HTTP Client module like LWP::Simple.
Like footpad, this list is not complete, but include some of the projects I've worked on recently to try some new things out in various languages. Like footpad, I'd be interested in hearing the projects that others use to learn or deepen knowledge in new languages.
| [reply] |
I wish that I had done this when I was learning to program. I learnt on Fortran, and since then have used Perl, PHP, TCL and other scripting languages. Now I'm trying to learn C++ and I'm finding it a very painful experience. I think untyped variables have really spoiled me!
Having said that, I'm learning from the very bottom, drawing lines, triangles and other things using just pointers - which is proving very instructive, as it has made me much more aware of what goes on 'under the hood'. Which can only be a good thing! | [reply] |
It is for that reason that I think everyone should spend a while writing in assembly language. I spent some time doing graphics demo coding for fun, and it has given me a deep insight into the inner workings. Of course, you're not going to do much work in assembler, but you get a fine feel for efficiency.
Even though you're miles above that level when writing Perl, it gives you a sense for what approaches generally are efficient, so even when you're not trying to squeeze cycles out of your code (and most of the time you shouldn't, you should be coding for maintainability), you are instinctively economical. It simply sharpens one's senses.
Makeshifts last the longest.
| [reply] |
| [reply] |