[Bf-committers] Integration of scripts in the UI
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
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
For example, you could estimate & schedule how much work you can do (or
with other rendering code enthusiasts) to get things solved in the
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
> 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
> structures and architecture.
> I think that implimenting sensible underlying structure is very
> 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
> Bf-committers mailing list
Ton Roosendaal Blender Foundation email@example.com