Yes, I get that. It's a bad idea. Showing atypical "promotional" cases for each language encourages faddishness and silver bullet cults; it's irresponsible and unprofessional. If you're shopping around for a language then nothing is worse than selected sweet spot cases. Unless they are a fair-ish benchmark for a language that excels in a clear area, like R, APL and Awk and you're looking for a glorified DSL.

I'd say that its better to have the same tasks for each language if you're evaluating a general purpose tool. Obvious ones would be, from simple to complex:

- Some of the unix command line utilities like wc (some of these might be single liners)

- OXO, Caesar cipher (10 lines or so)

- The Markov chain program from the Practice Of Programming

- Life

- A simple spheres only ray tracer like the one in Graham's Lisp book

- A simple calculator program like the one in Hutton

- The recursive 2D shape program I've mentioned in other posts today

- A version of the classic Traveller/Elite trading system - a really nice little toy business rules system that can be code either minimally or to show off the funkier features of a language to get more flexibility and more interesting pricing rules. Minimal version would be a few tens of lines and the config file declaring items.

If you want to see a language comparison done responsibly, look at Kernighan and Pike's "Practice Of Programming."

Thank you for criticism and tasks examples. But I still think it isn't such a bad idea. Because if somebody get excited about some language (even if it is based on "promotional" cases) and he learns this language more by himself then it's great. I don't think somebody will judge about whole language by few tasks. He may get interested or dislike the language, but I doubt there will be silver bullet cult based on few tasks. By shopping language I mean choosing some new fun language to learn, not to solve particular practical task. Nikita