[147491] in cryptography@c2.net mail archive
Re: [Cryptography] encoding formats should not be committee'ized
daemon@ATHENA.MIT.EDU (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_l)
Thu Oct 3 21:30:43 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <524D9771.10607@tik.ee.ethz.ch>
From: =?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl>
Date: Thu, 3 Oct 2013 22:35:55 +0200
To: Stephan Neuhaus <stephan.neuhaus@tik.ee.ethz.ch>
Cc: Jerry Leichter <leichter@lrw.com>, cryptography <cryptography@metzdowd.com>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7556916577699055139==
Content-Type: multipart/alternative; boundary=047d7b41ccf82d232104e7dc238c
--047d7b41ccf82d232104e7dc238c
Content-Type: text/plain; charset=UTF-8
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? (No,
your language is not archaic/hipster enough not to have a parser for a
popular notational format!)
I think that's the most useful I have to say on the subject.
--047d7b41ccf82d232104e7dc238c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">IMO readability is very hard to measure. Likely things bei=
ng where you expect them to be, with minimal confusing characters but clear=
"anchoring" so you can start reading from anywhere.<div><br></di=
v>
<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><br></div><div>I think that's the most useful I have to say on the=
subject.</div></div>
--047d7b41ccf82d232104e7dc238c--
--===============7556916577699055139==
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
--===============7556916577699055139==--
