> Introduction to Commands and Functions in HyperCard
HyperCard, introduced by Apple in 1987, came with its own scripting language called HyperTalk. One of HyperTalk’s most human-centered innovations was its clear distinction between commands and functions.
# The Original Purpose The idea was simple and revolutionary: - **Commands** were actions that made something happen, like “go to the next card” or “play a sound.” - **Functions** were queries that returned information without causing side effects, like “what is the name of this card?” This distinction made the language far more approachable to non-programmers. It was designed so that ordinary users who were new to computer languages could easily understand what a piece of code was meant to do. Commands “did things,” while functions “asked questions.”
# A Human-Centered Approach This human-centered design was a hallmark of HyperCard. It allowed people to build interactive “stacks” of cards and prototype applications without needing a background in traditional programming. The distinction between commands and functions made the code more readable and intuitive, reinforcing the idea that you were giving the computer instructions in a way that felt almost like natural language.
# The Evolution into LiveCode and Future DSLs This philosophy carried forward into LiveCode, the modern descendant of HyperTalk. LiveCode retained this approachable, English-like structure, allowing a new generation of users to create software with a similarly gentle learning curve. As we design the future DSL for the Hitchhiker Constitution or related projects, we draw inspiration from this legacy. The goal is to keep the language understandable and clear, so that users can distinguish between instructions that change the state of the system (commands) and those that simply report on it (functions or queries).
# What Was Lost in Mainstream Languages and the Rediscovery Over time, many mainstream programming languages, in their pursuit of power and generality, blurred this distinction. Commands and functions became unified under the broader concept of “functions” or “methods,” often making it less obvious whether a piece of code would just return a value or actually alter the system’s state. It wasn’t until patterns like Event Sourcing and CQRS resurfaced that the industry began to appreciate the value of making this distinction explicit again. By clearly separating commands (performative actions) from queries (descriptive functions), developers could once again see at a glance what a piece of code was intended to do.
# See