Helping to find the usefulness of a proposal
Joe.Darcy at Sun.COM
Thu Apr 2 12:48:54 PDT 2009
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:
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.
> 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:
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:
> (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
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.
More information about the coin-dev