Since mentioning my earlier involvement with DesignScript, I’ve been meaning to follow up with a quick post on why this programming language is different to the others people are currently using with AutoCAD.
Hence the title of the post, which stands for “Yet Another Scripting Language?”, inspired by two acronyms, Yacc and YAG (this is a subject-line often used by long-time Autodeskers leaving the company and stands for “Yet Another Gone”… I’m not sure if this term is used in the outside world – a quick Google would indicate not, but then you never know).
Anyway, back to the question: why did Autodesk choose to reinvent the wheel by creating another programming language? This question was clearly asked a lot when we first started developing it, but the ultimate answer is that it’s unlike anything we have today – in AutoCAD or even elsewhere, I suspect.
The primary reason it’s so different is its associative nature.
[Now I’m pretty sure what I’m writing here has been covered in a number of other places, but I tend to feel it’s better to be safe than sorry. And I just felt like writing something about DesignScript today.]
Let’s take a look at what the term “associativity” means, in this context. Take the following pseudo-code:
a = 0
b = a + 1
a = 2
In a traditional programming language, the value of b at the end of this code’s execution would be 1. The difference with DesignScript is that the associations you create in your code are remembered by the DesignScript runtime, so that when changes are made to variables others depend on, a ripple of changes makes its way through the network, updating any dependent variables. So the above code – when run from DesignScript – would result in b having a value of 3.
In itself this may not seem like a dramatic departure from what we have today, but as you flesh out a model – as described by DesignScript, specifying dependencies in your code to map relationships between geometry – you end up with something that makes it really easy to play around with variables, tweaking the design to meet your particular requirements (whether they be aesthetic or functional). This is one reason this technology is likely to see adoption in domains where people want to explore design variations.
The vision behind DesignScript is very broad: you can already integrate data coming from analysis and simulation tools (Ecotect is one such example) and the interfaces are there for developers outside the company also to integrate their own systems.
So DesignScript is intended as a way to map relationships such as constraints using code. How does it relate to existing parametric systems? It’s philosophically different, in many ways: rather than building a model with the constraints built in – as meta-data on existing geometry or data in its own right – you’re creating them via code. This approach has similarities to a project I came across a few years ago, where a company called Resolver Systems used Python scripting to create a spreadsheet that is essentially generated by executing code. Incidentally, I first heard about this product, Resolver One, on Channel 9. It’s very interesting the conceptual similarities between it and DesignScript: both attempt to unravel inherent model complexity in a way that people can understand and manipulate as code.
One last comment about DesignScript… you might also ask “why didn’t you just add some extensions to an existing AutoCAD-capable scripting language, to facilitate moving code across to it?” That possibility was certainly considered but eventually discarded: while DesignScript is ultimately a programming language – from what I recall it has a number of similarities to Scala, although there may have been other, more recent influences – one of the primary design goals was for it to be fairly easy for non-programmers to pick up. And it doesn’t make sense to port or migrate your code from (say) AutoLISP or VBA to DesignScript: the philosophical differences are such that you couldn’t (or wouldn’t) just move code across from one environment to the other.
A final note… many of these comments and observations are based on my somewhat stale knowledge of what’s been happening with DesignScript, so please don’t assume what I’ve said here is 100% accurate. Hopefully Luke Church (who has been largely responsible for the language’s design, over the last few years) will step with with comments if he sees anything glaringly incorrect.
Photo credit: See-ming Lee 李思明 SML via photopin cc
