Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Do your homework!

by FoxtrotUniform (Prior)
on Aug 21, 2002 at 19:29 UTC ( [id://191847] : perlmeditation . print w/replies, xml ) Need Help??

Lately I've been reading a number of books with included exercises (ANSI Common Lisp, Structure and Interpretation of Computer Programs, and Expert C Programming, in particular). I'm finding it useful to work through the exercises not only in the expected language, but in others as well, naturally including Perl. (In fact, I've been working through them in C, Perl, and Common Lisp. Scheme's on my to-do list.)

This is a great way (IMO) to:

  • Improve your general programming skills.
  • Expose yourself to different ways of doing things.
  • Find out a language's strengths and weaknesses in very difficult to ignore ways.
  • Generally stretch your brain.

I encourage my fellow monks to consider using multiple languages the next time they read a suitable book. Most of the problems are small and well-defined, and won't take a hell of a lot of time. (Most of them are fairly easy, to boot.)

And if you don't know any other languages, this might not be a bad excuse to learn one....

F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

Replies are listed 'Best First'.
Re: Do your homework!
by footpad (Abbot) on Aug 21, 2002 at 23:35 UTC

    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?


      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.

      I didn't believe in evil until I dated it.

(jeffa) Re: Do your homework!
by jeffa (Bishop) on Aug 21, 2002 at 21:06 UTC
    I concur. My graduate Systems Programming course met for the first time last night. I was surprised to find that our professor is allowing us to implement our projects in any language (that can access common system calls). However, instead of choosing Perl, i am going to choose C because i want to 'get a deeper' understanding. Our first assignment is a client-server app that functions much like rsh (next one will be more like ssh). We all know that Python, Java, and espcially Perl can solve this problem quite easily - i hope to gain more from implementing this puppy in C. Plus, i am teaching 3 C++ labs and need to get back into the swing of doing it the hard way. ;).


    (the triplet paradiddle with high-hat)
Re: Do your homework!
by Steve_p (Priest) on Aug 22, 2002 at 03:52 UTC

    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.

Re: Do your homework!
by physgreg (Scribe) on Aug 21, 2002 at 21:14 UTC
    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!

      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.

        It is for that reason that I think everyone should spend a while writing in assembly language.

        I'd successfully blanked that course out of my memory until you brought it all crashing back (whimper).

        Neil Watson