Well I went a bit long as I tend to when geeking out on stuff but I think the topic of how these elements of the language could be used better moving forward if we're stuck with 'em is interesting. I really do find it's helpful in debug to have different ways of saying 'fail.'
With these new JIT interpreters moving as fast as they are, I wonder if it wouldn't be completely ridiculous to eventually attempt to handle multiple versions of JS. It seems like handling multiple HTML doctypes became completely unworkable for a lot of reasons I've only started to understand, however, so I'm not sure how naive of an idea that is. What I love about JS is that anything you don't like, you can bend fold, mutilate, and warp into a shape that you do. That's why I'm a bit puzzled by the popularity of the compile-down approaches. On Wed, Aug 15, 2012 at 7:15 PM, David Bruant <[email protected]> wrote: > Le 16/08/2012 01:31, Brendan Eich a écrit : > > David Bruant wrote: > >> Le 16/08/2012 00:35, Rick Waldron a écrit : > >>> On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> > >>> Is consistent type return a heuristic carried over from more > >>> strictly-typed paradigms or would it murder performance of the > >>> native methods to do the logic required to return something like > >>> null in these cases? In a dynamic language, why not focus on more > >>> consistent return types across the board for an indicator that > >>> you won't be getting particularly handy results? > >>> > >>> > >>> It would break the web. > >> I agree and would like to encourage you (Erik) to read the foreword > >> of my "ECMAScript regrets" project > >> https://github.com/DavidBruant/ECMAScript-regrets#foreword > >> > >> The only way forward to "fix" broken parts of JavaScript (like making > >> it more consistent) is to give up on JavaScript and create a new > >> language that compiles down to JavaScript. That's my opinion at least. > > > > There's another way: extend JS with fixed forms and hope the broken > > ones die eventually. > I agree, but "hope" hasn't given the web a lot so far unfortunately. > > Also, it should work fine for syntax, but built-in libraries (like what > Erik wants to see fixed) seem to be a different story. For instance, > Number.isNaN is a fixed form, but I'm not sure it'll be enough to see > isNaN die. > > > Both compile-to-JS and evolve-JS-to-be-better are happening, and the > > former informs the latter directly (=> and for-of from CoffeeScript > > are in ES6, e.g.). Both should, since JS is at this point a huge > > public good, like it or not. > I could not agree more. > > David >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
