This year my (generous) employer sent me to Autodesk University, where I loaded up on design computation and BIM classes for four straight days. The first day was entirely taken up by a technology preview of DesignScript, where Robert Aish and others from Autodesk and Buro Happold presented the underpinning logic, some practical examples and attempted to help us get a handle on the syntax and functions. Below is a (thankfully edited) digest of my notes from the class. Note: much of what is listed below is guesses and conjecture. I am sorry if I am wrong, feel free to correct me in the comments.

– One of the first noticable features of DS is the ability to switch at will between “Imperative” and “Associative” programming modes, which is a fairly unique feature that reminds me of the setup() and draw() portions of a processing script. Indeed the basis of the language appears to be maximum flexibility, borrowing some language features from python, and allowing functions to call “collections” of objects (essentially arraylists) as well as single objects.

– The little IDE is fairly sparse but appears to have most of the important functionality implemented. Reminds me of Processing, in a very good way. One beef – error handling is currently very opaque and rudimentary; more everyday English and specificity would go a long way for those of us that don’t program for a living :).

– It took all of thirty minutes for someone to bring up Grasshopper and another thirty for GC to be invoked. Robert Aish was very gracious about this (one of my main lessons of the day is that Mr. Aish is a fantastic, patient, enthusiastic human being). He was, howerver, a bit dismissive of Grasshopper, exhibiting a programmer’s bias against non-textual methods of programming.

– DS is still very much in early development; there were many “known issues” including the fact that it’s not currently very fast. I hit another one almost immediately; the object color methods don’t play properly with Associative mode.

– Likewise, the geometry engine is surprisingly bare bones; they just revealed that they just added surface curvature functions to help a pre-alpha tester do some test scripts! I really hope that going forward they spend as much time on geometric functions as they have on pure syntax.

– When questioned on the details of a future graphical interface, they revealed that the graphical and textual representations will work in parallel; that is, you will be able to switch between them with a 1:1 correspondence, and both will represent the same compiled or interpreted result. Sounds complicated, but if it works out this would be a pretty awesome feature.

– DS still has a “run” button. Removing it appears to be on the “to do” list, which I suppose would make DS an interpreted language? Actually given what I have said above it sounds more like David Rutten’s description of Grasshopper; the script being a visual interface to get precompiled .dll’s to talk to one another. We will have to see how this shakes out.

– DS currently spits out “dumb” AutoCAD geometry with no link back to the script – there appears to currently be no method to “load” drafted geometry into the script. Obviously this is a big need on the wishlist.

– Aish et al have stated a desire to avoid the need to “bake” geometry into the host program. Not sure why this is something to avoid. As there doesn’t appear at the moment to be a way to keep rig geometry from being expressed at runtime the current state is essentially everything being “baked.” It would be interesting if there were simple ways to group geometry into groups to change their expression appropriately.

– The three statements immediately above this one all point to the same thing – currently, immediate feedback is not a feature of DS. I know that is coming soon, it will be interesting to see what it can do when the interface has more interactivity.

– The plugins already implemented (Robot, SmartForm formfinding by Buro Happold, Ecotect etc) show one major advantage of DS over similar interfaces- it appears to be very easy to extend with currently written libraries of code. This could be the feature that makes this language take off, particularly if Autodesk keeps adding analysis functions based on their current software. Once again, reminds me of Processing in a very positive way.

That’s what I have. I agree with a lot of what Daniel Davis said almost a year and a half ago, notably that my biggest fear is that slow development and a slower release schedule is keeping Aish and Autodesk from “failing faster” and will prevent this tool from being as powerful and popular as it deserves to be. It’s worrisome how much is still on the wishlist after multiple years of development. That being said, if this becomes the underlying architecture for all scripting in Autodesk products that would be fantastic – the language is clear, useful, powerful, and rewards guessing – I’m not lying when I say it kept reminding me of python and Processing. So, if some Autodesk Senior VP of something or other is reading this blog (ha!) – listen, give this team some more people and more money, light a fire and let’s get this thing out of the labs and into your software!