[Bf-committers] Blender roadmap article on code blog

[David Jeske]

On Tue, Jun 25, 2013 at 10:49 PM, Benjamin Tolputt <
btolputt at internode.on.net> 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 understand, and you may be right. I'd like to respectfully share a few
counter-points to your message...


> 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.
>

That 103MB Mono download size is not related to the embedded size as it
includes all kinds of stuff that would not be included. One dev found that
the embedded mono-runtime for his project was about
20MB<http://shishkin.wordpress.com/2009/12/24/mono-as-a-lightweight-net-runtime/>.
Many of the libs he included are not needed for Blender, though the
compiler would be needed because I want to compile directly from blender, I
suspect 20-25MB is close. V8+TypeScript is much smaller then Mono or Python
and is likely to remain so even as TypeScript matures, but with a loss of
included module functionality.


> Secondly, and perhaps Campbell can speak to this, but I don't think type
> safety is the largest source of bugs in Blender.


I'm specifically talking about segfaults, and I think we are having a
semantic issue. Type-validity, bounds-checking, and lack of direct pointer
manipulation are all part of Type-Safety. By my view, nearly any segfault
that occurs in C, other than failing to check a pointer for null, is
ultimately a type-safety issue in someone's code.

Of course a Type-Safe program can "crash" (aka, throw an Exception that
can't be handled). However, that backtrace is a pretty good indication of
where part of the problem lies. Wheras a segfault in C could be caused by
any number of data-stomps unrelated to the call stack.


> Thirdly, type-safety in languages like C# & TypeScript comes with a
> performance cost.


Yes, there is a performance cost for Mono/V8 relative to C, but for many
types of code that gap is quite small, about 1-3x
slowdown<http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=csharp&lang2=gcc&data=u32>,
shockingly Javascript-V8 is similar. Certainly smaller than CPython vs
C's 30-50x
slowdown<http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=gcc&data=u32>
.

I admit it's hard to predict what the slowdown would be for accessing
DNA/RNA without trying it.

A C#/Mono implementation is going to need a development environment setup
> just like the current C/C++/Python setup does.
>

An Embedded C#/Mono environment would include a C# compiler in blender,
just like Python's compiler is included in blender. Likewise for a
V8/TypeScript environment. All the source could be included and users could
edit/compile/run directly within blender, just like Python.. It would just
be faster and static-typed.


> 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.


Well.. there are lots of reasons more third party libraries are written in
C/C++. Those languages have been around longer. Integrating GC models is a
"hard problem", so C/C++ offers the greatest flexibility for library code,
since it can be imported into any runtime. And of course, when code is
heavily leveraged, the work of expunging all pointer and bounds bugs is
worth the effort for the performance gains.

However, I don't think any of these arguments hold for new experimental
blender features and UI. I personally would gladly give up 1-3x performance
for new features to get no segfaults, simpler code, and the ability for any
user to edit/compile/debug/patch that code within blender without
setting-up a build system.


> 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).


This evening I followed the steps to setup an OSX / XCode build, hoping to
fix my list of retina bugs. A couple hours later I have a built-binary, but
it crashes immediately on launch. I'm too unfamiliar with blender to have a
clue what is causing it.