> One thing you quickly run into with this exercise is needing to establish the boundaries around "programming language" which can be kind of fraught. Well I w

> One thing you quickly run into with this exercise is needing to establish the boundaries around "programming language" which can be kind of fraught. Well I was referring to what one could call a souped-up macro assembler: direct access to a machine's hardware, but with some (but important!) conveniences of higher-level languages. Eg. many Forth systems provide a read-eval-print loop (REPL), allowing users to re-define Forth words on the fly, poke some memory mapped IO, etc. But still do so in a relatively comfortable manner using Forth words rather than (only) through editing assembly code. The mapping (the "language", if you will) between Forth words, and assembly code that implements them, is fairly straightforward 1:1. And thus, allows for small implementations. Like, fit comfortably in a 16-bit address space. Many esoteric languages do not fit this description, since they often discard the convenience factor. C is on the fence here. It's got many of these aspects, but small-ish? Hmm.. And stripped down to a subset, is it still C?