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