Lots of folks start their programming adventure with some kind of scripting. How do we define a scripting language? Wikipedia says, it is a language used to write instructions that are:

• short
• simple
• usu. interpreted rather than compiled
• might be domain-specific
• (very) high-level
• limited capability
• reads top-to-bottom (rather than from an entry point)
• might automate an otherwise manual process

Tcl and Lua, it says, are designed to be embeddable in any application for scripting purposes. The main appeal of a general-purpose scripting language is you can avoid reinventing any wheels: it saves you from having to write an interpreter/translator from scratch.

Scripting languages are important in games, where developers want simple, flexible ways to configure character behavior, modify the game world, write dialog and such without having to write and compile headache-y low-level code. Watching people gear up for the Spring 2024 Lisp Game Jam, I learned about Fennel, which compiles to Lua (works with TIC-80) and Guile Scheme, used in David Thompson's Chickadee game toolkit, and other amazing-seeming things like the Hoot WebAssembly toolkit (which lets you run Scheme code in the browser)¹. Chickadee also supports Wisp, an alternate lisp syntax (basically, hides the parentheses). I also came across lips, a scheme interpreter for the browser written in JavaScript, an approach which by association seems slightly cursed but also potentially fun and very useful. A final Lisp option is to write your own simple interpreter, which may be ill-advised (as noted above) but at least easier for a Lisp-y language than anything else. Peter Norvig shows (how (in Python)) and there are lots of other examples around the internet.

In commercial and open-source CAD software, you can find examples of most of these approaches, and some good examples of more opinionated domain-specific languages. I'll leave visual programming alone for now (let's revisit that in a week or two). In this context it's important to consider that automation ("automate an otherwise manual process") is a really important use-case for CAD scripting, either to generate documentation drawings more quickly, to set up flexible ("parametric") models to test/tune design options, or some combination. So some of these lean toward broader, fuller feature sets and less domain specificity in order to facilitate a wider range of activities besides just modeling and rendering. A good example is the AutoLISP-based process used for SOM's concept design for the Lotte Tower in Seoul. These kinds of scripts are used within a context of diverse (human) working methods that are either more linear (like with fabrication, generating shop drawings) or involve slower, translation-heavy feedback loops involving multiple people and tools. So visualization is very important, but also interoperability between different file formats and data types. That said, here's a map of the landscape:

• Rhino can be scripted in Python, C# or VBScript
• AutoCAD has a range of options including its own Lisp dialect: AutoLISP
• SketchUp uses Ruby
• CityEngine uses a domain-specific language called CGA Shape Grammar Language
• OpenSCAD uses an eponymous domain-specific language
• OpenCASCADE, while not itself a CAD software in the same sense, comes with Tcl tooling for development use

What (I think) I'm working on at Recurse Center is a scripting environment for generative 3d modeling with fast feedback, borrowing from live coding techniques seen in game development and music. On the music side, TidalCycles is my favorite example of this. I'm hoping to do a deep dive on how that system actually works in another post, but as I currently understand it, "Tidal" is a domain-specific language expressing musical pattern, built on top of Haskell. Generated instructions are performed (rendered?) by SuperCollider, an audio synthesis program.

Since we're at mid-week already, I want to make some tenative decisions, and see how they roll. My instinct is to try Tcl, assuming it can be reasonably "live". Reasons, it looks pretty concise (that is, easy to type), it has object-oriented programming support, and, there should be source code in OpenCASCADE to consult/borrow from.