[147454] in cryptography@c2.net mail archive
Re: [Cryptography] encoding formats should not be committee'ized
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Oct 2 10:31:19 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <524B3BAC.20900@echeque.com>
Date: Wed, 2 Oct 2013 09:09:05 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "James A. Donald" <jamesd@echeque.com>
Cc: Jerry Leichter <leichter@lrw.com>, "Salz, Rich" <rsalz@akamai.com>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3277058604742215058==
Content-Type: multipart/alternative; boundary=001a1133c2d21c5b6e04e7c1c666
--001a1133c2d21c5b6e04e7c1c666
Content-Type: text/plain; charset=ISO-8859-1
Replying to James and John.
Yes, the early ARPANET protocols are much better than many that are in
binary formats. But the point where data encoding becomes an issue is where
you have nested structures. SMTP does not have nested structures or need
them. A lot of application protocols do.
I have seen a lot of alternatives to X.509 that don't use ASN.1 and are
better for it. But they all use nesting. And to get back on topic, the main
motive for adding binary to JSON is to support signed blobs and encrypted
blobs. Text encodings are easy to read but very difficult to specify
boundaries in without ambiguity.
Responding to James,
No, the reason for baring multiple inheritance is not that it is too
clever, it is that studies have shown that code using multiple inheritance
is much harder for other people to understand than code using single
inheritance.
The original reason multiple inheritance was added to C was to support
collections. So if you had a class A and a subclass B and wanted to have a
list of B then the way you would do it in the early versions of C++ was to
inherit from the 'list' class.
I think that approach is completely stupid, broken and wrong. It should be
possible for people to make lists or sets or bags of any class without the
author of the class providing support. Which is why C# has functional
types, List<T>.
Not incidentally, C also has functional types (or at least the ability to
implement same easily). Which is why as a post doc, having studied program
language design (Tony Hoare was my college tutor), having written a thesis
on program language design, I came to the conclusion that C was a better
language base than C++ back in the early 1990s.
I can read C++ but it takes me far longer to work out how to do something
in C++ than to actually do it in C. So I can't see where C++ is helping. It
is reducing, not improving my productivity. I know that some features of
the language have been extended/fixed since but it is far too late.
At this point it is clear that C++ is a dead end and the future of
programming languages will be based on Java, C# (and to a lesser extent
Objective C) approaches. Direct multiple inheritance will go and be
replaced by interfaces. Though with functional types, use of interfaces is
very rarely necessary.
So no, I don't equate prohibiting multiple direct inheritance with 'too
clever code'. There are good reasons to avoid multiple inheritance, both
for code maintenance and to enable the code base to be ported to more
modern languages in the future.
--001a1133c2d21c5b6e04e7c1c666
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Replying to James and John.<div><br></div><div>Yes, the ea=
rly ARPANET protocols are much better than many that are in binary formats.=
But the point where data encoding becomes an issue is where you have neste=
d structures. SMTP does not have nested structures or need them. A lot of a=
pplication protocols do.</div>
<div><br></div><div>I have seen a lot of alternatives to X.509 that don'=
;t use ASN.1 and are better for it. But they all use nesting. And to get ba=
ck on topic, the main motive for adding binary to JSON is to support signed=
blobs and encrypted blobs. Text encodings are easy to read but very diffic=
ult to specify boundaries in without ambiguity.</div>
<div><br></div><div><br></div><div>Responding to James,</div><div><br></div=
><div>No, the reason for baring multiple inheritance is not that it is too =
clever, it is that studies have shown that code using multiple inheritance =
is much harder for other people to understand than code using single inheri=
tance.=A0</div>
<div><br></div><div>The original reason multiple inheritance was added to C=
was to support collections. So if you had a class A and a subclass B and w=
anted to have a list of B then the way you would do it in the early version=
s of C++ was to inherit from the 'list' class.</div>
<div><br></div><div>I think that approach is completely stupid, broken and =
wrong. It should be possible for people to make lists or sets or bags of an=
y class without the author of the class providing support. Which is why C# =
has functional types, List<T>.</div>
<div><br></div><div>Not incidentally, C also has functional types (or at le=
ast the ability to implement same easily). Which is why as a post doc, havi=
ng studied program language design (Tony Hoare was my college tutor), havin=
g written a thesis on program language design, I came to the conclusion tha=
t C was a better language base than C++ back in the early 1990s.</div>
<div><br></div><div>I can read C++ but it takes me far longer to work out h=
ow to do something in C++ than to actually do it in C. So I can't see w=
here C++ is helping. It is reducing, not improving my productivity. I know =
that some features of the language have been extended/fixed since but it is=
far too late.</div>
<div><br></div><div>At this point it is clear that C++ is a dead end and th=
e future of programming languages will be based on Java, C# (and to a lesse=
r extent Objective C) approaches. Direct multiple inheritance will go and b=
e replaced by interfaces. Though with functional types, use of interfaces i=
s very rarely necessary.</div>
<div><br></div><div><br></div><div>So no, I don't equate prohibiting mu=
ltiple direct inheritance with 'too clever code'. There are good re=
asons to avoid multiple inheritance, both for code maintenance and to enabl=
e the code base to be ported to more modern languages in the future.</div>
</div>
--001a1133c2d21c5b6e04e7c1c666--
--===============3277058604742215058==
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
--===============3277058604742215058==--
