Helping to find the usefulness of a proposal

Reinier Zwitserloot reinier at zwitserloot.com
Thu Apr 2 08:18:25 PDT 2009


Polling has many, many problems associated with it:

1. It does not reliably measure impact. Let's say generics gets a 9.0  
in the polls, and the foreach loop gets only an 8.0. The right answer  
is to implement foreach, eventhough it scored lower. It's easier and  
has less impact. implementing difficulty can be decided by an expert  
group, but there's also the concept of impact.

A nice case in point: Almost everyone rated operator support for  
BigDecimal and BigInteger as very low in Stephen Colebourne's polls,  
but is that reflective? I don't think so. It's just the one with the  
lowest impact - no body cares about that a lot, and some care about it  
not at all. It is, however, hard to see how operator support for  
BigDecimal/BigInteger can break, well, anything. The value of any  
proposal is its positive impact divided by its negative impact, and  
dividing by a very small number gives you a very large number.

2. Not all know about intricacies. For example, with generics, I bet  
many who vocally supported them did not know the details about  
reification, the sheer complexity of co/contra-variance (which just  
cannot be simplified, the core concept is difficult, period),  
etcetera.  By not being aware of the weight put on future expansions  
and patchy stopgaps in the proposal itself, some proposals that are  
technically (but not obviously) complex get an unfairly inflated poll  
score.



Perhaps a fairer way would be to first reduce the list to a manageable  
number, and then to poll, but only amongst those who have attempted to  
read and fully grok all proposals on the list, and can be expected to  
know enough repercussions to make a fair analysis, and to poll not  
just on 'how much would you like this in java?' but also on 'how much  
would you NOT like this in java?' - in order to give the simpler stuff  
like e.g. operators for BigDecimal/Integer a fighting chance. How do  
you determine that someone is both skilled enough to understand AND  
has attempted to grok all proposals on the short-list? I have no idea.


  --Reinier Zwitserloot



On Apr 2, 2009, at 15:10, rssh at gradsoft.com.ua wrote:

>
>
> Yes, yet one idea - create poll, where each proposal is listed  with  
> link
> and rated from -5 to 5
> // -5 - I strongly against this in Java; +5 - I strongly for; 0 -  
> neutral.
> (by default all is null))  and publish somewhere.
> // better different instances for controlled and non-controlled  
> auditory.
>
> It will be interesting.
>
>
>
>> 2009/4/2 Stephen Colebourne <scolebourne at joda.org>:
>>> All,
>>> One possible way I'd like to suggest that the coin evaluation  
>>> could be
>>> helped would be to write a script to find out how frequently the
>>> specific issue comes up in real code.
>>>
>>> It should be possible to devise, write and run a script to find the
>>> number of LOCs affected by many of the proposals. For example:
>>>
>>> - strings in switch (find if else on constant strings)
>>> - multi-catch (find duplicate catch blocks)
>>> - elvis operator (find ternary and if else defaulting)
>>> - for each where the iterator remove can be accessed (% of loops  
>>> that
>>> access iterator)
>>> - for each where index is needed (% of loops that use int looping)
>>> - method and field literals
>>> - byte and short literals
>>> and probably many others (I've just listed some proposals I  
>>> remember)
>>>
>>> Ideally, any script would be ASM/BCEL based, but grep style might  
>>> work
>>> too.
>>>
>>> I mention all this because I don't have the spare time to write  
>>> such a
>>> script, but if you do, then I'm sure we'd all like to run it and
>>> discuss the results ;-)
>>>
>>> Stephen
>>>
>>>
>>
>> We may list all proposals and write opinions & statistics (as we  
>> think).
>>
>> --
>> Pozdrowionka. / Regards.
>> Lasu aka Marek Kozieе┌
>>
>> http://lasu2string.blogspot.com/
>>
>>
>
>
>




More information about the coin-dev mailing list