RTV Tools

Wednesday, January 15, 2014

Is Dynamo the new API?

I don't think the API programmers should get scared just yet, but is there a day coming when visual programming will completely replace custom code?  Julien seems to think so:

"I firmly believe Dynamo could be used for many many purposes, and addin-like behavior is one...
Definitions are easy to share and update. Users can tune them with only some basic Dynamo skill. It is not the same with addins. It is a lot of work to manage and deploy. And users will not be able to tune things. Same thing for macros."

Read more:
API or not API: addins vs Dynamo in Revit | AEC, you and me.

Heads-up: https://twitter.com/Jbenoit44/status/414322858823659520


  1. The answer is no, if such a scenario was the case then Visual Programming would have replaced regular programming for general stuff years ago. Visual programming is great at simplistic flows, but just like Grasshopper extremely complex files (which are still extremely simplistic compared to many modest API addons) can only really be used by the people who created them without documentation or training or spending an inordinate amount of time understanding whats going on. These programs lack any real ability to organise information correctly or track flow.

    They are great for the basics, but for a Macro I can write a Macro that does exactly what I want in a fraction of the time and with more freedom then what Dynamo offers now. The speed is something we can change, specific nodes can replace complex code but it cannot replcae the freedom as soon you touch on a niche that Dynamo can't handle then your either Coding new Nodes for Dynamo in VS, writing a Macro or building an Add-on.

    Here is a perfect example, in Dynamo I can write a beam creating node that gets line items from a families and builds structural elements around it in 2 mins. However lets say I wanted to add columns to that, as there is no node for it, a vast amount of time is spent either using existing nodes and getting values or writing a new one(back to Visual Studio). Writing new nodes for Dynamo is harder too, because a programmer has to know dotnet, F#, the Revit API and the Dynamo API in order to create a single node.

    I used a program called Quest3D for a while, which is probably one of the best examples of visual programming out there. Quest3D is a real-time programming game engine (so you can code and it updates the views automatically) so you would have nodes for Camera's, models, UI, animations the works, both Grasshopper and Dynamo could benefit alot from the UI features and functions for organisation, but even there you still have to write code for complex elements like shaders very custom animation types and so on, and the more complicated the harder for the standard user to customise. UI's are there for a reason to hide all the crap :)

    Visual programming is great, but way to high level for every purpose out there, and when we are customising it's generally because we are doing something very specific.

    1. Thanks for the detailed response mate, you hit on some excellent points. In some ways, I think the answer is "which one are you best at". One user feels comfortable coding, one feels more comfortable in visual programming, one can solve the problem using Revit / parameters / families. I guess coding remains the most "powerful" at least in terms of ultimate capability. Even Revit is code.

  2. Exactly like anything it's which are you best vs learning the best tools for the job. Parts of dynamo are brilliant at doing some very specific things, our best example is our Framing creator is built on Dynamo and allows us to bring in 3D line based families, CAD files and 3D models and quickly select the object and build our framing up completely connected based on our analysis outputs into Revit or simply complex trusses engineers have design in 3rd party programs.

    On the other hand our template generator could not have been done in Dynamo without a huge time investment due to lack of UI nodes, copy notes, open file in background all those sorts of things.

    I recommend learning bits of everything and applying the best bits of what a tool/language was designed for to solve the issue at hand.

    All programs and languages start of doing one thing really well, then they try to start to do everything else this usually is where the weak spots appear and requires mastery, knowing the easy stuff each tool does allows you to make better choices I think.

  3. Adam, you are write. as a coder guy. But your answer matches for around 0.5% of revit users in my company. That's my point.
    Visual programming is less powerful, it is not really coding in fact. but it as a huge potential for at least 50% of us here.
    We have a bunch of addins we use every day, addins that we're made by professional consultants. Best ROI so far. But as in the CAD days, when we needed every day some small LISP or like to automate tasks, Dynamo could help.
    Some will use definition, some will transform them. some will create them. Like internal open source program.We won't do this with code.
    My idea is to provide at the company scale definitions as starting kits to do iterative/automatic stuff. Provide some tutorials, that's all. No code training. It is also because every Revit user that is able to build advanced families is able to learn Dynamo, and get use to it, and like it a lot. Not true with code.
    Code is the King, yes. But Kings need servant, Dynamo to serve you ;-).


  4. Couldn't agree more :) we are attempting the same thing with (kits), quick manipulation and parameter feedback. We've actually had to build a lot of metric nodes as a lot of what's existing is all in Imperial, which our US projects only take up maybe 5% of time and much less in Revit.

    I don't see code and API's disappearing, though if you haven't seen this JavaScript example below, it's another great example of Visual Programming tools up & coming.

  5. Just saw this post, Dynamo can replace a lot of what a Revit 'add-in' can do but not everything (I guess it's possible in the future with enough development). You can also create Applications in Revit that run when Revit launches; this may or not be in Dynamo's future. One more aspect is the events in the API you can hook into (file open, view open, synch, ect).