Re: Constraints 2014 new slides

On 3/27/14 3:06 PM, Jim Barnett wrote:
> I would also like to clarify my earlier point on the simplicity of 
> syntax.  It's very much a matter of personal taste.  I was raised on 
> LISP and find nested structures quite intuitive, while I dislike 
> syntaxes that have semantically distinct concepts at the same level - 
> so "width" and "require" are at the same level in the dictionary yet 
> mean very different things.  I don't expect others to share my tastes, 
> but I don't  think that there is a fact of the matter as to which of 
> the proposals is simpler.

I appreciate that, I have likes and dislikes as well that guide me at times.

But you probably had a LISP compiler growing up, and you weren't just 
writing lisp-like structures of your own kind, you were actually writing 
LISP, because it compiled!

I'm wide open to tastes about where the "require" member is most 
meaningful to people, as long as it is valid. The current spec was never 
valid, and still isn't.

To the people who say that doesn't matter: imagine discussing c++ with 
someone without a c++ compiler.

.: Jan-Ivar :.

>
> - Jim
>
> On 3/27/2014 2:54 PM, Jan-Ivar Bruaroey wrote:
>> On 3/27/14 2:30 PM, Jim Barnett wrote:
>>> This all will be aired on the call, but let me agree with ekr for 
>>> the record.  I don't see how this new proposal is an improvement on 
>>> the existing one.  It is less powerful (can't couple constraints, 
>>> only limited back-off),
>>
>> I included a slide with your requirements in the new slide deck, so 
>> hopefully we can discuss them if there is time.
>>
>> I think that is generous given how the language of those requirements 
>> skews to the current spec (steeped in its language at least), and it 
>> is obviously written in hindsight. It doesn't look like the kind of 
>> requirements I would expect to see ahead of a project.
>>
>> For instance, what you call "back-off", I might turn around and call 
>> "preference", like "I prefer higher frameRates over lower ones". 
>> True, the syntax is more limited in that you can't say "if I can't 
>> have a boat then I want cake",  but people may view that as a win. I 
>> think some would say we went overkill here a long time ago.
>>
>>> and to my eye the syntax more confusing.  We have an existing 
>>> proposal that has been through a lot of discussion and we should not 
>>> change it without very good reason, particularly if we want to get 
>>> done this decade.
>>
>> I think the faster path is to avoid inventing odd non-WebIDL APIs. 
>> The sooner we stop innovating in this space, and use boring WebIDL, 
>> the sooner we can get back to our core mission.
>>
>> .: Jan-Ivar :.
>>
>
> -- 
> Jim Barnett
> Genesys


-- 
.: Jan-Ivar :.