I’m at a low point with C# for multiple reasons. I’m about to learn Python. Is anyone else dissatisfied with C#?
1 Like
What’s got you down with C# @keithscadservices?
1 Like
For one, it’s hard to pronounce three times fast…
11 Likes
Programming languages with no curly braces (no clear scoping boundaries) relying only on white space, is for people that like to shave off their eyebrows for convenience. 
8 Likes
The short answer is just a very meager return on investment time-wise. At this point I’m wondering if it’s just better to try something else.
The long answer:
I think C# is a good language but has some inherit flaws Including…
- Not the greatest documentation/learning content - This applies to both the language itself and API documentation. A lot of the stuff out there just isn’t polished off (probably the last thing a burnt out developer, especially a volunteer, wants to do). Lots of books and videos on C# aren’t great either. I have (finally) found a few really good books. But since I hadn’t when I first started progress was insanely slow. I’m not sure what it is about Microsoft, but anything Microsoft related ends up producing mountains of useless learning resources (whether it be C# or Excel). An additional issue is that many C# authors are explaining the code as if they’re teaching someone with experience in another C-based language.
- Too many hyped-up features that don’t work - Not related to Rhino/GH (hence the ‘Meta’ tag), but quite a few C# projects fell to the wayside. But not before eating up TONS of people’s time and energy. Maui sounds like the latest rendition of this. I read and watched a lot of hype around WPF making a comeback. I started to learn it and ran into some huge problems. One issue was a lack of a built-in file path (not file, file path) dialog. It’s since been fixed but f-me… I actually had to use a WinForms version (I’m actually a big fan of WinForms, at least it works reliably). There were other issues with WPF as well. And these types of issues are HUGE killers for new programmers because we aren’t skilled enough to know that the feature is broken and we haven’t missed something.
- Way too many different ways to write stuff - In my opinion this is unnecessary and killing readability. We have Visual Studio and Intellisense. We don’t need to abbreviate everything. Where this has the biggest impact for me is of course learning the language: It took me 4 to 8 hours alone just to figure out what Delegates were. And Lambda expressions. The syntax was written differently in almost every reference I had. And the explanations were beyond terrible. I finally realized that I had been basically using the same feature in AutoLISP for years without even knowing what it was called (lambda is actually called lambda in AutoLISP so I knew what that was, but delegates…). It’s almost scary: Me as a very green programmer learning a new concept in minutes verses me as a somewhat experienced programmer taking hours to learn the same thing in a different language… I hope I didn’t have a stroke at some point and not realize it :-S
- Not a lot of good sample code for beginners - There is some more advanced open-source stuff around. But for beginners it’s either so basic it’s useless, or way beyond a beginners skill level.
- Much slower development speed - This might be partially on me. But I’ve seen C++ tutorials where the author is building something in say, 1 hour, faster and better than a 1-hour C# workshop. For myself, I’m way slower at developing C# in AutoCAD compared to AutoLISP. When I gave AutoLISP a break to improve C#, the gap narrowed, but the connectivity to AutoCAD wasn’t there; deployment was much slower. There are YouTube tutorials where people build stuff really fast but it’s garbage.
- More stuff available in other languages - For Rhino, it seems like Python is king. There are also way more examples available. Regardless of any languages drawbacks, how much it gets used and how successfully speaks volumes. AutoLISP is the most widely used language for AutoCAD and hence has the best examples available.
I originally learnt C# because I figured I’d be able to focus on a single language for both Rhino and AutoCAD. So far I’ve found it to be next to useless. I’ve created a few okay tools but the overall time it took… I think I would have been better off learning Python. I want to learn C++ too but that’d be like a featherweight jumping up to heavyweight.
This is a good place to dredge up opinions. Posting something like this is a good way to see if others feel the same way, or if I just have to pull up my slacks and try harder.
3 Likes
Why not just give python a try then.
Scripting languages like python are generally faster to write and experiment with than compiled languages like c#. That said there are a number of things you currently can not do with python in Rhino that you can do with C# and these features are all related to creating a plugin. You can create a plugin with python, but we haven’t added all of the bells and whistles with regards to plug-in related features for python yet.
2 Likes
Thats a pretty fascinating answer, thanks for explaing so well.
Personally I learnt python, then C# and now I’m learning Rust. I LOVE python for scripting and web stuff using django. I love C# for Rhino/GH, libraries and it’s my usual go-to now. Rust is really cool where I want to go low level and really focus on my memory and optimisations, that said, I’m still learning.
I do see what you mean with Lambas/delegates in linq being a very tricky concept to throw infront of new developers without even a footnote.
I think the most important question is, what do you want to make? Any programming language is simply a communication tool between yourself and the computer, and it sounds like C# isnt letting you express your intent as well as you’d like.
Steve is bang on, give python a shot and see how you like it. Tasting new languages is always a good shout 
!
And some day you may find you need static types or access to functions python doesn’t have and C# might be the right tool for the job then.
3 Likes
Is McNeel officially going to support C# plugin development on macOS, given that Microsoft is discontinuing Visual Studio for Mac this year?
Yes, of course. VSCode will most likely end up being the dev environment of choice.
– Dale
2 Likes
I’m planning on learning C++. I’ll be ignoring things like python.
3 Likes
You can also use Rider quite easily and successfully! I program Crash entirely on Mac and only debug on Windows to test cross platform 
That being said, I think VSCode is the best choice for McNeel
I used VS Code with AutoLISP. I didn’t like it. But it has lots to do with whatever plugins are created for the programming language you’re using. Back in the day, we have editors for AutoLISP and VBA (still do of course, and they work good, they’re just old eyesores). As soon as I started using Visual Studio Code and all it was hyped up to be, I quickly realized that it was a downgrade.
I see the advantage: You have a starting point and then you just need to add whatever you need to it to make it function as an editor for whichever code your targeting. With AutoLISP they (Autodesk) failed to do that. And they didn’t document it well meaning you have to feel your way around in the dark. The old AutoLISP editor being what it is was easier to figure out. And equally important, if I needed to look something up about it the information was there.
The funny thing is that I seem okay with making scripts in C# (for GH that is). It’s the RhinoCommon that beats me up (when talking about programming related to Rhino that is).
One big reason I’ve thought about switching is that most of the time when I get help for C# the person that comes through shares some of their Python code. From there I have to translate the code into C#, which to be honest is fun, but at my level it just takes too much time.
For me I’ve found that learning code is very much momentum based. My example above: The missing file path browser (I should mention that it is fixed now apparently); that alone ate up an entire weekend which I had set aside for “programming”. So something that took minutes to figure out in an otherwise inferior language took me an entire weekend. Getting stuck like that is very much a momentum killer. And problems of that nature don’t really help you learn in any way. I do find however that taking a break and getting back into it is a good way to regain that momentum.
You get really good opinions on this forum. So since I haven’t heard anything along the lines of “you’re right: C# sucks”, I think that a nice long think is in order before deciding to throw in the towel. I’m the only one complaining so that’s a sign that I’m the problem lol.
Python looks like a fun language to learn. What’s stopping me is that I actually do quite well as far as scripting in C# goes (for a GH component for example). It’s when I get into writing commands.
5 Likes
Perhaps I’ll give Rider a try. Is code completion for the RhinoCommon SDK available?
Yep! It works really nicely!
1 Like
What is it you struggle with here? Are you new to RhinoCommon or have you used another flavour of RhinoAPI such as RhinoScriptSyntax?
Are you mostly scripting or doing Grasshopper?
This is actually how I originally learnt C#! It is quite tricky.
I absolutely hear that, learning a new library, language or syntax can be very frustrating.
It certainly is! You should give it a go! It’s more similar to LISP as I understand it than C#, so it might be more up your alley.
I’d suggest using python for everything else, and C# when you have to then 
1 Like
Don’t worry, we’ll continue to beat you up with python when it comes to RhinoCommon. Learning large libraries is typically a big task no matter what programming language you use.
5 Likes
From and old CAD (ex)user that always preferred scripting the CAD program than using it … 
Disclaimer: all the following IMHO, I’m not a pro developer.
( Also … sorry for my poor English )
I agree on that. You’re right.
But for non-official docs, I think it’s the same for any language nowadays.
A lot of poor stuff on the net …
Still I agree that learning a Microsoft language, not having clear official docs is a hurdle, when you start from zero.
I would ask for advice here about some good book/PDF to experienced C# users.
I’m not one, sorry.
I learnt to use C# several years ago, when it was way simpler,
and having used C (love it !) and Java (again when it was simple) before, so it was pretty easy for me.
(And BTW I also tried to use C++ (again when it was simple), but then I abandoned it.
too complex for me, also I don’t like OOP so much )
( I woudn’t say that features don’t work … )
But sure there are several different ways to do things.
But that also applies to a lot of (if not all) modern languages today.
( Maybe Lisp is not considered modern any more, so people don’t keep addding features to it … dont’ know )
Languages generally are no more what they used to be 30 years ago.
They keep adding things, and Python is no exception BTW.
I wouldn’t ‘waste’ time trying to learn all those ‘moders’ features.
In my humble experienxe, you can happily use a language without knownig all that ‘hesoteric’ stuff,
just use the basic features and 90 % of times (if not more) you’ll be fine.
You can always learn a feature you need when you need it.
Particularly, using C# for Rhino does not require all those things.
Maybe a delegate if you want to use events …
But for ‘regular’ Rhino and GH scripts, normal OOP stuff is generally enough.
IMO this may be just a lack of experience, expecially compared to Python.
Talking about syntax, Python and C# are not so different.
Lisp may be more concise, I agree
( BTW I love Lisp, even if I actually never used a proper Lisp interpreter )
Python and C#, like other languages, descend from C in some way.
Their syntaxes are similar.
They are both very different from Lisp.
True.
But if you’re going to use RhinoCommon, and not the much more limited rhinoscriptsyntax library,
please note that you’ll end up using often Python in a C# way, so to speak.
RhinoCommon is a C# library, and to understand how to use it easily, you’ll have to know some C# feature anyway.
The time you spend learning C# will not be wasted in any case. 
I have nothing against Python, I’ve written a lot of scripts with it. I like it.
Just don’t expect it to be so different from C#.
But if you feel that learning Python will be easier, just go for Python.
You’ll be able to do the same things in Rhino.
And you’ll be able to ask here for help for either language. 
2 Likes
This would require me to dig up my actual code and try to figure out what I was struggling with. To make things more difficult I was eventually able to get the core commands I was working on to actually work.
The documentation on RhinoCommon, for me at least, isn’t good enough. Thus far I’m one of the only ones to complain. Better documentation however would probably increase my development pace 2 - 4x. I can either teach myself to code with good samples, or good documentation, but I need one or both. The best AutoLISP documentation is made by a 3rd party not Autodesk. And sample code is plentiful. Many/most of the AutoLISP tutorials are also written by someone who was a drafter first and learnt to code after. C# is usually an experienced coder trying to teach other experienced coders how to write code.
ETO forms was another thing I went nowhere fast with. The documentation for ETO forms is lacking. I will state that it’s not just me because of the two sample codes provided, one sample is missing key information. ETO seems like a good system, but with such a high barrier to entry they run the risk of having nobody who knows how to use it.
In this case I was creating a RhinoCommon command. I don’t want to say “plugin” (even though technically it was a plugin) because there wasn’t much to it. I’m basically creating small individual commands to make annotating quicker. They work but I feel like I’ve aged 10 years lol.
I’ve also successfully written scripts for GH components but I’m really not much of a Grasshopper guy. This however is one area that I don’t seem to struggle in (ironically the least crucial area).
Don’t get me wrong it’s fun and challenging. But the hour glass runs out eventually.
There are lots of no-go zones with C#. You could call these time pits. Xamarin? and then Maui (if they don’t fix it). WPF as I mentioned was broken. An experienced developer would have found their way around it. I suppose I even found a work-around eventually. But it was time intensive. I guess the time is what’s killing me.
YES! I should have just learnt WinForms (one of the best books I have is focused on WinForms, but is written so well that it helped me understand many different aspects of the code). I actually burnt a lot of time trying to chance the fancy features of more modern dialogs.
With AutoCAD, many developers often say that you can’t do something in AutoLISP that you can with other API languages. Although this is true, usually the examples they use are wrong. And they usually exaggerate what can and cannot be done. It’s usually a very small amount of stuff. And a smart programmer can find a different way to achieve the same result using a different approach. AutoLISP lacks rich dialogs, but you can combine the code and a customized user-interface to achieve the same result. Sometimes I make the mistake of trying to pretend I’m a programmer when really I’m just a drafter/designer/3D modeller who also writes a little bit of code; I should choose the easiest option that can do what I need. Maybe I envisioned myself being a better programmer by now when I chose C#.
2 Likes
I think that what you say may be true for typical end users of Rhino who write scripts here and there for personal use but who focus on using Rhino and creating occasional tools, not on developing tools. Python gets the job done quickly and cleanly in a format that’s easy to share with others and tweak a few months down the line if your needs change slightly.
In particular, and this is entirely subjective, I find scripting in C# within Rhino to be painful and inefficient (vs Python) while I am very happy with C# and Rhino in the context of Visual Studio. This has much more to do with the environment (Visual Studio vs Rhino’s script window) than it has to do with the language itself. Debugging, stack trace, complicated cases like events, etc.
Your comment may not be as correct for people a step or two more toward the tools side who write Rhino plugins or grasshopper components intended to be more general purpose that they intend to use, extend, and maintain for a longer time. This group includes everything from people who write and maintain internal tools for themselves or their companies as a side task to dedicated software developers.
I am most emphatically not saying that I think one group or approach is superior to the other: there’s a reason that Python was designed as and is called a scripting language. The two are entirely different use cases.
1 Like