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
to set up a priority queue for my
." 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.
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.
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.
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>
Not quite the same thing, but the DiningPhilosophers
has been used as a toy problem in many papers on concurrent programming languages. -- DavidSarahHopwood
is a perennial (and personal) favorite: LittleSimulator
It's complex enough to use when learning a software methodology
or a programming language.
I use TurMite
s when I'm trying out a system or library with
a graphical environment.
. String classes when picking up object-oriented
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?
Occasionally I've gone as far as to write a language interpreter.
I wrote a ForthLanguage
interpreter in CeeLanguage
. I wrote an
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
I have long since lost the source code for my original "toy" in
, a general purpose text filter called XTYPE.EXE, but
I use the binary all the time.
- Write a WikiWikiClone! --BillTrost
- Template-fillers -- recursive, of course, and bonus points for allowing access to the implementation language for replacements.
Video Poker. My favorite is the one I did in ForthLanguage
; 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
utilities. They're great for exercising the basics of opening files and reading/writing lines.
- With all of the cat options, one hopes. ;-)
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/