C#/VB : Complexity of Code vs. Complexity of Wiring

Replies to This Discussion

Permalink Reply by Damien Alomar on August 25, 2009 at 7:08pm

I think this is a good question, yet ultimately one that you must answer for yourself. My take on things actually leans more towards relying on creating a network of components within GH and only adding the code where its needed. There are several reasons for this. First off, Grasshopper is really not a proper IDE (integrated development environment). GH really doesn't have the debugging, syntax highlighting, and the development flexibility that you can get through Visual Studio. Having worked with VS for a bit, I can tell that it is much easier and more efficient for me to write code there than in GH, and I know more about what's going on with it in VS than in GH.

Secondly, if all I'm going to do within GH is have 2 or 3 scripting nodes that do the heavy lifting, what's the point of me doing that within Grasshopper. If a project is going to be made up of that much code, then you might as well just do it all in code, compile it, and load it up as a plugin or a script. As I mentioned above, it would probably be more efficient to do it that way. Besides, although scripting nodes are great for specialized functionality that may never be native to GH, I'm not sure that the point of GH is to just become another scripting interface.

Lastly, I personally feel that there's a value in the network that winds up being created when you work in GH that is not only worth while to you, but to other people who may have to work with your logic. When its laid out graphically it has a certain kind of accessibility that doesn't seam to be the same when one looks at code (even if its your own). I'm not saying that one is better than the other, but I think that the actual enterprise of creating the network has a certain amount of importance.

In regards to my personal workflow, I generally take 2 (maybe 3) things into account when I determine whether something should be done through code or through GH. The first one is pretty simple...if something can't be done natively in GH, then it goes into code. That seams pretty self explanatory to me. Second is whether, for organizational purposes, a given operation would be better to do through code as opposed to through components. One of the most complex and visually cumbersome things to do in GH is reorganize data so that it reacts in the way that's needed. Sometimes I find this better to do in code rather than the dozen components it would take, so those are the times that this situation sticks its head out. The "maybe 3"rd thing is whether or not I can pass the data between scripting nodes. Unfortunately, for things like transforms that haven't been added, that data is "stuck" in a scripting node, so if I want to continue working with it it almost has to be within the same node*. I guess to some up, if it doesn't need to be coded, and it doesn't make things easier to code it, then I take care of it through standard GH components.

HTH
-Damien

* this isn't 100% the case as there are ways to share data between components, but it may be more effort than its worth depending on the situation

Permalink Reply by Ritchie Jackson on August 26, 2009 at 4:18am

Hi Damien,

Thanks for the considered feedback.

I guess the crux of the matter is the logical organisation of components, whether custom or standard. If the latter are used almost exclusively is there some way of visually containerising them into "black-boxes" so that internal links are invisible and just the critical inputs and outputs show ? I've only been using v0.6.0019 and I have a feeling that in previous releases there was a "grouping" facility which achieved that purpose.

I agree that graphical networks provide accessiblity to both the creator and other users but the organisation needs to be clear. By this I mean that a large flow-graph with a multitude of wired connections is, for me, as hard to follow as uncommented conventional code unless explanatory text 'Panels' are used extensively. 'Receiver' objects are also useful in this context. Your comment with regard to using code to help with the cumbersome reorganisation of data in GH is especially pertinent.

Ritchie

Permalink Reply by Damien Alomar on August 26, 2009 at 9:43am

In previous releases there was something called clusters that would visually combine several components in to one "black box" component. David has taken them out temporarily but they'll be reworked and put back in. In some situations they were useful, but in others they were a little bit more cumbersome to deal with. I used them most for either A) consolidating nitty gritty operations that used a bunch of minor components or B) organizing repetitive operations.

I personally don't think that having everything out in the open precludes organization. I also think that an unorganized definition is as useless (communication wise) as one big component that does everything without exposing its method/process for doing it. Commenting, whether with panels in a definition or in code, should always be encouraged and help a outside reader (or yourself) understand what's going on without worrying about what's going on line by line or component by component. Whenever things start to get big, recievers are a must IMHO. The allow you to "section off" parts of the definition much as you would write a separate function to get those operations out of the main sub.