TL;DR

“Templates” or a series of simple programs for quick prototyping, learning, language comparison/research, etc.

Motivation

These started out as my research into how many programming languages I could get installed in Debian GNU/Linux and write the hello world program[fn:1] in.

Later, after I discovered the binfmtc[fn:2] package, I wanted to see how many different languages I could “script”, so I made as many as the programs executable out of the box.

Next, I wanted to learn ways to make my code better - warnings I could enable, checks that were builtin, etc. So I added those sorts of checks where I could.

Eventually I decided that “Hello, World!” was too simple and almost useless; I wanted something a bit more, something that would show me how to get “real” work done (accessing arguments, etc), plus even more test practices such as automated tests (using builtin test utilities if possible).

The result is something I can use to rapidly prototype things in a handful of languages (some of which weren’t even initially designed for such), and play with things, extending and testing as I went along.

Goals

Each program should:

• Demonstrate “Hello, World!” functionality at an absolute bare minimum.
• Compile/link/run without warnings (with maximum error and warning checking).
• Pass with no warnings or errors other code checking tools (see run_tests.sh for examples).
• Be usuable for rapid prototyping (that is, immediately runnable/compilable).
• Have integrated tests.
• Be well designed enough to be run on it’s own (including tests) and integratable to a larger project (including tests) with a minimum of fuss.
• Implement the Trabb Pardo-Knuth algorithm[fn:3] for even more demonstration and comparison.
• Show good practice usage of other commonly used features such as:
  • Process commandline arguments.
  • Function/subroutine/method declaration, definition and calling.
  • Reading and writing files.
  • Performing network operations.
  • Searching.
  • Sorting.
  • Be well and fully documented, to the point that a run doxygen pass with requirements that everything be documented.
• Whenever possible use builtin features. If a feature isn’t builtin, use the lightest weight, best performing, most standardized option available, and fail gracefully if that option can’t be used.
• Check and handle all errors.

Extranea

While not having identical goals, the Rosetta Code project[fn:4] is similarly edifying and interesting.

Steve Yegge has some insights on language comparisons[fn:5] that are cogent, I believe.

Similarly, Paul Graham believes that you should use Lisp[fn:6] because it will help you “win”[fn:7] partly because it is succinct and has more expressive power[fn:8].

That being said, there might be reasons Lisp is not more popular[fn:9]

Footnotes

[fn:1] https://en.wikipedia.org/wiki/%22Hello,_World!%22_program

[fn:2] https://www.netfort.gr.jp/~dancer/software/binfmtc.html.en

[fn:3] https://en.wikipedia.org/wiki/Trabb_Pardo-Knuth_algorithm

[fn:4] https://rosettacode.org/wiki/Rosetta_Code

[fn:5] https://sites.google.com/site/steveyegge2/tour-de-babel

[fn:6] https://www.paulgraham.com/icad.html

[fn:7] https://www.paulgraham.com/avg.html

[fn:8] https://www.paulgraham.com/power.html

[fn:9] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html