Home

Round 3: A rebuttal by ayg011

September 12, 2012

On April 1st this year I wrote a blog post called Programming, conflicting perspectives which was partially a response to several comments left by a user called ayg011 on the Grasshopper forum. Ayg’s original comments had an unmistakeable veneer of bitterness, even vitriol to them, but I was glad to find a thoughtful response a week ago.

Rather than taking this discussion into the comment section, I prefer to continue it as another top-level blog post, because it is an interesting and important discussion. I hope the inherent imbalance between our respective manifestations* —blog owner vs. commenter— doesn’t lead to an unfair advantage in favour of the points I am arguing.

Anyway; round 3. Ding!

“The example you have used to argue that there is no difference between GH ‘programming’ and any other language is poor as it conveniently ignores all of the key concepts programming offers which GH is unable to handle […]”

Guilty as charged. I did pick a very simple example, something devoid of both conditional statements and iteration or recursion. Grasshopper —like most node-based editors I know— is notoriously bad at control flow design. An amended example that does include a conditional statement could look like this:

public Vector3d VectorFunc(Vector3d A, Vector3d B)
 {
    A.Unitize();
    B.Unitize();
    if (A.Z < 0.0)
        A.Reverse();
    return A + B;
 }

with the Grasshopper equivalent being this:

A number of observations can hopefully be agreed upon by all parties:

  1. The increase in relevant characters in the C# code is roughly 50%. I’m discounting characters which could have been omitted.
  2. The increase in relevant objects in the Grasshopper code is roughly 100%. Where before we used 5 components with 4 wires, now we need 10 components with 11 wires.
  3. The legibility of the C# code remains high.
  4. The legibility of the Grasshopper code suffers quite badly.

It certainly seems to support the notion that Grasshopper is a worse programming language than C#, at least in terms of efficacy, which is a very important characteristic. But is it sufficient reason to jettison Grasshopper from the realm of the ‘real’ programming languages? I’d argue that this is not a fundamental asymmetry, but rather a matter of degrees.

Take for example a language such as VBScript. It can deal with conditionals and loops and recursion quite well. Does that mean it’s on a par with C# or VB.NET? Well… no. VBScript cannot do threading, which is possible in VB.NET. If you never use threading you’ll be unmoved, but if you do it may well be a deal-breaker. So you switch to VB.NET and you find that you cannot access memory directly using pointer addresses, which makes bitmap-processing significantly slower. So you switch to C# since it has the unsafe keyword, or even to C++ which provides fine-grained control over the memory. And the regression doesn’t end here, if you need even more performance than C++ can give you you may need to switch to Assembly and so on and so forth.

To say that VB.NET is not a programming language because it can be outperformed by C++ is ridiculous. To say that VBScript is not a programming language because it can be outperformed by VB.NET is ridiculous. So would it be ridiculous to say that Grasshopper isn’t a programming language because it can be outperformed by VBScript?

Here’s a different way to make the same point. What if next week I add a mechanism which makes adding conditional statements to Grasshopper networks straightforward? Would that propel Grasshopper into a different category? I doubt it. Adding such a feature would be an incremental update, not a paradigm shift. In the meantime —and perhaps forever— Grasshopper is indeed rather lame concerning conditionals and loops.

“There is a limit, particilarly [sic] when it comes to conditional statements, loops, and efficient data structure (the list structure in GH know [sic] as ‘trees’ I find to be highly esoteric, stifling and worst of all a non-transferable skill […]”

I find this an interesting point, because it is both true and yet mostly irrelevant in my opinion. Ignoring the bit about conditionals and loops since we just talked about that, I wonder what it means to the status of a programming language that its primary data storage is inefficient, esoteric, stifling and non-transferable.

I assume the word ‘efficient’ is used to refer to memory overhead concerned with storing data in a tree, as opposed to some other mechanism**. I wonder how ayg011 knows that data trees are inefficient. What have they been compared against? And under what conditions?

Esoteric and stifling are things I do worry about myself. Languages such as VB.NET and C# have a lot of different options when it comes to data storage. Individual variables, arrays, lists, arraylists, sorted lists, linked lists, collections, synchronized collections, readonly collections, dictionaries, sorted dictionaries, hash tables, queues, stacks… the list goes on. Datatrees are an attempt to provide as flexible a mechanism as possible for the problem of storing any nesting depth of jagged array (sparsely populated if need be). I concede they are complicated and can be daunting to use and I’d love to hear some ideas about making them a bit more cuddly, but I don’t see a workable alternative that would both significantly reduce complexity while maintaining —let alone increasing— efficiency and flexibility.

Finally, I find the objection that a skill is less worthy because it is non-transferable very sketchy. I would hope that people learn Grasshopper because they want to work with Grasshopper, if anyone out there is using Grasshopper as a springboard to learning C#, why not just learn C# and be done with it?

“Once this limit is reached, conventional programming methods have to be used (c++ or python component etc), which proves there is a difference and you can’t truly call GH ‘programming’.”

Once penicillin no longer helps you may have to switch to stronger substances (Augmentin or Azithromycin etc), which proves there is a difference and you can’t truly call penicillin ‘medicine’. See? It does not follow.

“At this point, for the reasons above, I stipulate that due to the convoluted methods of creating a definition, along with the plethora of different components that will undoubtedly require a lengthly [sic] and protracted training programme for new users, that GH will forever remain a niche; the betamax of the parametric software world.”

I think all programming requires a lengthy training programme. And I suspect that there’s a disturbingly large percentage of people —not correlated with intelligence— who cannot be taught programming at all. Whose reasoning and thinking patterns do not lend themselves to translation into algorithmic operations.

Grasshopper is not for everybody. It was never intended to be for everybody. Robert McNeel & Associates feel the computational architecture/parametric software world is big enough to warrant continued development, even for a niche product. I do not know how long this state of affairs will last. Perhaps computational design is really a fad after all and people will lose interest in 2 years. Perhaps the Grasshopper user base will dwindle due to a blossoming of competing products, within or without Rhino. Perhaps students will start learning C# en masse and be frustrated with the lack of flow control that Grasshopper provides.

* Christ I miss the time when one could use the word “avatar” without sounding like a 14 year old boy. Now I’m stuck with “manifestation” or “reincarnation”.

** If I’m wrong about this, please correct me.

*** I hope anyway, it would be a sad world where Grasshopper is forced on people.

3 Responses to “Round 3: A rebuttal by ayg011”


  1. I can’t believe people are still making this kind of exclusionary argument. GH is absolutely programming, as is Scratch or any other graphic system. One of the things I love about working with it is that is exposes a base fact of most parametric design- that it is rooted in directed acyclic graphs, with all of the advantages (stability, clarity) and limitations (rigid topology, limited interactivity) that they confer. If computation ever becomes a common practice in design it is going to be because of methods like GH, not in spite of them.

    Also, this: http://xkcd.com/378/

  2. visose Says:

    Ok, hold it, hold it, hold it. Let’s see if i got this straight…

    His son was the ball boy?

    • David Rutten Says:

      Yes, but I posted it mostly because of the final comment; “it lets you see what you want to see and miss what you don’t want to see.” which is sort of the underlying idea of Grasshopper as well. Programming without any of the surrounding complexities like compilers or run and debug buttons.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: