[mamcx]

So, I read about the fast interpreter and small language. How do something like this?

"Whitney’s strategy was to implement a core of the language – including the bits everyone thought most difficult, the operators and nested arrays – and use that to implement the rest of the language. The core was to be written in self-expanding C. As far as I know, the kdb+ interpreter is built the same way.

Unlike the tall skinny C programs in the textbooks, the code for this interpreter spills sideways across the page. It certainly doesn’t look like C."

This mean that the code is very unreadable C? Like a kind of code-golf?

How replicate it for built a speedy interpreter? And what if I use lua or python instead?

[JulianMorrison]

There are two opposite schools of readable C.

The mainstream says: readable C has function and variable and type names that express meaning, so a function is read like a narrative with verbs, adjectives and nouns. The fact that this narrative scrolls over pages, is unimportant.

The APL/K/J school says: readable C has functions, variables, and types named with single letters, so that the totality of a function is short enough to fit in one glance - preferably, on one line that does not need a scrollbar. The function does exactly what it says, no more and no less; its intent is thus completely clear. To name it descriptively would ruin the ability to grasp the whole thing as a gestalt.

[mamcx]

Ok, so APL/K/J is for people that read compressed code..

But that how relate to how build a fast interpreter? Faster than C?