MyFavoriteToyProblem

Last edit September 30, 2009

I think you know what I mean; I think you have at least one problem that you solve with each language or methodology as you learn it. It's a LearningPattern, related to BodyFollowsEyes.

It's the problem you solve each time you start learning a new programming language, software platform, hardware platform, or <shudder> methodology. It's a way of familiarizing yourself with the environment, a way of ensuring that your assumptions about how things work are correct. It's not too trivial a problem, otherwise you're really not learning anything; it's not too difficult, otherwise you'll be quickly defeated by the complexities and will abandon the language. (Possible relation to or subdivision of GoldilocksSolution?)

It's a means of gaining confidence by solving the familiar within an unfamiliar context, a specific focus while learning an abstract grammar, a gauge or barometer of how well you've learned things. Once done, you can even dismantle and generalize the solution, cannibalize it for parts, or ReFactor it into a framework, a prototypical example, or a template boilerplate.

You might even not code it up, simply use it to provide a context or framework for learning: "Ah, so I can use an OrderedCollection to set up a priority queue for my ElevatorSimulation." Or, "Hm, so I can use the StatePattern to model the internal states of my TurMite." Or, "How would I make a SpikeSolution of my GameOfLife?" It's an intensely personal thing, and you often feel proprietary towards your toy problem.

MyFavoriteToyProblem

You're excited by a new environment, such as a programming language or a methodology. You have fiddled with it for a little bit, trying out trivial examples, to get a feel for the grammar, or the water, or the social situation. You're not confident that you can use the environment to solve major problems yet.

Therefore, solve a non-trivial problem with which you are intimately familiar. Exercise your skill in the new environment by implementing a solution to that problem, to ensure that your assumptions are correct, to gauge how well you've learned the rules of that environment, and to build confidence.

However, you don't have time for it. You must jump in at the deep end, before you're fully cognizant of even some of the rules of the game. <needs more>

--AllanBaruz

Not quite the same thing, but the DiningPhilosophers has been used as a toy problem in many papers on concurrent programming languages. -- DavidSarahHopwood

ElevatorSimulation is a perennial (and personal) favorite: LittleSimulator. It's complex enough to use when learning a software methodology or a programming language.

I use TurMites when I'm trying out a system or library with a graphical environment.

Conway's GameOfLife. String classes when picking up object-oriented languages.

More examples would be appreciated, of course. As this is my first description of a pattern here (or anywhere!) I am keenly interested in comments and criticisms as well. --AllanBaruz.

One of my favorites is to write a pocket calculator. Sounds trivial. There are I/O issues (you can't just type a line and press <Enter> and you can't just mouse), there are user interface issues, there is the obvious math stuff, and a bunch of little silly things that become problematic depending on the language you've chosen. Some languages *really* aren't good for this. Some of the "toys" I've written have tried to TakeOverTheWorld as they've acquired features.

Occasionally I've gone as far as to write a language interpreter. I wrote a ForthLanguage interpreter in CeeLanguage. I wrote an 8086 AssemblyLanguage simulator in FoxPro.

I used to use this technique when teaching languages: we set out to write LPRINT.EXE in AssemblyLanguage, the object being to allow the user to type lines analogous to those used in BASIC to control the printer from the DOS command line. LPRINT, in its simplest form, allows commands like "LPRINT 27 65" which does precisely what the BASIC line "LPRINT CHR$(27)+CHR$(65);" does. But then we allowed different number bases for input, string inputs, allowed redirection of output, take input from a file source, escapes in strings ("hello world\r\n"), and so on. Eventually the toy would TakeOverTheWorld.

I have long since lost the source code for my original "toy" in CeeLanguage, a general purpose text filter called XTYPE.EXE, but I use the binary all the time.

-- GarryHamilton

Write a WikiWikiClone! --BillTrost
Template-fillers -- recursive, of course, and bonus points for allowing access to the implementation language for replacements.

TicTacToe ?

Video Poker. My favorite is the one I did in ForthLanguage for PalmOs; it was especially fulfilling to watch members of my family play it for a few hours.

That's a toy problem? How many Forth words? Is the GUI interface so straightforward that it didn't take more than a toy amount of effort? If so I should check it out, which Palm Forth? GUIs are usually a pain in toy problems.
- Probably QuartusForth. I can attest that you can throw stuff together pretty quickly using it (given that you already know Forth pretty well). It is very well supported. -- IanOsgood

I also like to implement the UNIX cat and tee utilities. They're great for exercising the basics of opening files and reading/writing lines.

With all of the cat options, one hopes. ;-)

-- KrisJohnson

Blackjack

Fibonnaci Sequence Generator - shouldn't take more than an hour in most languages. (Adjust for familiarity.)

In learning a new programming language, toolkit, or library, some people write "Hello, World". One I knew would write a hex dump utility. I calculate Mayan dates. Probably my very first real programming effort involved taking a Mayan date calculator written in FORTRAN and re-creating it in C. Since then I've rewritten it many times, and used the basic code as the core for implementing a prototype to learn new things, including web CGIs, servlets, Mozilla XPCOM, Web Services, and more. It was the natural choice for my foray into FIT: http://cmdev.com/antfit/examples/. --StevenNewton