Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .... .

Dear John B.,

   Thank you for taking the time to share your views.
We differ on many of the points you have raised.
I have to teach some classes for now, but I will try
to respond to the most substantive difference this evening.

   Regards,
     Herbert

=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

On Tue, 22 Feb 2011, Bollinger, John C wrote:

> Dear Herbert,
> On Monday, February 21, 2011 6:10 PM, You wrote:
>>   I am sorry you feel that responding to the comments speaking
>> to the purpose of Ralf's proposal, even Ralf's explicitly
>> stated purpose in making the proposal, is not relevant to the
>> discussion.
>
> I think you misunderstood me.  Ralf's, John W.'s, and your comments were certainly relevant to the question of which elide proposal to adopt.  They have been stated and heard, however, whether those who found them unpersuasive responded directly or not.  In fact, it appears that at least some of those points *have* been directly addressed, but everyone who voted thereby responded indirectly.
>
> The immediate question is whether the previous discussion of proposal P in this group has adequately satisfied COMCIFS's responsibility to give due consideration to those questions properly brought before it.  It has.  It is not helpful to reopen the discussion now, in the wake of a vote unfavorable to P, apparently on the assumption that voters who did not support P must not have known or understood the arguments in favor of it.
>
>>  Fortunately, Simon was kind enough to provide
>> a substantive response, but if you do have some other thoughts on
>> those issues, I still would appreciate knowing them.
>
> Very well.  My attempts to forestall reopening the discussion having failed, I will summarize my position on these questions:
>
>>> "such informal
>>> descriptions are never as reliable as an actual implementation,
>>> in particular one that's been around for many years and is used
>>> by millions of people."  (Ralf)
>
> Indeed, Python's own documentation does not completely agree with its implementation, at least in that Python reports syntax errors on some string literals that comply with its documented lexical definitions and accompanying descriptive text.  However, I don't interpret that as an implementation being more reliable, but rather as implementations being *un*reliable.
>
> I think Ralf's concern can fairly be restated as "human-language descriptions are open to differing interpretations, but a computer program encodes all the details."  Fine.  Let us then plan for the CIF 2.0 specification to include a *formal* definition of the string literal syntax, in regex or BNF form.  That will essentially constitute a computer program implementing the syntax.
>
> It is a good and common practice for standards bodies to sanction or even to provide a reference implementation of each standard.  In some circles, there must be at least two independent implementations of a specification before it can be accepted as a standard.  However, that in no way replaces a technical specification.  Indeed, if we reject the possibility or utility of formal specifications, then what are we doing here?  Developing such specifications is this subcommittee's primary mandate.
>
>>>   "meaningful adoption of DDLm/CIF2 will require embracing
>>> and leveraging existing technologies as much as possible." (John W.)
>
> John provides no foundation for this rather abstract assertion, and no guidance on how he supposes it applies to CIF and DDLm, except that he apparently believed at that time that it favored proposal P.  In fact, proposal P will not ease CIF2 or DDLm adoption among developers in general, and perhaps not even among Python developers, because it will be more complicated to implement and adequately test than any of the other alternatives we have considered.  I see no reason to believe that it will ease adoption among CIF authors, either, because most of them are not Python initiates and thus Python syntax is not within their current sphere.  On the contrary, as we have already discussed, proposal P holds more nasty surprises for CIF authors familiar with CIF 1.1 and the IUCr elides than does any other proposal we have considered.  I would expect that to hinder adoption rather than help it.
>
>>> "I find it [counter-intuitive] and unproductive to adopt something
>>> that looks very much like the python treble quoted
>>> string but which follows confusingly different rules." (HJB)
>
> I know you have a working familiarity with many computer languages.  How many of them share identical string literal syntax?  Very few, I daresay.  Indeed, look just at Python: Python 3's triple-quote syntax and even semantics differ from Python 2's.  Similar-looking but different syntax is a fact of computing life.  Moreover, the only people who stand a chance of being confused on these grounds are Python programmers, but as programmers they should be reasonably prepared.  If you reject that, however, then you should consider how the differences between Python 2 and Python 3 string literals make this a particularly inopportune time to adopt features wholesale from either one: whichever we chose, the other would provide for confusion.
>
>
> Regards,
>
> John
>
> --
> John C. Bollinger, Ph.D.
> Department of Structural Biology
> St. Jude Children's Research Hospital
>
>
>
> Email Disclaimer:  www.stjude.org/emaildisclaimer
>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links