Consistency in The Negative Result Values Through Expansion of null's Role

Erik Reppen erik.reppen at gmail.com
Wed Aug 15 18:11:26 PDT 2012


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 <bruant.d at gmail.com> 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 <erik.reppen at gmail.com
> >>> <mailto:erik.reppen at gmail.com>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120815/bdb9c056/attachment-0001.html>


More information about the es-discuss mailing list