Get the latest tech news

Exploring biphasic programming: a new approach in language design

I’ve noticed a small but interesting trend in the programming languages space. I’m not sure how novel it is, but this pattern, which I’ll refer to as “biphasic programming,” is characterized by languages and frameworks that enable identical syntax to express computations executed in two distinct phases or environments while maintaining consistent behavior (i.e., semantics) across phases. These phases typically differ temporally (when they run), spatially (where they run), or both.1 One can say that metaprogramming systems are related to biphasic programming. For example, C pre-processing can be thought of as biphasic programming in spirit since it allows you to run code in the pre-processor, a phase of compilation before runtime. But it doesn’t satisfy the definition I’ve provided since the preprocessor only does textual substitutions, and C’s preprocessor macros are limited – #ifdef is quite different from a bona fide if statement. Lisp-style hygenic macros like those in Scheme and Racket, on the other hand, are expressed through functions that support the same expressiveness as the base language(s), so I think it would be fair to say Lisps provide some of the oldest examples of biphasic programming. ↩

It shifts the developer’s mental model from thinking of metaprogramming as advanced wizardry to being more of an optimization tool that can also be leveraged to implement generics and other code generation uses. I haven’t had a chance to write many Zig programs yet but the comptime system seems like a clever approach to reduce both compiler complexity and soften the language’s learning curve. Lately, the front-end JavaScript ecosystem has been doing a lot of exploration to figure out how to most efficiently render UI components on either the server or client to improve page performance.

Get the Android app