[147494] in cryptography@c2.net mail archive
Re: [Cryptography] encoding formats should not be committee'ized
daemon@ATHENA.MIT.EDU (Watson Ladd)
Fri Oct 4 09:54:54 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAHWD2rKF2twH6HSioMqtd9ygeV3GrsBandZis+_ffOmO=4pOYg@mail.gmail.com>
Date: Thu, 3 Oct 2013 19:00:37 -0700
From: Watson Ladd <watsonbladd@gmail.com>
To: =?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl>
Cc: Jerry Leichter <leichter@lrw.com>, cryptography <cryptography@metzdowd.com>,
Stephan Neuhaus <stephan.neuhaus@tik.ee.ethz.ch>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6684714237091458076==
Content-Type: multipart/alternative; boundary=f46d043890872d955404e7e0abdb
--f46d043890872d955404e7e0abdb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 3, 2013 at 1:35 PM, Lodewijk andr=C3=A9 de la porte <l@odewijk.=
nl>wrote:
> IMO readability is very hard to measure. Likely things being where you
> expect them to be, with minimal confusing characters but clear "anchoring=
"
> so you can start reading from anywhere.
>
> If someone could write a generative meta-language we can then ask people
> to do "text comprehension" tasks on the packed data. The relative speeds =
of
> completing those tasks should provide a measure of readability.
>
> I don't like anyone arguing about differences in readability without such
> empirical data. (it's all pretty similar unless you design against it I
> guess)
>
> XML is actually surprisingly readable. JSON is a lot more minimal. I find
> its restrictions frustrating and prefer using real JAVASCRIPT OBJECT
> NOTATION wherever possible, like INCLUDING FUNCTIONS and INCLUDING 'THIS'
> REFERENCES. Harder on parses, but why would you write your own anyway? (N=
o,
> your language is not archaic/hipster enough not to have a parser for a
> popular notational format!)
>
What part of the Chomsky hierarchy do you not understand?
What part of running computations on untrusted data which amount to Turing
machines sounds like a good idea? The trivial DDOS, or the oh-so-amusing
use as part of a distributed computing service?
What dangers of multipass computation on potentially ambiguous data do you
think are worth the extra connivence?
And let's not forget the bugs that context-sensitive grammars invite.
>
> I think that's the most useful I have to say on the subject.
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--f46d043890872d955404e7e0abdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Oct 3, 2013 at 1:35 PM, Lodewijk andr=C3=A9 de la porte <sp=
an dir=3D"ltr"><<a href=3D"mailto:l@odewijk.nl" target=3D"_blank">l@odew=
ijk.nl</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">IMO readability is very har=
d to measure. Likely things being where you expect them to be, with minimal=
confusing characters but clear "anchoring" so you can start read=
ing from anywhere.<div>
<br></div>
<div>If someone could write a generative meta-language we can then ask peop=
le to do "text comprehension" tasks on the packed data. The relat=
ive speeds of completing those tasks should provide a measure of readabilit=
y.</div>
<div><br></div><div>I don't like anyone arguing about differences in re=
adability without such empirical data. (it's all pretty similar unless =
you design against it I guess)</div><div><br></div><div>XML is actually sur=
prisingly readable. JSON is a lot more minimal. I find its restrictions fru=
strating and prefer using real JAVASCRIPT OBJECT NOTATION wherever possible=
, like INCLUDING FUNCTIONS and INCLUDING 'THIS' REFERENCES. Harder =
on parses, but why would you write your own anyway? (No, your language is n=
ot archaic/hipster enough not to have a parser for a popular notational for=
mat!)</div>
</div></blockquote><div>What part of the Chomsky hierarchy do you not under=
stand?</div><div>What part of running computations on untrusted data which =
amount to Turing machines sounds like a good idea? The trivial DDOS, or the=
oh-so-amusing use as part of a distributed computing service?</div>
<div>What dangers of multipass computation on potentially ambiguous data do=
you think are worth the extra connivence?</div><div>And let's not forg=
et the bugs that context-sensitive grammars invite.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr">
<div><br></div><div>I think that's the most useful I have to say on the=
subject.</div></div>
<br>_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com" target=3D"_blank">cryptography=
@metzdowd.com</a><br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br></blo=
ckquote></div><br></div></div>
--f46d043890872d955404e7e0abdb--
--===============6684714237091458076==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============6684714237091458076==--
