Helping to find the usefulness of a proposal

[Marek Kozieł]

2009/4/2 Joe Darcy <Joe.Darcy at sun.com>:
> 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
>
>
>

YES I do make mistakes.
You already said that.

  While I'm against splitting Java into more languages, I'll be happy
even if one proposal will make Java better and more frendly.
  So if you think that i didn't helped at all then remove me from the group.

-- 
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/