Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report

[Felix Duesenburg]

Argent Stonecutter wrote:
> On 2008-04-19, at 05:05, Felix Duesenburg wrote:
>> A compromise could be to switch on the custom build step only for 
>> shelling out a new release viewer, and to leave it out while GUI 
>> elements are being developed. I don't foresee a lot of problems/bugs 
>> that could occur only because of that step, because once established 
>> it runs automatic, same as with Bison for the script compiler. I find 
>> it hard to imagine that anyone would prefer to have that ditched as 
>> well for a data driven approach?
>
> I would.
below *

>
> I guess you didn't catch that when I say I routinely provide changes 
> to the XML files for people to use, that's not limited to "first look" 
> or "production", these are needed in all viewer. These have nothing to 
> do with whether the viewer is in production or not, or whether one is 
> a developer or not, they have to do with the fact that people have 
> different preferences as to how they want the user interface of the 
> browser to operate, and these files give them the ability to satisfy 
> many of them without being a developer.
Think I did, and replied that it would still be possible with an 
overlay. Only that you could as well live without if you had a 
monolithic viewer with built-in defaults.

Anyway, I can see why there is a lot of opposition to what I thought, 
and won't trample on everybody's nerves by keeping to ride on it. 
Throwing my 2 cents and learning where the flow goes was the purpose.

>
>> Although this would enable the possibility to hook up any programming 
>> language with the script engine by finding a way to describe how it 
>> is to be translated into bytecode (current or mono).
>
> This part of your comment I don't understand. What does the scripting 
> language in-world have to do with the viewer user interface?
*  - Because the script compiler is part of the viewer. This was my "I 
would", or rather "would I?". Sounded like a nutty idea or science 
fiction at first, but it would consequently follow the path of moving 
intelligence out of code and into data. If you had something that takes 
a description of the scripting language of your choice and translates it 
into bytecode, like a bison input file or a more modern XML version of 
that, then this would be a loadable component as well. The complexity of 
such a thing may be toenail-curling though.

>
>> The main point of this now is to shed light on the distinction 
>> between what is/should be flexible for the developer for reaching a 
>> better work economy, and what is/should be mutable/immutable to the 
>> end user or "light developer" (i.e. skinning, customizing the surface 
>> only).
>
> Ideally the entire user interface should be implemented completely in 
> a scripting language (Javascript, Lua, Tcl, Python, etc) with only the 
> actual "in-world" part implemented in a compiled language at all. This 
> should improve the reliability of the viewer, because it would reduce 
> the amount of code that is subject to buffer overflows, null pointers, 
> wild pointers, memory management problems, and so on, because there 
> are many many more eyes looking for these problems in the scripting 
> language runtime.
Yes that would be awesome. Actually, if the mention of X finds any 
friends, then this would mean that anything goes. We wouldn't even have 
to dictate which language to use for the UI. Apart from the selection 
you mentioned, XUL or Java anyone? Or a compiled app again based on Qt 
or wxWidgets or JUCE? Everyone as they like.

>
>
>> I don't think there's an argument that there has to be a certain core 
>> which the user is not to touch, and that strictly ought to be 
>> developed with the goal of stability.
>
> Yes, there is an argument there.
>
> The user should have access to everything in the viewer user interface 
> where it does not impact performance.
>
Well at least between you and me, nope, no argument at all. As you say 
"where it does not impact performance", that's where to draw the line 
between the core and the rest. What exactly that comprises though, at 
least so it seems to me, is not exactly finalized yet. Without such a 
clear layout it's difficult to know what to do about refactoring. Others 
have expressed it before that they wouldn't even know where to start.