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:
http://www.grasshopper3d.com/forum/topics/grasshopper-vs-python-c-v...
http://www.grasshopper3d.com/forum/topics/vb-vs-c-vs-python
http://www.grasshopper3d.com/forum/topics/which-programming-languag...
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
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.
Tags:
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.
The nice surprise with C# for me was a relatively painless entry into the world of JavaScript. Although very different under the hood, the syntax is familiar. I am finding the ability to leverage the many open source JavaScript resources out there invaluable. I have come across other GH users finding novel ways to link JavaScript to GH. Flux is making that easier with the new JavaScript SDK (C# also). An example of the novel options it can provide here: https://goo.gl/NP5QCE
I should add the reason I brought up JavaScript is its predominance in web applications and that being a useful side benefit of following the C# path.
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.
On the VB.NET vs C# front: underneath they are essentially the same language, the differences are largely cosmetic so it's down to whichever form of syntax you like the best. VB will be slightly easier to pick up if you've done any scripting before in Rhinoscript or VBA in Excel etc. As noted, C# will be more familiar to people with C/C++/Java/Javascript backgrounds. I use both and both are great languages - I slightly prefer C# to write because it's marginally more compact, but VB.NET to read because it's more english-like so there's less translation effort needed.
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.
Dear Reader,
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.
Best,
Devang
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.
Cheers, Martin
Thank you
I guess it`s Python
I think that you need to understand what you are doing - marketing, SEO, programming, design or what you are doing there, you should have cases, examples, insights, and stories that will be interesting to your listeners. I also advise you to read the https://gradesfixer.com/free-essay-examples/world/ articles of these guys that they publish absolutely for free. Perhaps they will be useful. Good luck with that!
Welcome to
Grasshopper
© 2024 Created by Scott Davidson. Powered by