An experiment in implementing the same recursive counting problem across programming languages, from ALGOL, B, BCPL, and Simula to contemporary systems languages, functional languages, scripting languages, and foreign-function interfaces.

This is primarily a collection of source-code examples and historical build notes, not a curated set of verified modern builds or a standardized performance benchmark. Some compilers and interpreters are obsolete or require patches. The 150 directories are implementations and language combinations, not 150 distinct programming languages.

• The counting problem
• Reference results
• Quick start
• Language catalog (A–Z)
• Cross-language interoperability
• Language families and lineages
• Versions and historical toolchains
• Build status and reproducibility
• Contributing
• License

The programs count ordered sequences of card ranks that can be drawn without exceeding a running total of 21, from a finite single deck, after a dealer's exposed card has been removed.

The deck is represented by ten ranks, with values 1, 2, ..., 10 and initial multiplicities

rank:        1  2  3  4  5  6  7  8  9  10
multiplicity:4  4  4  4  4  4  4  4  4  16

Here rank 1 represents an ace, always counted as 1; rank 10 combines tens, jacks, queens, and kings. The programs do not implement the complete rules of casino Blackjack.

For each possible dealer upcard rank d, the program:

1. Removes one card of rank d from the deck.
2. Considers each possible rank j for the player's first card, removing one such card.
3. Recursively draws at least one additional player card; each legal new prefix (total at most 21) contributes one outcome, representing the choice to stop after that draw.
4. Also explores further draws when the running total is below 21. Draws that bust are discarded, and a total of exactly 21 cannot be extended.
5. Sums these counts over the ten possible initial player ranks.

Important conventions: A hand with only one player card is not counted. Rank order matters, but individual physical cards of the same rank are indistinguishable for counting purposes. The rank multiplicities limit the available draws; they are not probability weights. Thus the result is not the number of suit-distinct deals, nor a probability, nor the number of winning Blackjack hands.

Let c = (c_1, ..., c_10) be the available rank multiplicities, and let F(c, s) count the admissible nonempty continuation sequences from subtotal s. Writing e_k for the unit vector of rank k,

F(c, s) = sum over k with c[k] > 0 and s+k <= 21 of
             (1 + (s+k < 21 ? F(c-e[k], s+k) : 0)).

The 1 counts the option to stop after drawing rank k. The recursive term counts longer sequences. Starting from the full deck c0, the count for a dealer upcard of rank d is

N[d] = sum over available initial player ranks j of
           F(c0-e[d]-e[j], j).

The implementations use direct recursion and, in some cases, variations or cross-language calls. The formulas above specify the intended reference calculation; they do not prescribe an optimization strategy.

The reference C implementation is c/outcomes.c. Its checked-in output is c/outcomes.txt.

Some programs print zero-based rank indices (Dealer showing 0 through Dealer showing 9) instead of card values (1 through 10). The output labels therefore differ by one, but the reference counts are in the same order. The final sum is over rank categories, without weighting by the number of physical dealer upcards.

outcomes.txt files may also include wall-clock or CPU timings measured on their original systems. Those timings are historical and should not be compared as a controlled language benchmark.

From the repository root:

cd c
cc -O2 -std=c11 -o outcomes outcomes.c
./outcomes

The final line should be:

Total partitions = 6398430

cd python
python3 outcomes3.py

Python 2 and Python 3 variants are kept separately where they existed historically; Python 2 is obsolete and is not required for the Python 3 example.

• Cyclone: a safer dialect of C; historical cyclone toolchain required.
• ALGOL W: can use the companion aw2c translator.
• SuperPascal: uses the companion SuperPascal compiler/interpreter.
• Niecza: an implementation targeting the CLR for Perl 6 / Raku.
• BCPL and B: early predecessors in the C family.

These entries illustrate historical toolchains; their build commands are not certified against current Linux distributions.

121 single-language or runtime-variant directories, in alphabetical order. The first link opens this repository's implementation; the last link opens the compiler/interpreter project or language documentation. The descriptions summarize each language or variant, not a tested compiler version. For exact historical commands, consult the directory's own README.md when available.

Some entries are distinct implementations of the same language (such as CPython/PyPy/MicroPython/Jython or several Scheme compilers), and others are embedded languages or scripting environments (such as PostgreSQL SQL and shell languages). They are retained as separate implementation directories, not counted as 121 different language specifications.

Important historical name collisions: cobra/ is the older Chuck Esterbrook .NET/Mono language (not later languages also called Cobra). idl/ uses the GNU Data Language (gdl) interpreter, as shown in its README. niecza/ is a Perl 6 implementation targeting the CLR, not a separate language specification. Likewise, stalin/, chez/, chicken/, gambit/, larceny/, and vicare/ are distinct Scheme implementations.

The remaining 29 directories deliberately mix languages or build separate native libraries. They are indexed separately so they do not inflate the number of distinct programming languages. Descriptions below are based on the checked-in README commands and representative source calls; no recent end-to-end build is implied.

In particular, the repositories illustrate several different FFI mechanisms, not just calling a second program: native shared libraries with C-compatible ABIs, dynamic linking (dlopen), Python ctypes, Python cffi, Julia ccall, R .C(), and Ruby FFI. These APIs have different ownership and ABI assumptions; a successful call is not by itself a portable interface contract.

This is a conceptual map, not a rigid taxonomy. Arrows indicate major historical descent or influence; shared runtimes and similar syntax do not imply direct descent. A language may appear in more than one family.

• ALGOL line: ALGOL 60 influenced ALGOL W and ALGOL 68 along different branches. Simula extended ALGOL 60 with classes and coroutines and became an important ancestor of object-oriented programming.
• Wirth line: ALGOL W and other ALGOL ideas informed Pascal → Modula-2 → Oberon. Modula-3 developed from Modula-2 ideas; Zonnon is a later Pascal/Modula/Oberon-family language.
• Pascal extensions: SuperPascal extends Pascal with structured concurrency; Vector Pascal extends it with array and SIMD operations. They are parallel derivatives, not sequential revisions of Pascal.

• Direct historical chain: BCPL → B → C.
• C extensions and descendants: C++ adds major object-oriented and generic features; Cyclone retains much of C's syntax while adding safer pointer/region typing. D is heavily C/C++ influenced, but not a drop-in successor.
• Other C-syntax relatives: Java, C#, JavaScript, TypeScript, Go, Rust, Zig, Odin, and V share varying C-style syntax or systems-programming goals; they are not one linear genealogy.

• Lisp / Common Lisp: CLISP and SBCL implement Common Lisp.
• Scheme: MIT Scheme, Chez Scheme, CHICKEN, Gambit, Guile, Larceny, Vicare, Bigloo, and the Stalin compiler cover several Scheme implementations and compilation strategies. Racket originated as a Scheme implementation and later expanded into a language-creation platform.
• Other Lisp descendants: Clojure targets the JVM with persistent functional data structures. F# belongs principally to the ML/OCaml functional tradition rather than Scheme.

• BASIC family: BASIC, PureBasic, and Visual Basic reflect distinct dialects or descendants of BASIC, and should not be assumed source compatible.
• JVM languages: Java, Kotlin, Scala, Groovy, Gosu, and Ceylon share a runtime target, but have differing language origins. Jython is a Python implementation on that runtime.
• .NET / CLR: C#, Visual Basic, F#, Boo, Nemerle, the original Cobra, and Niecza demonstrate different language designs on a common managed platform.
• BEAM: Elixir builds on the Erlang virtual machine and ecosystem; unlike JVM/.NET languages above, its direct ancestor in runtime terms is Erlang (not represented by a standalone directory here).

• Python contains historical Python 2 and Python 3 programs. PyPy runs Python with a JIT; Jython targets the JVM; MicroPython targets constrained systems.
• Cython and Cython (array variant) compile a Python-derived language into extension code; Numba JIT-compiles selected Python functions. They are alternative implementations or acceleration strategies, not independent unrelated languages.

• REBOL lineage: REBOL influenced Boron and Red.
• Unix shells: Bash, KornShell, and Zsh are related Bourne-shell descendants; fish is a different shell design. PowerShell is object-pipeline oriented, not Bourne-shell compatible.
• Scientific / array languages: Fortran, MATLAB, Octave, Julia, R, IDL/GDL, Yorick, Maple, Mathematica, and SageMath form an application/ecosystem grouping, not a single historical ancestry. MATLAB and Octave are intentionally related; SageMath uses Python as its interface language.
• Concurrency / distributed / parallel experiments: Chapel, Regent, X10, ParaSail, Pony, AmbientTalk, and SuperPascal illustrate distinct approaches to parallelism, actors, locality, and type-enforced concurrency.

A language name is not a compiler version. Unless a README records a number, a build recipe usually establishes only a toolchain identity. Source extensions, language syntax, target runtimes, and flags can narrow the dialect, but cannot by themselves establish a precise compiler release. In particular, the links above are references to upstream documentation, not claims that their latest versions compile this code.

Some identifiable cases worth retaining in future per-directory READMEs:

Proposed per-language README convention (to implement gradually): language and dialect; compiler/interpreter and exact tested version (or unknown); canonical upstream source/docs; prerequisites; build and run commands; observed results; portability notes; and date/platform of last actual verification. Historical commands should be preserved without silently replacing them.

Most directories contain an outcomes.* driver and often a partitions.* helper, a short README.md, and an outcomes.txt transcript. Some tools emit C as an intermediate artifact; some scripts require a shared library, external runtime, or source files from a companion repository.

This repository expands the related octonion/puzzles/blackjack collection. recursion covers 150 implementation directories, compared with 136 under puzzles/blackjack. All 136 directory names occur here, but a few files exist only in the earlier tree (including a compiled SuperPascal artifact and an optimized SBCL variant). Review those differences before consolidating.

Do not assume every example still builds. Many READMEs preserve commands used at the time of development; there is currently no repository-wide CI matrix that verifies all 150 directories on modern toolchains.

For reproducible comparisons, record:

• Operating system and architecture, plus compiler/interpreter and version.
• Exact build and execution commands (including optimization flags).
• Whether the program completes and matches all ten reference counts and the total.
• Any patches needed for compatibility, and whether they change the algorithm.
• Timing methodology, if performance is being reported (including warmup, repetitions, and hardware).

A successful build is not necessarily a successful execution; and matching a total alone is weaker evidence than matching all ten counts. Historical outcomes.txt files serve as reference artifacts, not evidence that a current toolchain has been tested.

Contributions that recover older toolchains, document build dependencies, add missing language READMEs, repair portability problems, or expand regression tests are welcome. In particular:

1. Keep the original language implementation and historical notes intact where feasible; isolate modern compatibility changes.
2. Document the compiler/runtime version and a command that runs from the relevant language directory.
3. Report whether the output matches the ten reference counts above; distinguish untested code from a verified build.
4. Avoid calling measurements a cross-language benchmark unless algorithms, compilation settings, and measurement conditions are controlled.

A useful longer-term goal is an automated test matrix for readily available compilers, plus an optional, separately documented suite for historical and unsupported environments.

MIT. Copyright © 2018 Christopher D. Long.