I looked at the tinywm code and it's extremely informative.
A lot of times I'd like to quickly wrap my head around things like how an X Window Manager is written, for example, and one that implements the most minimal functionality possible is the ideal thing to look at.
There should be more of these projects, this is the greatest thing ever for understanding.
That is like saying that poetry is unreadable prose. There's pleasure in brevity. Also one can learn some neat tricks sometimes. And nobody demands you use clever one-liners in your production code.
I think your parent is stating an expectation of what can be found in that forum. Not a fundamental characterization of what 'tiny code' is necessarily like.
Aside: I've never understood poetry to be about brevity.
Also, although I've focused a lot on lazy functional programming languages lately (http://fexl.com), for my main scripting work I've been using simple token-based languages. Most of these languages are domain-specific (e.g to hedge fund accounting or certain web-rendering tasks), but I also have a Turing-equivalent token-based language which is concatenative in nature. I think my language is simpler than Forth because I use a global key-value storage context which supports ordered iteration, giving you the power of "hashes" and "lists" without actually having those as first-class data objects.
My point being that I'm becoming more enamored of the tinyvm approach, namely the use of "opcodes" with very simple operational semantics. And I also like the ability to embed these languages inside other programs written in any language (e.g. C, Perl, Lisp, Ruby, Java, whatever).
Tell ya what, I'll document some thoughts on the http://fexl.com web site. In the meantime, let me just say this. It's a language which you can "execute" manually on a whiteboard very easily. So I can demonstrate the language semantics fairly simply to a non-programmer. Anyone who can follow basic instructions can follow along.
The interpreter has two things: a single stack, and a global key-value space. Both the keys and values in that space are simple strings. You can store numeric values, and the interpreter will just "do the right thing" depending on how you use them, converting to and from machine numbers as it chooses.
Here's just a taste of some of the verbiage:
: x : 4 store
: y : 3 store
? x ? y add : z store
Now the ? is a shorthand for the more general "fetch", which allows arbitrary large levels of indirect reference. These two forms are equivalent:
? x
: x fetch
But single-indirection is so common that it's nice to have the shorthand. In the rare cases you need to do multiple indirection you can do crazy things like this:
: name fetch fetch fetch
By the way if you don't like "store" and "fetch" you can use "put" and "get" instead. The concepts are more important to me than the specific vocabulary.
The really fun part is defining conditionals and looping in the language, without using labels and gotos. Here are some snippets:
# What color is the fruit? (Yeah I know I'm doing
# repeated string comparisons here even after I've
# found the right color, but whatever, at least until
# I think of something better.)
: fruit : banana store
: color : "" store
( ? fruit : banana eq : color : yellow store )
( ? fruit : orange eq : color : orange store )
( ? fruit : strawberry eq : color : red store )
( ? fruit : cherry eq : color : red store )
( ? fruit : grape eq : color : purple store )
# First 100 Fibonacci numbers. Note that with appropriate
# use of the stack I can dispense with "z", but I leave
# it this way for "clarity", such as it is. :)
: count : 100 store
: x : 1 store
: y : 1 store
(
? count : 0 >
? x print nl
: z ? x ? y add store
: x ? y store
: y ? z store
: count dec
repeat
)
The conditional tests such as "eq" and ">" work by short-circuiting the surrounding block enclosed in "(" and ")" in the case that they are false. If they're true, execution proceeds sequentially. In effect, the conditionals are guards.
Also note that in the fruit example I don't actually have to set the color variable to the value. I could just leave the value on the stack instead and let the caller grab it. But I do it with the color variable as an illustration.
Now you may ask how to define a named routine. You language purists are probably gonna shudder at this, but here goes ... you just store the routine in the key-value space, where the value is a single text string containing all the instructions. So fibonacci is:
: fibonacci ~@
... all those instructions above right inside this string
@
store
Now to call or "do" that routine, you say this:
: fibonacci do
# Note that it automatically dereferences the routine
# name so you don't have to say "? fibonacci do".
You might think it slow to read the tokens off that string every time you call the routine, but I'm not worried about it too much. First, it's plenty fast enough for most scripting purposes. Second, if and when you really care, you can do all sorts optimized representations of these tokens streams in memory, perhaps in the extreme case even compiling down to assembly code.
There are also ways to iterate through keys in forward or backward order, and ways to expand templates for producing web forms, simple ways to save and restore values inside routines, etc. etc.
Here's a little more on ordered iteration, which allows you to sort very efficiently. Some examples:
: x next
# top of stack now contains the next key in the space
# which is strictly greater than "x" (or null if no
# such thing)
: x prev
# same thing, except less than instead of greater.
The ordered iteration concept completely eliminates the need for first-class "lists" and "hashes" and such. If you want to sort a bunch of names, just jam them all into a little sub-space, prefixed with "names/" perhaps to keep them separate from other global variables, and then simply iterate over them using "next" until you reach a key that does not start with "names/". I have a verb called "follow" which matches a given prefix and gives you the stuff following that prefix, or null if it doesn't match.
Note that you cannot just jam tokens together like this:
(:x :1 store)
Instead you must keep all the tokens separated with at least one white space:
( : x : 1 store )
That makes the token reader drop-dead simple. The reader doesn't need to know anything about what any tokens "mean", and it doesn't need any rules about "special" characters such as "(" and ")". Also, any indentation or line breaks you happen to use or not use are utterly irrelevant.
In a way I'm almost agnostic on the details, since you can embed whatever verbiage and semantics you like into your surrounding interpreter, which is written in C, Perl, Ruby, Lisp, or whatever. If you want to use Swedish verbs instead of English, have fun! It's more of a technique than a specific formal specification.
The essential concepts are:
1. The use of simple space-separated tokens.
2. The use of a single stack of string values.
3. The use of a global key-value map with string keys and string values.
This basically emulates the traditional execution model of a computer, with a stack and memory area, except that instead of the values and addresses being machine words, they are strings instead.
Perhaps I should call this language "Yet Another Forth" or even "Assembler for Dummies" :)
I think it's more clear than Forth because you don't have to do major gyrations to handle complex data. In effect, the "structure" of your data is modeled in the naming scheme of your keys, and the ability to iterate over the keys gives you the ability to "walk" that structure fairly easily.
At risk of being overly meta, the top thing on it now (by more than an order of magnitude) is "So how many of you heard about this subreddit from Y Combinator?"
and programming language subreddits: http://redditlist.com/dir/1785
You can add any missing subreddits
</shamelessplug>