[Bf-committers] Blender roadmap article on code blog

[Benjamin Tolputt]

On 26/06/2013, at 3:07 PM, David Jeske wrote:

> ...though now we have to define "integral". I would like to see more
> blender UI and experimental features built in a static-typed extension
> language like C#/Mono or TypeScript.

I gotta say I neither want, agree, nor think this will ever happen. I say this as someone that is actually disappointed Python was chosen over another language for Blender's scripting language of choice.

I'm not trying to trash your ideas, because I understand somewhat where you're coming from in regards to wanting to improve Blender stability, but it does need to be tempered with a some facts.

Let's start with the runtime size. Everything you need ti run Blender comes packaged in the download. For the latest Mac OSX version (i.e. the one I'd be running if I wasn't building it myself) - that's 87MB. The latest stable Mono runtime is a 103MB download - all by itself and without any of Blender packaged into it.

Secondly, and perhaps Campbell can speak to this, but I don't think type safety is the largest source of bugs in Blender. At the level of code I've played in, the types of variables are clear and not violated through casting back & forth through void pointers (or similar nonsense). Sure, there'll be code in the application that does that kind of thing but, from what patches/bug-fixes I've looked at the solutions of, those practices are not the source. Again, I think Campbell could speak to this with far more authority (perhaps even pointing out I'm wrong), but that's the situation as I see it.

Thirdly, type-safety in languages like C# & TypeScript comes with a performance cost. There is a reason that most the third-party libraries used are written in C/C++ and it's not just because it's the de facto coding language of the OSS world. C/C++ is almost about one step up from the metal (when used the way most engineers write code). Type-safe languages, such as those you suggest, need to inject a runtime platform between the metal and the coded application - that middle layer provides your safety... using more CPU & memory than would be needed for the C/C++ equivalent. It's a trade-off and, frankly, Blender needs all the speed and memory it can get a hold of ;) 

I could go on & on about this. I've had to make this decision (safer language or faster code) many times. You can get fast & bug-free code in C/C++. I'll concede you might get the bug-free code in C# (or similar) quicker... but the resulting executable will be larger, take more memory, and run slower. 

With all that in mind, it took me less than a hour to setup my build environment both on Windows & on OSX (I already had the developer tools installed). If you want to do it, it's not that hard. If you don't want to do it, the ability to code in an alternate language isn't going to change that much. A C#/Mono implementation is going to need a development environment setup just like the current C/C++/Python setup does.

--
Benjamin Tolputt