{"id":4323,"date":"2026-03-06T19:07:43","date_gmt":"2026-03-06T16:07:43","guid":{"rendered":"https:\/\/demensdeum.com\/blog\/2026\/03\/06\/interpreter-in-practice\/"},"modified":"2026-03-06T19:41:37","modified_gmt":"2026-03-06T16:41:37","slug":"interpreter-in-practice","status":"publish","type":"post","link":"https:\/\/demensdeum.com\/blog\/2026\/03\/06\/interpreter-in-practice\/","title":{"rendered":"Pattern Interpreter in practice"},"content":{"rendered":"

In last article<\/a> we looked at the theory of the Interpreter pattern, learned what an AST tree is and how to abstract terminal and non-terminal expressions. This time, let’s step away from the theory and see how this pattern is applied in serious commercial projects that we all use every day!<\/p>\n

Spoiler: You may be using the Interpreter pattern right now, just by reading this text in your browser!<\/b><\/p>\n

One of the most striking and, perhaps, the most important examples of the use of this pattern in the industry is JavaScript<\/b>. The language, which was originally created \u201con the knee,\u201d today works on billions of devices precisely thanks to the concept of interpretation.<\/p>\n

10 days that changed the Internet<\/h2>\n

The history of JavaScript is full of legends. In 1995, Brendan Eich, while working at Netscape Communications, was given the task of creating a simple scripting language that could run directly in a browser (Netscape Navigator) to make web pages interactive. Management wanted something with a syntax similar to the then super popular Java, but intended not for professional engineers, but for web designers.<\/p>\n

Eich had only 10 days<\/b> to write the first prototype of the language, which was then called Mocha (then LiveScript, and only then JavaScript for marketing reasons). The rush was not accidental: Microsoft was hot on its heels, which at the same time was actively preparing its own scripting language VBScript<\/b> for embedding in the Internet Explorer browser. Netscape urgently needed to release its response so as not to lose in the looming browser war.<\/p>\n

There was simply no time to write a complex compiler into machine code. The obvious and fastest solution for Eich was the architecture of the classic Interpreter<\/b>.<\/p>\n

The first interpreter (SpiderMonkey) worked like this:<\/p>\n

    \n
  1. It read the text source code of the script from the page.<\/li>\n
  2. The lexical analyzer broke the text into tokens.<\/li>\n
  3. The parser built an Abstract Syntax Tree (AST)<\/b>. In terms of the Interpreter pattern, this tree consisted of terminal expressions<\/i> (strings, numbers like 42) and non-terminal<\/i> (function calls, statements like If, \u200b\u200bWhile).<\/li>\n
  4. Then the virtual machine \u201ctraversed\u201d this tree step by step, executing the instructions embedded in it at each node (calling a method similar to Interpret()).<\/li>\n<\/ol>\n

    Context and Objects<\/h2>\n

    Remember the Context object that we had to pass to the Interpret(Context context) method in the classic implementation? The interpreter needs it to store the current memory state.<\/p>\n

    In the case of JavaScript, the role of this context at the top level is played by a Global object<\/b> (for example, window in a browser). When your AST node tries to, say, write text to the screen via document.write(“Hello”), the interpreter accesses its context (the document object) and calls the desired internal browser API.<\/p>\n

    It is thanks to the interpreter that JavaScript is able to interact so easily with the DOM (Document Object Model) – these are all just objects in a context that are accessed by tree nodes.<\/p>\n

    Evolution of the interpreter: JIT Compilation<\/h2>\n

    Historically, JS in browsers has long remained a \u201cpure\u201d interpreter. And this had a big disadvantage – slow speed. Parsing the tree and slowly traversing each node each time the script was executed slowed down complex web applications.<\/p>\n

    With the advent of Google’s V8<\/b> engine (built into Chrome) in 2008, a revolution occurred. Engineers realized that one interpreter is not enough for the modern web. The engine has become more complex: it still builds the AST tree, but now uses JIT (Just-In-Time) compilation<\/b>.<\/p>\n

    Modern JS engines (V8, SpiderMonkey) work like a complex pipeline:<\/p>\n

      \n
    1. The fast and dumb base interpreter starts executing your JS code instantly, without even waiting for it to compile (the classic pattern still works here).<\/li>\n
    2. In parallel, the engine monitors \u201chot\u201d sections of code (loops or functions that are called thousands of times).<\/li>\n
    3. These sections are compiled by the JIT compiler directly into optimized machine code, bypassing the slow interpreter.<\/li>\n<\/ol>\n

      It was this combination of the instant start of the interpreter and the computing power of compilation that allowed JavaScript to take over the world, becoming the language of servers (Node.js) and mobile applications (React Native).<\/p>\n

      Interpreter in the gaming industry<\/h2>\n

      Despite the dominance of C++ in heavy computing, the Interpreter pattern is an industry standard in game development for creating game logic. For what? So that game designers can make games without the risk of \u201cdropping\u201d the engine or the need to constantly recompile it.<\/p>\n

      An excellent historical example is UnrealScript<\/b> – the language in which the logic of the Unreal Tournament and Gears of War games was written in Unreal Engine 1, 2 and 3. The text was compiled into compact abstract machine bytecode, which was then step by step (interpreted) by the engine’s virtual machine.<\/p>\n

      Visual graph scripts (Blueprints)<\/h3>\n

      Today, text has been replaced by visual programming – the Blueprints<\/b> system in Unreal Engine 4 and 5.<\/p>\n

      If you’ve ever opened a Blueprint in Unreal Engine, you’ve seen a lot of Nodes connected by wires. Architecturally, the entire Blueprints graph is a huge Abstract Syntax Tree (AST)<\/b> drawn on the screen:<\/p>\n

        \n
      1. Terminal Expressions:<\/b> Constant nodes. For example, a node that simply stores the number 42 or a string. They return a specific value when interpreted.<\/li>\n
      2. Non-Terminal Expressions:<\/b> Compute nodes (Add) or flow control nodes (Branch). They have argument inputs, which the interpreter first evaluates recursively before producing the result as an output pin.<\/li>\n<\/ol>\n

        And the role of context here is played by the memory of an instance of a specific game object (Actor). The Interpreter Machine safely \u201cwalks\u201d through this graph, requesting data and performing transitions.<\/p>\n

        Where else is the Interpreter used?<\/h2>\n

        The interpreter pattern can be found in almost any complex system where dynamic instructions need to be executed. Here are just a few examples from commercial software:<\/p>\n