[whatwg] Endianness of typed arrays
bzbarsky at MIT.EDU
Wed Mar 28 01:47:57 PDT 2012
On 3/28/12 1:14 AM, Charles Pritchard wrote:
> Most developers work with multiple programming languages. They read
> manuals, they read blogs, they try things out, and then they often code
> more in other languages than in JS.
Are you sure this is true for most developers creating web content?
> But those that endeavor to make quality games and demos do try to
> consume as much as they can.
See, at this point people are using typed arrays for a lot more than
"games and demos". I will make no judgement about "quality".
> I don't want to be in this kind of conversation with you nor Robert.
I honestly don't want to be in this conversation either, all that much.
But I think the current state of the typed array specification is
actively bad for the web, and I sort of care about that sort of thing.
> Your statements of fact are fine.
> Your claim that "developers ... just do whatever" is toxic.
My claim is that developers do "what works", not "whatever".
And I can totally understand where they're coming from, by the way.
They just want something to work. They read several tutorials on the
subject, they write the code, they test it in a browser, if they're
conscientious they test it in several browsers. Everything seems to be
working fine, so they deploy. At no point in that does reading the spec
per se enter the picture. The spec is typically written to target
_implementors_, not developers, and it shows. It's near impossible to
get useful information out of it, as a developer. This is true for
specs in general, not just the typed array spec.
This is not limited to web developers, by the way. How many C or C++
developers really read the C or C++ spec and then write code that
follows the spec to the letter? Precious few, in my experience, for the
same reasons: the specs are targeted at compiler implementors, not
developers. I say this as a C/C++ developer but not a compiler
implementor. ;) And even ones who do read the spec then proceed to
write code that doesn't follow the spec, and feel that this is fine
because their core works OK on their target architectures. As a result,
finding a C program that doesn't rely on undefined behavior takes some
doing. It's the same dynamic at work: code is written, compiled with a
particular compiler (or small set of compilers) for a particular
architecture or small set of architectures, tested, then shipped. The
number of C programs assuming that there are 8 bits in an unsigned char
is ... large, for example. Likewise for the number of C programs
assuming that (int)0xFFFFFFFF == -1. Or that INT_MAX+1==INT_MIN. Or
that you can cast between function pointers, or cast a function pointer
to void*, or any of a huge number of other things. And the world still
works, more or less ok.
What I don't understand is why you think that keeping this reality in
mind is "toxic".
> When you or Robert disparage developers as a class, that is harmful.
I'm not disparaging developers; I'm saying that the way things are right
now developers are assuming typed arrays are little-endian and that this
makes total sense. If I were writing code using typed arays, I'd
probably do the same. The cost-benefit tradeoff to those developers is
that the cost of trying to support big-endian typed arrays is decidedly
nonzero while the benefit is very close to zero, if not identically
zero. So they don't support the big-endian stuff, just like Gecko
doesn't work correctly on hardware with 32-bit unsigned chars or
hardware with 16-bit ints.
If you think these developers are somehow being "bad" by making this
cost-benefit analysis, then _you_ are doing the disparaging. I think
they're just being rational. And if we (members of this mailing list,
the WebGL working group, tech evangelists, whatever) started berating
them for not testing endianness, which is what you seem to be proposing,
they would rightfully tell us that we're full of it. Several of the
presenters at SXSW explicitly told me that when I mentioned the issue to
them privately after their presentations: they were quite cognizant of
the endianness issue, and had no problem whatsoever with assuming
More information about the whatwg