Learning VB.NET and RhinoCommon

I've decided that my ignorance on the subject is simply too great, and I'd like to make a concerted effort to learn VB.NET and RhinoCommon specifically for scripting in Grasshopper and Rhino. What would be the best resources/methods for doing so?

Thanks,
Marc

Replies to This Discussion

Permalink Reply by David Rutten on September 8, 2010 at 9:43am

I wish I had a good answer to this question, as it is a legitimate and frequent one. But I don't.
Learning a programming language takes a while (not that long). Learning best practices and building a mental library of partial solutions and algorithms takes years.

The web is a great resource for programmers as you can find example code on almost any topic. Unfortunately there's also a lot of really bad code out there and as a beginner you probably can't tell the difference.

As far as print is concerned, I prefer reference books to reading books. I my experience you're much more likely to learn something when you truly need it, which is never the case with hypothetical examples and homework assignments.

Please feel free to ask questions that are tangential (or even perpendicular) to Grasshopper and/or RhinoCommon here. Another excellent resource is StackOverflow.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Marc Syp on September 8, 2010 at 10:02am

Thanks for the reply... are there at least some good starter materials to help me understand how to begin working with Functions, Methods, Classes, etc? For instance, the GH Primer has a section on VB programming. Is that a decent place to start, despite the fact that a lot has changed since then? Or should I pick up a "VB.NET for Dummies" from the bookstore?

Thanks,
Marc

Permalink Reply by David Rutten on September 8, 2010 at 11:39am

The following seem promising for introduction to OOP and Windows/.NET programming:

http://visualbasic.about.com/c/ec/12.htm
http://www.homeandlearn.co.uk/net/vbnet.html

Unfortunately most introductory courses start with Windows.Forms programming (the design and interaction with windows), which is exactly what you don't need when you want to start with Grasshopper.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Damien Alomar on September 8, 2010 at 1:09pm

There's learning the language, learning Object Oriented programming (OOP), and there's learning RhinoCommon (and to a lesser extent, the .Net framework). Learning VB.Net is pretty straight forward, and there are tons of good books and websites available to do so. Learning OOP is going to be necessary in order to understand what's actually going on with RhinoCommon and to be able to interact with the all the things you'll need to in order to get things done. You're going to need to understanding how things like inheritance, hierarchy, and abstract classes work, but because you're just working with them, not creating them yourself, you don't have to understand all the small nuances right when you start out. Again, this is a heavily covered topic, so most intro books have a short section on it and there are a ton of web resources as well.

Then there's learning RhinoCommon. This is going to be the hardest thing because there really isn't all that much information out there for this at the moment. The best thing to do is start with simple classes, such as Point3d, Vector3d, Plane, Line, and Circle, and get used to dealing with those objects first. Starting out "small" allows you to get used to the syntax and working with objects and will allow you to get your feet wet with RhinoCommon without having to jump into the deep end. The good thing about RhinoCommon is that is much more natural and straight forward when compared with the old .Net SDK, so you'll hopefully be able to pickup on things easier and quicker. After you begin to feel comfortable, then you can start working with more complicated curves, surfaces, b-reps and meshes.

The "unwritten" thing with coding is that you also have to understand how you're going to solve your problem. A lot of people think that coding is the answer that will allow them to go from A to B, and that's it. The reality is that you have to know and understand each little step of the process of going from A to B and manage it. After a while of coding, this becomes the majority of what you spend your mental effort on. Its not figuring out how to write a given function, its what that function actually needs to do, step by step.

Like I mentioned with RhinoCommon. Its best to start with simple problems. Ones that you either know almost all the steps to solve or ones that you've maybe solved already. Try making grasshopper definitions, then translating them into a single (or series) of scripting components. That way you'll already have a solution to work with and a guide for how to get your script done.

Permalink Reply by Steve Lewis on September 8, 2010 at 1:28pm

Even though I am not a novice at programming, I would still like a reference for good coding practice. For example how to improve the speed of my code, where to use if
Else branches and where to use select case branches for example.
Use of orelse vs or etc.

Permalink Reply by David Rutten on September 8, 2010 at 2:09pm

Hi Duck,

optimization comes in multiple flavours. Macro-Optimization is difficult but generally yields good results, especially if you're implementing proven algorithms (binary search vs. linear search for example). Micro-Optimization rarely makes a big difference, especially when you're using 'smart' compilers like modern C++ or .NET ones. In fact, it's not that rare that an attempt at micro-optimization is actually detrimental, as the compiler suddenly no longer 'understands' what it is you're doing and can no longer help out.

Two things I've learned over the years about optimization:

1. You will not be able to guess/deduce which parts of your code are bottlenecks. Don't start blindly optimizing code. Always always always profile your code first. You can either build in custom profilers (the .NET framework supplies some useful classes for this) or use an external profiler (I use RedGate Ants).

2. Debugging code is twice as hard as writing code. Therefore, writing complicated optimizations that stretch your skills to the limit is pointless and frustrating. You will not be able to debug your optimized code and end up worse off than when you started.

As a general piece of advice to everyone who wants to get better at optimizing, I'd recommend to have a good long look at the System.Diagnostics namespace as it provides all kinds of useful goodies to aid you in your quest for the Holy Cycles.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Philipp on September 18, 2010 at 4:42am