Helping to find the usefulness of a proposal

[Joe Darcy]

On 04/02/09 09:09 AM, rssh at gradsoft.com.ua wrote:
>> 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.
>   

I do not share that opinion.

There are no simple language changes in Java.

Given the relative scarcity of prototypes, to say nothing of prototypes 
with a thorough test suite, we can at best make informed estimates of 
the difficulty of various changes, but I'm certain there will be 
surprises down the line, as there were for every JDK 5 language change.

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

On this point, I've long thought the Java platform is like the elephant 
in the parable about the blind men and the elephant:

    http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant

That is, while each of us may know and understand our own usage of Java 
quite and well and have valid ideas about how Java could be changed to 
improve programming in our own areas of interest (properties! operator 
overloading! design by contract!  your favorite feature!), evolving the 
platform  with an eye toward optimizing it *as a whole* will  mean at 
least some areas don't get what they want.

[snip]

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

Your own sentence disproves your point since ARM was not listed among 
the five proposal areas under consideration before Project Coin started.

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

The call of proposal phase of Project Coin is an effort both to solicit 
feedback from the external community and also to invite the external 
community to participate more directly in evolving the language.  That 
opportunity to participate also implies participating in the large 
amount of work required to go from "I have this great idea!" to "I have 
this great idea and here is a carefully considered review of all the 
implications of the idea, along with a prototype."  The blogs I wrote 
last year and the proposal form itself are part of an effort to explain 
and expose what this language work entails so more people can get involved.

Unfortunately, many of the submitted proposals did not do a credible job 
of analyzing the true effect the proposal would have, which has a rather 
strong relation to why many were not chosen for further consideration.  
For example, let's take the "'This' type" proposal:

    http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000107.html

Including a this type/self type notion in a programming language type 
system is a well-studied problem in type systems; as I sent to the list, 
papers continue to be written on this topic in the programming language 
literature.  It known to *not* be a simple change to the type system.    
Let's look at the specification section of the proposal:

> SPECIFICATION:
> (I did not have time to analyze this completely.)
>   

The analysis is the part that matters most!  This proposal appears 
completely oblivious to and ignorant of the large amount of prior work 
on this topic.

It is not as if the notion of adding a self type to Java is a new idea; 
there is already a Sun bug for this from several years ago:

    6479372 Add self types (type of 'this' aka ThisClass) to the language
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6479372

So in total, this "proposal" added *nothing* to the understanding of 
what adding a this type to Java would mean and how the change could be done.

Those factors weighed quite strongly in why this particular proposal did 
not more on to "for further consideration."

Language design, especially additions to an existing language, is not an 
endeavor where enthusiasm can overcome lack of diligence and expertise.

-Joe