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