algorithmic modeling for Rhino
This question comes up a lot, and the answers below are compiled from my own experience and a number of posts by others:
VB.Net and C#
VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order:
Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable.
I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both.
I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there.
Excellent article Andrew - when I started customizing my own GH components I chose C# on the assumption it would give me better performance. It was a steep learning curve at first but there are a lot of resources out there.
This seems like a good summary to me.
I teach people coding in Python, because that's the easiest language to get people who haven't coded before up and running and producing usable scripts quickly, but I personally tend to use either VB or C# and would recommend those instead to anybody who's in it for the long haul and is willing to put in a bit more effort up-front, because those languages are ultimately a bit more powerful in terms of what you can do with them. Even if Python plugins become available that's probably not a task I would choose to use that language for - the features that make VB and C# feel a bit more complicated and restrictive than Python really start to make sense when you start developing bigger, more complicated, multi-file projects.
Of course, learning any one of these languages will put you 75% of the way towards being able to use one of the others, so it doesn't really matter all that much which one you choose first. The key criteria in real life is usually whatever language your friends and colleagues are using, not only because it makes it easier to get help but also because it boosts productivity if you can share and reuse code, and when some hiccup in a script comes to light the day before a deadline it's an excellent idea to have somebody else on hand who stands a chance of understanding and fixing the code in case the original author isn't around.
I really like Paul's approach of learning the one language that "your colleagues" are using, and working under the assumption that this way you will be able to get more help and be able to collaborate better. +1
Just like everyone else has said, Python is a great "entry" language to learn, and once you get that, you will be able to transition to any other language with relative ease. I personally use both (python and C#) because I can use Python components to test an idea out really quickly without need to compile anything and then when I am comfortable with it, I usually transition my components to a library that was written in C# (I do most of my work in Dynamo/Revit environment but don't think that matters here in context of the conversation).
Great write up Andrew!
Excellent notes from Andrew! Great tips from Anthony, Paul, and Konrad. Thank you all for sharing your experience. I would like to add something to this thread.
While it is good to start with a language that you find easier to learn by following a tutorial series or reading a book, if you are in for the long haul, things typically won’t end there. You will soon realize that finishing an introductory course on a language will not completely enable you to contribute in terms of development of tools if that’s what your aim is. For example, you’ll really need to understand object oriented programming if you want to work with an already established group. You need to learn and understand the API of tools that you want to contribute to. You might also encounter the need to use external libraries for the language you are using. All of this will require you to read and understand a lot of documentation. If there’s no good documentation, you’ll need the skills to read and learn from someone else’s code if they have done something similar. All these processes can be very mind bending and therefore, the keys will always be patience and perseverance.
Start out with a language, but be open-minded to learn and accept other languages and technologies too. All the people who have contributed to this thread before me have experience in more than one language. I hope you realize by now why did they not end after learning one language.
Paul’s made a brilliant point. While it will not cut down on the work you’ll have to put in to learn things, it will invariably add some luck in difficult situations. If you are the first one in your circle and don’t have friends and colleagues with such skills, I recommend you find online communities and groups. That would help a lot.
I would say that compiling in VS offers the following advantages:
- Proper debugging with step-through, performance profiling etc.
- Slight increase in performance.
- Can completely customise the component by setting the icon, adding menu options and use an entirely custom GUI for it if you wish.
- Can implement your own custom data types/'goo'.
- Can create different types of component (parameters, value lists etc. etc.)
- Can reuse code between multiple components.
- Easier to reuse in different definitions or share with others as a plugin (you can wrap up scripts in user objects, but I find that to be a bit less neat).
- You can use external libraries etc. with scripting components, but Visual Studio does make this a bit easier to manage.
- You can add more in the way of documentation to the component (i.e. tooltips, Help documentation etc.)
- Much less buggy than the script editor (i.e. it won't delete your type arguments *every single f*%#ing time* you try to instantiate a new generic object...)
- You have ultimate power and can do pretty much whatever you want. (Cue ominous thunder...)
There are however a few disadvantages:
- You need to write your code, compile it, install it and then run it in Grasshopper - it's not as immediate as the write-try loop you have with scripting components. (You can make certain minor changes to the code while debugging, but more major ones will mean having to shut down, re-compile and re-run).
- You need to write a couple of extra functions to populate your inputs/outputs, declare a GUID etc. You also need to extract your inputs in a slightly more complicated way. The script component takes care of all this stuff for you.
- Other people who open your definitions will need to have the plugin installed as well or those components won't work - it's not embedded in the definition itself like a script is.
I tend to grit my teeth and put up with the awful script editor if I'm just writing short scripts that are specific to that particular definition or if I'm in the early stages of writing a new tool and just want to experiment. I'll switch to VS if it's becoming something larger and more complicated or that I might want to reuse or share. Excluding the input/output parts, the bulk of the code is going to be the same no matter what you're using, so it's not too much of a commitment to go from one to the other.
Thank you, Paul!
The difference is smaller than I imagined then. I think your last paragraph sums it up well, and it makes me less catious spending time in the scripting editor.