Round 3: A rebuttal by ayg011

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.

Programming, conflicting perspectives

Different people have different ideas on what constitutes programming. The Assembly coder will scoff at the C coder for using high level function calls, the C coder will belittle the C++ coder for using classes, the C++ coder will deride the C# coder for not managing her own memory and the C# coder will mock the VBscript coder simply because she can. In my experience a lot of programmers seem to consider those who use older or more primitive languages as ascetic sadomasochists who waste their time and effort doing things that could be automated, while at the same time ridicule those who use newer or more high-level languages for toying around with ‘fake’ programming.

My own definition of programming would only include a single constraint; execution. Anybody involved in any job that ultimately creates instructions that are executed by a computer, machine or even biological entity, can be said to be programming. This results in some interesting, and perhaps counter-intuitive, consequences. For example, the writing of pseudo-code does not count as programming, because no machine will execute the instructions. Until of course someone writes a compiler for pseudo-code, at which point it will suddenly become programming.

Every now and again I come across someone who feels that Grasshopper is not a programming language. The main reason for this seems to be the fact that one does not write textual source code when using Grasshopper, rather instructions are combined in a visual fashion using primarily the mouse rather than the keyboard.  The user ayg011 on the Grasshopper forum recently took this position with a vengeance:

“Out of experience I can tell you that the problem you have would be solved via your own skill and intelligence in a matter of seconds, rather then clumsily relying on somebody else to write some code ‘packaged’ as a component, and ultimately restricting your capacity to explore novel design solutions in an intelligent way.

[...]  

Its merely a toy for students and hobbyists. If you are just starting out, invest your time more wisely and learn something which can be used over the entire life cycle of project. It’s so versatile that you essentially have unlimited potential and all operations remain fully in your control, or put in another way; you’re not restricted by the idiosyncrasies of another programmer who’s ‘components’ might be totally unsuitable for a novel idea you may want to explore therefore killling it.” ^[link]

His point is somewhat novel in that he doesn’t so much focus on the textual vs. visual, but instead focuses on the fact that all operations in Grasshopper come in a pre-packaged form; as ready-made components. ayg011 seems to feel this limits the designer:

“True originality comes from the freedom of expression; GC allows this, where as preconfigured ‘components’ in GH have an intrinsic limitation.” ^[link]

To me, this signals a profound misunderstanding of what programming is. Unless you’re Charles Babbage, it is difficult to make the claim that you are truly programming from the ground up and not being limited in any way by what other programmers have done before you. I would defend the position that there is no difference —none whatsoever— between this algorithm:

public Vector3d VectorFunc(Vector3d A, Vector3d B)
{
  A.Unitize();
  B.Unitize();
  return A + B;
}

And this one:

            

Whatever language you are programming in, you will always be initially limited by the SDK that other programmers have put together for you. If you have access to fine-grained operation (vector addition for example) you can always extend the SDK with your own functions as you see fit. Just like you can always write a novel story using a 26 character alphabet, you can always write a novel algorithm using a limited number of basic functions. This is what’s known as universality in computational theory.

ayg011 has a further objection, one with which I find myself far more aligned:

“My main concern is that the close-ended style of GH is going to trigger a generation of designers to plan their creativity around components they know exist in the software (so a tower becomes this identikit style of architecture that ‘twists’, or has a hexagonal parametric skin etc), rather then seeing it as a tool to realise whatever their imagination can think of (the beauty and strength of GC)” ^[link]

This is indeed a fundamental problem that faces us all. The easier it becomes to achieve something, the higher the likelihood that someone will achieve it without fully understanding it or without having an actual need to do it. Both are deplorable outcomes. It strikes me as a poor solution though to complicate the software to ensure only those with ‘true grit’ will be able to make headway.

This is a problem caused by easy-to-use software, but it is a problem that must be solved by better education. As an employee of a CAD firm, my job is to make it easier and easier for my users to construct the geometry they want. As a teacher at a university or college, it is your job to make sure that new tools are used sagely.