Helping to find the usefulness of a proposal

Thu Apr 2 09:09:28 PDT 2009

> Polling has many, many problems associated with it:
>

 yes.  But we have no other ways to know 'meaning of mass'. I. e. 'design
by poll' is not good idea, but 'design without any information from real
word' is not good idea also.

It's well-known problem in sociology, where, unlike computer science, we
 have no correct instruments at all. Exists some 'non-direct' ways
 to know how correct is poll: controlled auditories, same poll in different
cases, but all this is not panacea.

> 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.
>

 Yes. I think all understand this.
// btw, near all proposals in project coin are easy implementable.

> 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.
>

I also have question to Stephen polls: i. e. I can't understand why
multiline strings rated so low.  Anybody, who works with databases
 know, that analyzing query plan or copy non-trivial query test
 in java is a big pain, and most of Java project in corporate sector use 
non-trivial sql queris".
  Only one answer, which I can suggest - that auditory which attend Java
conferences does not reflect auditory of Java users: most of Java
conferences attenders do system programming or research and have nothing
with most of  database projects which is not so interesting and rare
have academics interest.
  To verify this, possible repeat his poll on some programmer event, which
is not so academics.

> 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.
>

Filtration by proposal size, as I know, already was done.

>
>
> 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

 Or just does not touch proposals, which was not readed.
(mark as 0, 'neutral')

> 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

 Yes.

> 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.
>

'Skilled enough', sorry, I think that people, which skilled enough prefer
haskell and will poll for haskell-like features, which is not ordinary
Java programmer want ;)

Also will be wery interested difference between this audience (subscribers
of the list) and general audience of Java programmers.

Note, that I does not propose use polls as one and only one criteria. I
just tell that see result of such poll will be interest.

// btw - from other side, all this activity is overkill, I can suggest,
// that  accepted proposals would be exactly same, which was listed in
// project-coin description (before coin was started)
//     http://blogs.sun.com/darcy/entry/project_coin
//   +ARM  +jsr292  and ...  it's already 6, which is more than 5 :)

I. e. doing project coin with external auditory  was a 'Sun system error',
I guess; if they want some feedback from community, correct way was at
first implement own stuff, than ask community for something new ;)

>
>   --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/
>>>
>>>
>>
>>
>>
>
>