Dissecting Grasshopper

Daniel Davis – 31 August 2010

Afew months ago, Ben Sitler created a guide for making Grasshopper components where, tucked in the bottom, are instructions for viewing the Grasshopper source code. Download the .Net Reflector from RedGate, point it towards the Grasshopper dll, and there it all is. Dissecting Grasshopper like this is against section 3.2.1 of the Grasshopper terms of service, however just looking at the code is unlikely to draw attention, copying the code on the other-hand is both unethical and illegal.


It is fascinating to see the inner workings of production software. I was expecting it to be overflowing with elaborate geometric algorithms, graph theory and optimisations. These are definitely there but for the most part the code is user interface. This probably should not be surprising, the interface to Grasshopper is fairly sophisticated with many different buttons and controls, while the geometry is largely handled by Rhino. The dominance of interface in code seems to be true for many other projects, I used to sell small software plugins and was always amazed by how much time I would spend not writing plugins and instead packaging software, writing instructions and providing support. Adobe seems to face a similar phenomena, about 25 minutes into this talk about Photoshop at Google, the Adobe engineer mentions that the interface of Photoshop accounts for about 1/3 of the code base, surprising when you consider how simple the interface is relative to how complex the tools are. I think as a user the output of the software gets all the attention, however under the hood of production software are elaborate algorithms, not to generate the right output, but to help the user generate the right output.

Lately I have been very focused on the output of CAD software, and whether software engineering can teach us how to make better parametric models. I wonder if I have this the wrong way around, perhaps you need to start with the interface.

3 August 2010: Removed the sentence that stated: “David Rutten, the developer of Grasshopper, has mentioned that decompiling code like this is often against the terms of service, but I can not deduce if it is against the Grasshopper terms of service – I think as long as you are just looking and not taking anything, it should be fine.” And replaced it with a sentence referring to the Grasshopper terms of service, thanks to David Rutten for clarifying this in the comment below.



Join the mailing list to receive an email whenever a new post comes out. Otherwise, you can follow me on Twitter, or add the RSS feed to your reader.


  • Mentioned 1 September 2010 at 8:35 am

    […] This post was mentioned on Twitter by Rodrigo Medina, Andrea Graziano. Andrea Graziano said: Digital Morphogenesis – "Dissecting Grasshopper" #gh3d http://snipurl.com/1117fr […]

  • David Rutten 2 September 2010 at 11:22 pm

    It actually is against the terms of service as explicitly stated in the license agreement under section 3.2.1:

    “Reverse Engineering. You may not (and may not permit any third party to) reverse engineer, decompile, or disassemble Grasshopper.”

    This clause is obviously added to provide some protection against immediate Grasshopper clones and RMA will in all likelyhood not pursue anyone sneaking a peek at the source. But I think it is important that you know it is a violation of the license agreement to both disassemble the library and encourage others to do so.

    That being said, I do myself often hint at the use of Reflector and I think it is a magnificent way to have specific questions answered.

  • David Rutten 2 September 2010 at 11:35 pm

    On a more constructive note, I’m often myself surprised at how much code it takes to write a halfway decent interface. I don’t know if this is a temporary state of affairs that stems from the immediate history of programming or if it’s simply much harder to write succinct UI code.

    A simple QuadTree can be written in 100 loc, I need multiple klocs just to handle a mousemove event…

  • Daniel 3 September 2010 at 5:20 pm

    Hi David,

    Sorry. I had searched for the Grasshopper TOS when I wrote the post, but could not find them – I assume they come up when you install Grasshopper. I have amended the post with reference to the terms of service.

    I think interfaces will always be fairly verbose parts of programming, primarily because they describe the logic for a wide range of events. One thing that is sort of happening with SDK’s, like the Grasshopper SDK, is that the interface has been abstracted to the point where plugin developers only really need to manipulate data. There is also the reverse of that trend with things like the Twitter API, where the data is supplied but the interface is still up for grabs.

Leave a comment