headers
hendrik | 2 Feb 18:13

Re: Lumiera work-flow

On Sun, Feb 01, 2009 at 08:17:02PM +0100, Ichthyostega wrote:
> tonsofpcs schrieb:
> > Long time listener, first time caller!
> Welcome to Lumiera!
> 
> > Anyway, after reading Nikola's post from 19 January, I wanted to add my 
> > thoughts. Having ideas for the projects eventual goal is great, but be aware
> > that you are trying to develop a workflow and interface that will work for 
> > the simple user and the professional.
> ...
> > I propose that instead of creating a simple workflow desirabilities document
> > as you have begun, create a simple set of guidelines for requirements before
> > the system is usable and the minimum workflow and interface requirements ...
> 
> While I agree with you on the goal, I actually think that it will help
> us to start out with a single consistent workflow description as Nicola
> started it. Because I think it's much more easy to reason and discuss
> such a closed and consistent document, than it is to discuss open-ended
> feature lists. Rather, I think we should then discuss this workflow and
> build up those feature lists on the results of the discussion, which
> includes ordering the features into urgent .... nice-to-have.
> 
> > Also, with the goal being a new editing system, I think the current 
> > concentration should be on the editing backend -- where the magic happens,
> Fully agreed, and actually that is what is happening right now.
> The Lumiera project deliberately started to build up from the
> technological core.

For that technological core, I believe you are using traditional 
programming langiages like C or C++ for low-level efficiancy at the cost
(Continue reading)

Permalink | Reply |
headers
Joel Holdsworth | 2 Feb 20:50
Picon
Gravatar

Re: Lumiera work-flow

On Mon, 2009-02-02 at 12:13 -0500, hendrik@... wrote:
> For that technological core, I believe you are using traditional 
> programming langiages like C or C++ for low-level efficiancy at the
> cost of additional effort in debugging, and at the cost of potential
> unfound bugs that crash the editor.

Hmm.... Yes and no. VMd languages like Java and C# and Lua help
eliminate a certain class of bugs: buffer overruns, deallocation...
general memory management. There are a few ways to mitigate against
these: the GUI makes heavy use if both STL, Stack Based programming, and
Boost - particularly Boost smart pointers which help reduce the danger
here, as well as extensive use of NoBug checks for sanity at every step.

The other thing is that the mistakes that Python et al. help you not
make, are the types of mistakes that you mostly see poor or
inexperienced programmers making. If you have programmers who are
experienced and reliable then these types of bugs almost never get
introduced in the first place! - all it takes is a simple awareness of
memory management issues.

Python won't help you not introduce other types of bug - functionality
bugs; there's no language that can help you not make those mistakes.

So with Python, Lua, C#, Java etc. you pay a very high price in both
memory and efficiency in exchange for things that we can do very well
without! - so long as we have competent contributors, which so far we
do.

> Might it be worth suggesting that the UI(s) be built in an
> easier-to-use type-safe scripting language (such as python or some
(Continue reading)

Permalink | Reply |
headers
hendrik | 2 Feb 21:16

Re: Lumiera work-flow

On Mon, Feb 02, 2009 at 07:50:34PM +0000, Joel Holdsworth wrote:
> On Mon, 2009-02-02 at 12:13 -0500, hendrik@... wrote:
> > For that technological core, I believe you are using traditional 
> > programming langiages like C or C++ for low-level efficiancy at the
> > cost of additional effort in debugging, and at the cost of potential
> > unfound bugs that crash the editor.
> 
> Hmm.... Yes and no. VMd languages like Java and C# and Lua help
> eliminate a certain class of bugs: buffer overruns, deallocation...
> general memory management. There are a few ways to mitigate against
> these: the GUI makes heavy use if both STL, Stack Based programming, and
> Boost - particularly Boost smart pointers which help reduce the danger
> here, as well as extensive use of NoBug checks for sanity at every step.
> 
> The other thing is that the mistakes that Python et al. help you not
> make, are the types of mistakes that you mostly see poor or
> inexperienced programmers making. If you have programmers who are
> experienced and reliable then these types of bugs almost never get
> introduced in the first place! - all it takes is a simple awareness of
> memory management issues.

I'm very much in favour of strongly, statically-typed programming 
language.  C++ doesn't go quite far enough in my opinion.  While it's 
abundantly clear to me that there are situations where you can't 
tolerate a pre-built, canned static type system (like the one built into 
the language you use), and you need ways to escape from it from time to 
time, C and C++ makes it too easy to do so by accident.  Usually the 
result is stray pointers and memory corruption.

>
(Continue reading)

Permalink | Reply |
headers
Ichthyostega | 3 Feb 02:58
Picon

Re: Lumiera work-flow

>> On Mon, 2009-02-02 at 12:13 -0500, hendrik@... wrote:
>>> Might it be worth suggesting that the UI(s) be built in an easier-to-use
>>> type-safe scripting language

> On Mon, Feb 02, 2009 at 07:50:34PM +0000, Joel Holdsworth wrote:
>> Well it's quite a long time too late for that, because the GUI is quite 
>> well advanced now.

hendrik@... schrieb:
> That's not the impression I got from reading the mailing list here, where
> everyone sems to be discussing how the UI should look but concentrating on
> building a solid back end.

Hi,
maybe I can help understanding this a bit better.
Actually, both is correct. Its now almost a 3/4 of work (in terms
of open source participation, of course) which went into building
up the foundations of our GTK UI. We are reaching the point where
features get visible. In many respects, the GUI is now waiting
for some facilities in the backend to hook them up.

On the other hand, indeed we are building bottom up and are mostly
concerned with things no one really questions and which we also
take for self-evident (like having tracks, clips, being able to
edit by dragging, having viewer windows, multiple play controls,
expanding and collapsing of entities, improving the handling of
panes and docks etc.

On the contrary, those things which are topic in the workflow
discussions are the fine points which indeed are very important
(Continue reading)

Permalink | Reply |
headers
prg | 2 Feb 22:30
Picon

Re: Lumiera work-flow

hendrik@... schrieb:
> I'm very much in favour of strongly, statically-typed programming 
> language.  C++ doesn't go quite far enough in my opinion.  While it's
>  abundantly clear to me that there are situations where you can't 
> tolerate a pre-built, canned static type system ..., C and C++ makes
> it too easy to do so by accident.  Usually the result is stray
> pointers and memory corruption.

Hi,

just to throw in a little comment...
Don't you think that exactly this is where experience on the side
of the programmer comes into play. For both C and C++ there exists
a quite save subset and there are proven methods in both languages
which allow you to work in a typesafe manner and use the help of
the compiler to spot misconceptions.

Cheers,
Hermann
Permalink | Reply |

Gmane