<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 24, 2012, at 1:28 PM, Brendan Eich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Douglas Crockford wrote:<br><blockquote type="cite">On 4/23/2012 6:41 PM, Mark S. Miller wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On Mon, Apr 23, 2012 at 6:30 PM, Allen Wirfs-Brock<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a> <<a href="mailto:allen@wirfs-brock.com">mailto:allen@wirfs-brock.com</a>>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    The point is that much of what is done on the web is not high<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    integrity computation. It is essential that high integrity be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    possible, when it is required. But forcing all computation into the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    high integrity category seems like as bad an idea as forcing all<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    computation to be low integrity.  I really wonder how successful JS<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">    would have been if it had started out as a high integrity language.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Yes, I think that's a good point.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">No, that is not a good point. The strange ascendance of JS can best be described as miraculous. It succeed despite its low integrity, not because of it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Our problem is not to figure out how to make this language popular. We have somehow already managed that through amazing luck.<br></blockquote><br><a href="http://www.imdb.com/title/tt0076759/quotes?qt=qt0440727">http://www.imdb.com/title/tt0076759/quotes?qt=qt0440727</a><br><br><blockquote type="cite">I think our problem now is to disarm the array of toeguns while minimizing breakage as much as possible, and to avoid installing new toeguns. I think a focus on high integrity gives us a useful discipline.<br></blockquote><br>Of course we'll never know, but I've argued something I *do* know: I made JS mutable by default (all objects, almost all properties safe constructor.prototype and perhaps some DOM ones) in 1995 because I knew developers would have to monkey-patch it right away. I was counting on that non-miracle to help save it.<br></div></blockquote><br></div><div>Back to the original point, which was that making strict mode delete throw when applied to a non-configurable property is not significantly higher integrity than the non-strict behavior of returning false when a property can not be deleted.  <a href="http://www.flickr.com/photos/steffmac/5733303422/lightbox/">http://www.flickr.com/photos/steffmac/5733303422/lightbox/</a> </div><div><br></div><div>Anton reported that this delete throw was one of the two strict mode features that caused him some difficult in switching to string mode.  I suggested that we might consider removing the delete throw behavior from strict mode.  No body has comment on that specific idea.</div><div><br></div><div>Allen</div><div><br></div><br></body></html>