[Bf-committers] Integration of scripts in the UI

Ton Roosendaal bf-committers@blender.org
Sat, 6 Sep 2003 16:34:04 +0200


I know my coding past might justify such suspicions, but certainly it  
was not meant as advertisement for quick hacks.

Quick hacks only are for "easy" coding, doing things "simple" is  
different. Complexity is not by default good, can be as dangerous as  
quick hacking.

A famous quote I cherish is from scientist Carl Wiemann, who got a  
Nobel prize for his work on Bose Einstein condensation. In a famous  
Huygens Lecture in the Netherlands he said "It's simple, but not easy".  
I've imprinted that one. :)

Yes, the state of blender code is cumbersome, difficult to understand,  
partially unstructured, totally undocumented, and stuffed with code  
that should be removed and cleaned up to reveil its original intentions  

Then how to tackle this problem? Most oviously the original creator  
(and cause for most problems!) should assist with that... and  
unfortunately he can't afford to work for more than half a day per week  
on code. This task will demand many weeks of non-stop concentrated  
I sometimes feel in I'm stuck in a sortof catch22... doing all things I  
need to do minimally moves things too slowly forward. But when only  
doing one thing I'm afraid other projects will collapse. Rationally, I  
best could invest time in finding a sponsor or fund or subsidy to pay  
for a small Foundation office to run all operations, then freeing up my  
time to work on Blender more.

A restructuring & documenting of Blender code might well be impossible  
to do with only volunteers who also can work max 1 day a week on this.  
So, for as long that situation lasts we have to define smaller & more  
feasible targets.
For example, you could estimate & schedule how much work you can do (or  
with other rendering code enthusiasts) to get things solved in the  
render module.
With - of course - keeping in mind that at a certain moment it's better  
to start over, from scratch. Another catch22, right? :)


On Thursday, Sep 4, 2003, at 20:58 Europe/Amsterdam, Nathan Vegdahl  

>> My experience learnt me to always choose for the simplest monkeyest
>> proof solution, which includes only requirements you really know you
>> need. Growing pains always will happen, no matter how smart you think
>> you can predict a future.
>    I don't really understand most of the discussion (I don't know much  
> about UI
> programming), but I would like to respond to the above statement.   
> When you say
> "the simplest monkeyest proof solution" it sounds like your talking  
> about a
> quick hack.  I think that quick hacks, for anything other than a purely
> temporary solution, are very bad for the overall code.  The state of  
> Blender's
> source code when it was first released (and even now) is evidence of  
> that.  It
> makes for very dirty code, with difficult to understand (and  
> inconsistant)
> structures and architecture.
>    I think that implimenting sensible underlying structure is very  
> important,
> though it sometimes requires rewriting a good deal of code.
> --Nathan "Cessen: Vegdahl
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
Ton Roosendaal  Blender Foundation ton@blender.org