- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 28 Mar 2012 01:47:57 -0700
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. OK. > 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 little-endian behavior. -Boris
Received on Wednesday, 28 March 2012 01:47:57 UTC