Context and expectations

Debasish Ray Chawdhuri debasish.raychawdhuri at gmail.com
Thu Jul 19 16:52:52 PDT 2012


I would agree with David in this matter, and in face I think we did have a
constructive discussion.

On Fri, Jul 20, 2012 at 4:35 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> I certainly hope that this isn't directed at me, as my post specifically
> calls out the correctness and validity of the requirements, including a
> suggestion for a better idea as an illustration of the weakness of the
> requirement, and did not include any insults or anger, especially towards
> individuals; though it's hard to draw any other conclusion given how rarely
> anyone posts to the jigsaw list from outside of Oracle.
>
> As I've often said in ##java, politeness is always defined in the context
> of one's local culture.  As for me, I'd rather have someone directly say
> "your idea is wrong and here's why" if they feel they have a strong
> argument.  Rejecting discussion that *you* find impolite *because* you find
> it impolite is a very insular attitude, and doesn't work well in the
> greater community which is often far less culturally homogeneous than
> corporations tend to be.  Remember Postel's law.  It's far more productive
> to consider the actual content of the message and reply in good faith -
> only if a message has no valid content is the "bozo" bit in scope.
>
> Also, this isn't Congress, it's a public forum - once a question is
> "answered", it is not "closed" especially if it relates directly to the
> validity of requirements or the efficacy of an implementation decision.  If
> you don't allow direct criticism of requirements, the definition and
> understanding of which are the basis of any good software, you've cut off
> pretty much all meaningful input from the community, which would make this
> whole exercise a sham; I'm continuing to give the benefit of the doubt on
> that point, which is why I keep on trying to work with the Jigsaw team.
>
> I do think it is clear that many of the requirements in the requirements
> document are implementation directives, and I believe this is a poor way to
> design software.  Implementation directives are *derived* from
> requirements, which in turn are guided by real-world use cases.  For each
> such directive, one must ask, what is the *real* requirement that
> precipitated it?  Chances are there is a very good reason that it seemed
> necessary to give such a directive; but it's the underlying requirement
> that has to be identified, because chances are also very good that there
> are other options to meet it which may be superior (or may not be).  One of
> the key strengths, in my opinion, of Open Source Software is recognition of
> this basic humility and the opportunity it presents for us to create
> software greater than we ourselves would be capable of.
>
> You (and by "you" I mean "all of us in this business") have to be able to
> question your own perspective and accept outside views, and yes this *does*
> mean calling into question your own motivations, *constantly*. Is a
> requirement there because it specifically solves a known problem or use
> case, or because it's just something you want?  Is there a better or more
> concise way to express this requirement?  The answer to these questions can
> mean the difference between good and bad software.  Often times we *want*
> something because of an intuitive understanding of the problem - but these
> things still *must* be expanded and codified, because they nearly always
> contain weaknesses and prejudices (we all have them; stature or experience
> level is no guarantee against this).
>
> So yes, you could say that I question your motivations, because that's a
> responsibility incumbent upon anyone who evaluates requirements gathered by
> another.  It's nothing personal, it's just good engineering.
>
>
> On 07/19/2012 05:12 PM, mark.reinhold at oracle.com wrote:
>
>> To quote from the Project Jigsaw main page [1]:
>>
>>    The goal of this Project is to design and implement a standard
>>    module system for the Java SE Platform, and to apply that system
>>    to the Platform itself and to the JDK.
>>
>>    Right now this effort is in an exploratory phase in which we are
>>    investigating and prototyping various ideas in the context of an
>>    in-progress requirements document.  That document, together with
>>    the overall Jigsaw design, will be among the starting points of
>>    an eventual Java Platform Module System JSR.
>>
>> That page also contains pointers to additional working and background
>> documents.  The most important of those are the requirements [2] and
>> the "big picture" overview [3], which together describe the context
>> of the design and development work taking place on this list.
>>
>> Please make sure you're familiar with that context before you post to
>> this list.  If you don't agree with it, that's fine -- ask questions.
>> If you have a better idea, that's great -- please suggest it.
>>
>> Do not expect, however, that asking questions that've already been
>> answered, attacking the motivations or intelligence of those of us
>> who've been working on this for a long time, casting insults, getting
>> angry, or otherwise behaving impolitely will have any effect other
>> than to set your bozo bit.
>>
>> - Mark
>>
>>
>> [1] http://openjdk.java.net/**projects/jigsaw/<http://openjdk.java.net/projects/jigsaw/>
>> [2] http://openjdk.java.net/**projects/jigsaw/doc/draft-**
>> java-module-system-**requirements-12<http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12>
>> [3] http://cr.openjdk.java.net/~**mr/jigsaw/notes/jigsaw-big-**picture-01<http://cr.openjdk.java.net/%7Emr/jigsaw/notes/jigsaw-big-picture-01>
>>
>
>
> --
> - DML
>



-- 
Debasish Ray Chawdhuri
http://www.geekyarticles.com/
[A collection of advanced articles on java]



More information about the jigsaw-dev mailing list