The Lisp Advantage: Lessons from the Early Days of Viaweb
In a talk given at BBN Labs in April 2001, Paul Graham detailed the technical foundations of Viaweb, the precursor to Shopify. At the time, the industry was dominated by C and C++, but Graham chose Lisp. This decision wasn't just about personal preference; it was a strategic technical choice that allowed a small team to outpace larger competitors through superior development velocity and architectural flexibility.
The Freedom of the Server
One of the primary drivers for using Lisp was the shift from desktop to web-based applications. In the desktop era, developers were largely tethered to the language of the operating system. However, with server-side software, the developer controls the environment.
Graham argues that this freedom is a competitive necessity. In a market where speed of iteration is everything, sticking to the industry standard (like C++) simply because it is the standard can be a liability. A small startup using a more expressive, powerful language can "eat the lunch" of a larger company by shipping features faster and with fewer bugs.
The Power of Incremental Development
Lisp enables a specific philosophy of software creation: incremental development. Rather than spending weeks on a comprehensive design document and then implementing it, Lisp programmers often start with a program that does almost nothing and gradually add features while keeping the code runnable at every step.
Graham describes the growth of the Viaweb editor as a prime example: it grew from a 120-line example program into a 25,000-line system without a single full rewrite. This approach aligns perfectly with the "rolling release" nature of the web, where software is updated continuously rather than shipped in a boxed product.
Rapid Debugging and the Interactive Toplevel
The interactive toplevel (REPL) provided a massive advantage in bug resolution. Because the users' data lived on the company's servers, Graham could reproduce bugs in real-time by loading the code into the interpreter and logging into the user's account.
This led to a remarkably fast turnaround: bugs could be fixed and deployed while the user was still on the phone with customer support. As Graham notes, this was often handled with a bit of "sneaky" charm, where support would tell the user to simply refresh their page, and the bug would be gone.
Architectural Wins: Macros and Rtml
Lisp's macro system allowed Viaweb to build a Domain Specific Language (DSL) called Rtml. This embedded language served several critical purposes:
- HTML Generation: Since HTML is recursive and uses prefix notation, it mapped naturally to Lisp macros, making complex page generation manageable.
- The "Upgrade Path": Rtml allowed sophisticated users to write their own templates. While most users stuck to defaults, Rtml served as an "escape valve" for power users and a signal to the developers about which features needed to be added to the standard templates.
- Layered Abstraction: By separating the page-generation logic (Rtml) from the lower-level system code, the team could make high-level changes to the UI without risking the stability of the core engine.
The Lesson of Keyword Parameters
Graham highlights a specific technical detail that saved them significant effort: the heavy use of keyword parameters. By designing Rtml operators to take keyword parameters, they could add new functionality to an operator without breaking existing templates. This provided a level of forward compatibility that is rare in more rigid languages.
Simulating State with Closures
One of the hardest problems in early web development was the statelessness of HTTP. Viaweb solved this by using lexical closures to simulate subroutine-like behavior.
Instead of thinking in terms of "which CGI script should I call next," the software thought in terms of "which piece of code should I run next." By storing closures in a global hash table and associating them with unique IDs in URLs, the system could maintain context across requests.
This allowed for sophisticated UI flows—such as a color picker that would "return" the user to the exact state of the object editor they were in previously—making the application feel far more advanced than the static form-based competitors of the era.
Modern Perspectives
While the original talk dates back to 2001, the principles of Lisp-driven development remain relevant. Modern developers continue to find value in the interactive nature of Lisp and its ability to create powerful DSLs. As noted in community discussions, tools like HTMX and Datastar are finding a natural fit with Lisp today, proving that the combination of a dynamic, interactive language and a flexible frontend can still produce highly efficient development cycles.
As one contributor noted, a small group of programmers with the right tools can often outperform massive teams regardless of the resources thrown at them, provided they leverage the architectural power of languages like Lisp or Scheme.