[Bf-committers] Blender roadmap article on code blog

[Campbell Barton]

On Thu, Jun 27, 2013 at 4:20 AM, David Jeske <davidj at gmail.com> wrote:
> 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!

You've made your point quite well and I see where you're coming from.

Personally I feel like we have enough big tasks ahead of us and this
would be another really big project - not just up-front but
maintaining, bug-fixing, and dealing with complaints when the api
breaks.
Even if some clever person gets mono integrated in a weekend - this
still ends up being many months (years?) of work to properly support.

At this stage though this probably needs support from the Blender
Foundation. aka "convince Ton its a good idea" :)