[Bf-committers] Blender roadmap article on code blog

[David Jeske]

On Wed, Jun 26, 2013 at 4:56 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

> This seems like admitting defeat before identifying the problem,
>  as if you say --- "Blender crashes for me therefor you should use a
> new language"
>

I fear my wordy detail is confusing my message. What I'm trying to say is..

"I wish more blender code for UI and new features could have zero delay,
zero work, zero build-setup between a casual user-dev like me seeing a
(small) problem in the UI or a new feature, and doing an
edit/compile/run/patch cycle."

....This way, all of the limited time I have to touch blender code could be
spent trying to actually fix code, instead of the current situation of
spending 1-4 hours wrangling the current build just to spend 1-4 hours
making patches to fix a couple bugs. Or not even starting because I know
this is what I'm in for. The more eyeballs fixing bugs the better.

This is where the slippery slope of my thought began, and it went like
this...

- I don't think we can make the C build instant to setup and included with
blender...
- so to get there would require more code to be written in an extension
language that blender can compile/run itself (like Python).
- Except I don't think more of blender should be pushed into Python...
because it's slow. and because code with no types is hard to read and
understand, and without compile-time type-checking, harder for non-authors
to change without fear of breaking something. Casual coding in a foreign
codebase without types and type-aware-completion is also much harder.
- So it would be great to have an extension language that didn't have these
problems. Something as fast as possible, that has static types,
type-aware-completion, type-checking, and where the compiler and build
context can be cheaply built right into blender.

What language systems can do that? Hmm.. well. There is  Mono/C#/Boo, and
there is TypeScript/V8. And maybe Google Dalvik/Java, though probably not
the JVM. Hmm.. might be an interesting idea to integrate one of these. The
graph editor, outliner, property panels, movie clip editor, masking and
tracking, video sequence editor -- tons of the UI could be written in one
of these languages without affecting blender performance much, making all
that code more accessible to more devs. The more eyeballs fixing bugs the
better. I wonder what other people might think of this idea.

I'm not expecting that to necessarily sell you, but I hope it is a clearer
explanation of my thinking.


> Read through your other comments, reasonable points but I would want
> to be convinced the errors you hint at _can't_ be fixed first.
>

Of COURSE they can be fixed! Any code can be fixed, in any language. This
isn't about a magic language. It is about iteration speed for the
setup/edit/compile/run cycle. The faster than cycle is, the more casual
devs can be roped in to help improve blender -- for however much code is
written in that extension environment.


> > 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.
>
> Crashes immediately is more likely to be some kind of build error (or
> incompatible libs/environment) then a bug in the code.
>

Ohh it was totally setup user-error on my part. I'm not saying the blender
build is somehow broken. Obviously there are lots of devs working on
blender, including all the new GSOC folks.

I spent another thirty minutes retracing my steps. Turns out when it said
to toggle to the "install" target, I did the wrong thing because I don't
know XCode enough to have understood the very-nice screenshot in the doc
the first time through. Now I need to figure out how to source debug, since
the XCode run button doesn't seem to launch blender.

.... which is all sort of my point. The time between when I thought "darn
it, I'm just going to try to fix this", and when I can actually begin to
dig through the code in this case was 2-3 hours of my time, and 12 hours
wall-clock.

Plus, I'm a software engineer. I'm impatient and hate setting up builds,
but I'm comfortable working in big foreign builds, and C/C++, with
code-generators, and third-party libs. However, I suspect there are also a
lot of amateur coders/scripters who would spend some time reading through
UI/feature code in C# or TypeScript trying to Code-Monkey out a patch..

....my theory is that reducing that setup overhead to just a few minutes
and using an easy language -- for an interesting subset of non-core blender
code -- would mean a lot more eyeballs helping fix bugs and improve
blender.

Of course the real book you can throw at me is that I spent more time on
this email discussion than I did setting up the build. :) However, I don't
think that invalidates the argument. Even if nobody is on board with me, I
hope it's interesting food for thought. Now I need to go fix some small
bugs and submit some patches before I get written off as a non-contributor!

Go Blender!