9 ms·

JavaScript has been in the throes of an identity crisis since its inception, and IMO we're just now starting to get to a point where developers are leveraging i

JavaScript has been in the throes of an identity crisis since its inception, and IMO we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right rather than trying to cram into a statically-typed, OOP box. To that effect, it seems like strong mode and SoundScript are a step in the wrong direction. I noticed the very deliberate and self-aware FAQ entry "Are you turning JavaScript into Java?" along with the canned denial, but that still doesn't change the fact that strong mode and SoundScript aim to remove dynamic typing and prototypes from a dynamically-typed prototypal language.

Touche 12y ago
That was a classic non-denial denial[1]. [1] http://en.wikipedia.org/wiki/Glomar_response http://en.wikipedia.org/wiki/Glomar_response
dietrichepp 12y ago
> we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right It's damning that you say it took 20 years for us to "start" to leverage JavaScript's power. Compare to C#, which appeared 15 years ago, or Go which is from 2009, or Swift, which hasn't even celebrated its first birthday yet. Better comparisons might be Python and Ruby, which are both fully dynamic and have cool metaprogramming facilities like JavaScript does, but they'll both give you hard errors when you type the equivalent of [].lenght. And they give you proper stack traces and error messages, too: none of "undefined is not a function" which took until 2015 to get fixed in Chrome (try it). Working with Node.js will make you fall into despair when you realize that your program crashes, and it has stack traces, but none of the stack frames are in your code because everything has been threaded through callbacks. Python's major implementation has serious problems with concurrency (re: the GIL, global interpreter lock) and it too has dynamic types everywhere but it's still far easier to work with. What I want is to be able to refactor a JavaScript project without feeling like I'm crossing the river Styx. Where are the call sites for this function... who knows? TypeScript seems to at least give me some of those tools, it's a shame that the tooling isn't really ready--the compiler takes ages to run (timed it at 2.0 seconds on a small project... I might as well be using C++ at those speeds). And if Google has been using TypeScript as a basis, as they say, then you can keep using JavaScript the way you want and you don't even have to type anything in differently. Just let us add some type checking if we want it.
- BrendanEich 12y ago
  Before TypeScript (fall 2012), Zef Hemel then at c9.io did static analysis for JS IDE diagnostics (mid-2012?), Dmitry Vardoulakis then grad-student-interning at Mozilla Research did DoctorJS (spring 2010, I think). And don't forget the Closure compiler from Google, but I'm not sure when that really got serious about static analysis -- perhaps after Google hired Dmitry. So no more than 15 years, not 20. ;-) What's damning is the stagnation under the IE (convicted in the US) monopoly from late '90s through 2009 when ES5 was published. It's not as if Python 1.3 or whatever, if frozen in Netscape 2 amber, would have fared better if forked.
  - dietrichepp 12y ago
    My comment about 20 years was in response to a quote from the parent comment. But yes, that's a very good point. Very few languages have ever come out of the gate close to the mark. Early C# and Java were painful without closures, iterators, function pointers, or good performance. Which is why I'm glad to see things like TypeScript, Closure, and ES6, Traceur, etc. (and I'm less excited about Coffeescript and Dart). It's especially a good sign that Google is using TypeScript as a basis because it means we might not get siloed implementations and communities.
  - lmm 12y ago
    > It's not as if Python 1.3 or whatever, if frozen in Netscape 2 amber, would have fared better if forked. Disagree. Python 1.3 was at least designed as a general-purpose programming language, with a variety of use cases, and took the best parts of existing languages (TCL and Perl) rather than having novel features that sorta-but-not-quite replace more conventional ones. It had its share of warts but nothing in Python 1.3 is as awkward as prototypal inheritance or javascript's scoping. IMO the biggest tragedy is Mozilla's unwillingness to put other languages in the browser. Dart was developed in public, far more of an open standard than the original JS, fixed language design problems that ES6 still isn't addressing, had an adequate approach to running in JS-only browsers, and would have added much less complexity to browser implementation (the reason given for rejection) than many standards that Mozilla has been happy to support.
BrendanEich 12y ago
I got tired of replying with true ES4-is-not-turning-JS-into-Java denials in 2007: https://brendaneich.com/2007/11/my-media-ajax-keynote/ https://brendaneich.com/2007/11/my-media-ajax-keynote/ /be
- ryanisinallofus 12y ago
  Aren't you against this sort of thing? "It seems to me that a lot of you "bring on our new overlords" boosters are unaware of how HTML5 came about. It was not through one vendor shipping proprietary code and standards bodies mopping up later. Study some recent history." You convinced me 1274 days ago.
  - BrendanEich 12y ago
    V8 folks promise to work with TC39 on semantics and open source the code, which helps. You're right that, worst case, this turns into another Chrome-only power play. But all signs suggest otherwise, so far. /be
- rmrfrmrf 12y ago
  ::adds "publicly spanked by Brendan Eich" to resumé:: But seriously, that article is insanely ahead of its time. Or we're progressing reeeaaally slowly. Or both.
- marrs 12y ago
  `type` and `like` seem like a really natural way to enforce interfaces in JS. What happened to those ideas?
ergothus 12y ago
I couldn't help but notice how it boiled down: Q: "Are you turning Javascript into Java?" A: "No, it's optional" That's not a strong denial, I was hoping for a more substantial response.
- ahoge 12y ago
  What does "turning into Java" even mean? What exactly are you afraid of? Having actual integers? Threads? Better tooling? The `class` keyword? It makes the code less verbose. Optional types? Would you rather write JSDoc comments? Optional typing actually works amazingly well. You need very few type annotations to get all the tooling benefits. Typically, it's enough to annotate the headers of your function. Type inference takes care of the rest.
  - Offler 12y ago
    It might be a reference to Dart?
  - ergothus 12y ago
    1) I was commenting on how they didn't answer the question. 2) JS and Java have very real differences. Turning one into the other DEFINITELY comes with consequences. Maybe you like them, maybe you don't, but it's clearly a legit question. Regarding #1: The optional part wasn't Perl6-style optional typing (which I'd be fine with), as I read it, but USING their system at all. If I teach how to juggle chainsaws, and someone says "isn't that dangerous?" and I respond "No, you don't have to do it", I've not addressed the question at all. Regarding #2: For me, it'd be threads (a simple system that is almost never painless), classes (JS today has objects but not classes, and it's a fundamental part of how it works), compilation, and most importantly typing. "Session session = Session.getSession()" is not something I enjoy typing.

Touche 12y ago

That was a classic non-denial denial[1]. [1] http://en.wikipedia.org/wiki/Glomar_response http://en.wikipedia.org/wiki/Glomar_response

dietrichepp 12y ago

> we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right It's damning that you say it took 20 years for us to "start" to leverage JavaScript's power. Compare to C#, which appeared 15 years ago, or Go which is from 2009, or Swift, which hasn't even celebrated its first birthday yet. Better comparisons might be Python and Ruby, which are both fully dynamic and have cool metaprogramming facilities like JavaScript does, but they'll both give you hard errors when you type the equivalent of [].lenght. And they give you proper stack traces and error messages, too: none of "undefined is not a function" which took until 2015 to get fixed in Chrome (try it). Working with Node.js will make you fall into despair when you realize that your program crashes, and it has stack traces, but none of the stack frames are in your code because everything has been threaded through callbacks. Python's major implementation has serious problems with concurrency (re: the GIL, global interpreter lock) and it too has dynamic types everywhere but it's still far easier to work with. What I want is to be able to refactor a JavaScript project without feeling like I'm crossing the river Styx. Where are the call sites for this function... who knows? TypeScript seems to at least give me some of those tools, it's a shame that the tooling isn't really ready--the compiler takes ages to run (timed it at 2.0 seconds on a small project... I might as well be using C++ at those speeds). And if Google has been using TypeScript as a basis, as they say, then you can keep using JavaScript the way you want and you don't even have to type anything in differently. Just let us add some type checking if we want it.

BrendanEich 12y ago
Before TypeScript (fall 2012), Zef Hemel then at c9.io did static analysis for JS IDE diagnostics (mid-2012?), Dmitry Vardoulakis then grad-student-interning at Mozilla Research did DoctorJS (spring 2010, I think). And don't forget the Closure compiler from Google, but I'm not sure when that really got serious about static analysis -- perhaps after Google hired Dmitry. So no more than 15 years, not 20. ;-) What's damning is the stagnation under the IE (convicted in the US) monopoly from late '90s through 2009 when ES5 was published. It's not as if Python 1.3 or whatever, if frozen in Netscape 2 amber, would have fared better if forked.
- dietrichepp 12y ago
  My comment about 20 years was in response to a quote from the parent comment. But yes, that's a very good point. Very few languages have ever come out of the gate close to the mark. Early C# and Java were painful without closures, iterators, function pointers, or good performance. Which is why I'm glad to see things like TypeScript, Closure, and ES6, Traceur, etc. (and I'm less excited about Coffeescript and Dart). It's especially a good sign that Google is using TypeScript as a basis because it means we might not get siloed implementations and communities.
- lmm 12y ago
  > It's not as if Python 1.3 or whatever, if frozen in Netscape 2 amber, would have fared better if forked. Disagree. Python 1.3 was at least designed as a general-purpose programming language, with a variety of use cases, and took the best parts of existing languages (TCL and Perl) rather than having novel features that sorta-but-not-quite replace more conventional ones. It had its share of warts but nothing in Python 1.3 is as awkward as prototypal inheritance or javascript's scoping. IMO the biggest tragedy is Mozilla's unwillingness to put other languages in the browser. Dart was developed in public, far more of an open standard than the original JS, fixed language design problems that ES6 still isn't addressing, had an adequate approach to running in JS-only browsers, and would have added much less complexity to browser implementation (the reason given for rejection) than many standards that Mozilla has been happy to support.

BrendanEich 12y ago

I got tired of replying with true ES4-is-not-turning-JS-into-Java denials in 2007: https://brendaneich.com/2007/11/my-media-ajax-keynote/ https://brendaneich.com/2007/11/my-media-ajax-keynote/ /be

ryanisinallofus 12y ago
Aren't you against this sort of thing? "It seems to me that a lot of you "bring on our new overlords" boosters are unaware of how HTML5 came about. It was not through one vendor shipping proprietary code and standards bodies mopping up later. Study some recent history." You convinced me 1274 days ago.
- BrendanEich 12y ago
  V8 folks promise to work with TC39 on semantics and open source the code, which helps. You're right that, worst case, this turns into another Chrome-only power play. But all signs suggest otherwise, so far. /be
rmrfrmrf 12y ago
::adds "publicly spanked by Brendan Eich" to resumé:: But seriously, that article is insanely ahead of its time. Or we're progressing reeeaaally slowly. Or both.
marrs 12y ago
`type` and `like` seem like a really natural way to enforce interfaces in JS. What happened to those ideas?

ergothus 12y ago

I couldn't help but notice how it boiled down: Q: "Are you turning Javascript into Java?" A: "No, it's optional" That's not a strong denial, I was hoping for a more substantial response.

ahoge 12y ago
What does "turning into Java" even mean? What exactly are you afraid of? Having actual integers? Threads? Better tooling? The `class` keyword? It makes the code less verbose. Optional types? Would you rather write JSDoc comments? Optional typing actually works amazingly well. You need very few type annotations to get all the tooling benefits. Typically, it's enough to annotate the headers of your function. Type inference takes care of the rest.
- Offler 12y ago
  It might be a reference to Dart?
- ergothus 12y ago
  1) I was commenting on how they didn't answer the question. 2) JS and Java have very real differences. Turning one into the other DEFINITELY comes with consequences. Maybe you like them, maybe you don't, but it's clearly a legit question. Regarding #1: The optional part wasn't Perl6-style optional typing (which I'd be fine with), as I read it, but USING their system at all. If I teach how to juggle chainsaws, and someone says "isn't that dangerous?" and I respond "No, you don't have to do it", I've not addressed the question at all. Regarding #2: For me, it'd be threads (a simple system that is almost never painless), classes (JS today has objects but not classes, and it's a fundamental part of how it works), compilation, and most importantly typing. "Session session = Session.getSession()" is not something I enjoy typing.