[Bf-committers] Blender roadmap article on code blog

David Jeske davidj at gmail.com
Wed Jun 26 07:07:45 CEST 2013


On Tue, Jun 25, 2013 at 12:40 PM, Jürgen Herrmann <shadowrom at me.com> wrote:

> You're not really trying to lure us into coding integral parts of blender
> in python, c# or mono, are you?
>

No..  Blender core code is large and depends on many useful third party
C/C++ libraries. I'd guess it's going to be C for a very long time
(possibly it's entire useful life).

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

 There is a reason why coders always fall back to c/c++, that reason is
> speed.
> Imho Type safety in c++ is not as critical as you present it here.


Let me explain my motivations differently...

Blender is an incredible piece of software, and I'm thrilled it exists,
thrilled to use it, and thrilled to support it.  I'm working on a VFX clip
right now, and I'm just *astonished* at what I'm able to accomplish -- as a
software engineer with little art-skill. who has never done any filming,
compositing, or even node-editing before. It's truly awesome....

....So it's sad that, for me, Blender crashes WAY too much and more than
any other program I have ever used. I'm just an amateur who hardly does
anything fancy.

This is why my #1 is automatic crash reporting and a crash-stats dashboard.
The only other blender users I have direct contact with also say it crashes
alot. I see it crash in youtube tutorials. I personally would like to know
how much it crashes. I think measurement is often a good step to
improvement.

However, lets get back to type-safety...

My (unproven) theory is the crashes and instability is primarily for two
reasons (a) devs are volunteers and there is more interest in incorporating
cutting edge features than spending time making sure every piece of C/C++
code is well behaved. (b) blender is primarily used on windows, and a
windows build takes quite a while to setup and get working, so it's easier
for software-engineer blender users to just work-around bugs and crashes
than help fix blender.

(a) can be improved with type-safety, but only for code that is written in
the type-safe environment.

(b) I'm guilty of myself. I have spent time filing bugs for small problems
that might have taken me less time to actually fix and submit a patch -- if
I had a working build. However, I've tried to setup a working windows build
before and given up for frustration and lack-of-time. I despise setting up
builds. Build setups are notorously under-documented, and my machines are
used for development, so I often can't just install the tools the build
wants in all the standard places because it collides with other versions of
the same tools. All of this means I just work around the issue and file a
bug instead.

...so, I agree type-safety is not a panacea. In fact, if I get to choose
between type-safety and enabling any blender user-dev to quickly and
trivially edit/compile/run/patch/share blender code, I'd take the latter.

The only path to instant embedded edit/compile/run/debug cycles I've ever
seen is extension languages, which also happen to mostly be typesafe, so
this is why I see the two as intertwined. A magic "push button" way to
automatically setup a windows build would be a great alternative if it can
be done.

A new/additional scripting language might be cool and is definitely
> something we should think about.



> Ok you could replace some parts of blender with scripted code, but I don't
> agree with your arguments at all.
>

Let's keep in mind the term "script language" is very imprecise, and is
being blurred by technology like JIT and virtual machines.

To clarify, I don't want to see more of blender written in Python, nor do I
want to see another dynamic typed scripting language added to Blender.
Consistency is good and Python is a good scripting language.

What I would like to see is: (a) Blender crash less, (b) an easier workflow
for a software-engineer blender-user making a small fix.

My hypothesis is that a static-typed extension language like
C#/Java/TypeScript would be a more viable way to develop "real" features,
not just scripts. This would allow more of blender UI and new experimental
features to be built in an extension language that won't crash blender. A
language that the user-dev community could more readily fix and improve,
because they wouldn't need to setup and maintain a whole blender-core build
to contribute.

Any of that seem more attractive?


More information about the Bf-committers mailing list