To those who say that creating a JavaScript 2.0 would break compatibility... couldn't you have a .js2 extension and compile a .js as a fallback. The newer browser would ignore the fallback and use the js2. Thoughts??
Example:
The State of JavaScript - Brendan Eich
191–200 of 266 posts
Re: The State of JavaScript - Brendan Eich
#192Earlier quoted context omitted.
Thats a good thing. Rust is THE alternative to C++, and it should not lose focus by compiling to javascript.... Rust should not compile to javascript.. It should remain native(LLVM). @pcwalton Please assure me that rust won't compile to javascript, and it will remain Native (C/C++ compatible, ahead-of-time). Rust is my last haven, let it remain rust only!!
Well, we aren't going to stop, or even discourage, people from writing Rust-to-JS compilers, but we won't be working on such a thing...
Hey, thanks...
I believe - Anything can reach very high, granted it dosen't lose aim/target... Javascript as a target is intrestingly beautiful, but this might fork up a way for yet another dart. Rust should remain, what its meant for....
Re: The State of JavaScript - Brendan Eich
#193Earlier quoted context omitted.
PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format. PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified now…
There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to…
The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.
Re: The State of JavaScript - Brendan Eich
#194Earlier quoted context omitted.
PNaCl is both not done and (last I checked) not totally machine-independent due to LLVM encodings of machine word sizes. See also http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43... for doubts on the wisdom of using LLVM bitcode for a long-lived, widely-distributed object file format. PNACL is a fine research project, but unfortunately both NaCl and PNaCl are tied to Pepper, a gargantuan API specified now…
There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to…
[deleted]
Re: The State of JavaScript - Brendan Eich
#195I would expect to hear something like that not from a respected tehnologist but rather from yet another "cool kid". He could just say "JavaScript is awesome" on a single slide and that wouldn't tell much less than what the whole presentation did. > First they said JS couldn't be useful for building rich internet apps Who said it is? Rich - yes. Anything near to match complexity of the desktop apps - never(think Photo…
Why do we need to make Photoshop in JS?
I can't make a printing press in C++, but why would I want to?
Photoshop was made during an era where computers were used to make media for physical printing. You would take a picture with an analog camera, digitize it, manipulate it in Photoshop, and then have it ready for print. "Save For Web" is the closest you get to using Photoshop for publishing to the web, and you'd have to admit it's a bit of an afterthought in the whole experience.
Software doesn't exist on it's own. It exists in an input and output environment, beyond just mice and monitors. It exists to capture information, manipulate it, and then republish it.
In many ways, memegenerator.net does a better job of consuming, manipulating, and publishing content for the web than Photoshop does.
Photoshop will probably not go away. There are still printing presses and there are avenues to publish things made with them. Media tends to gain a lot of inertia by the time it gets to the point of being a household name. However, this inertia doesn't really impede some other form of media from gaining it's own momentum. Photoshop is busy being Photoshop, not memegenerator.net.
If you ask my opinion, I'd say there is plenty of ground somewhere between memegenerator.net and Photoshop and there is no better language and environment to create these tools than the environment where they will be published: JavaScript running in a web browser.
Re: The State of JavaScript - Brendan Eich
#196Earlier quoted context omitted.
You seem to misunderstand "structs" -- see http://wiki.ecmascript.org/doku.php?id=harmony:binary_data , this is an extension of WebGL's typed arrays, which are already in all the new browsers (IE10 too). As for implicit coercions, I enjoyed Gary Bernhardt's "Wat", referred to it, and at past talks even mocked along with. At Strange Loop, I went through each "Wat" in the "Wat Secrets Revealed" slide series (use down a…
May be off-topic but: Is it just me, or are macros just a new way to get confused while reading JavaScript? Introducing language-foreign syntactic constructs seems to me superfluous and confusing - This is the job of transcompiling languages like CoffeeScript.
All abstractions can make your code unreadable; the key, as always, is to create good abstractions and document them clearly. Macros are syntactic abstractions. It's just as important to document them as it is for functions or objects. Of course, if you just have a little local macro that you're using for convenience, looking at the implementation may be sufficient. But when you write a macro that you want to share from a module, rather than requiring your clients to read the implementation, you document the syntax and the semantics, just like you would if you were writing a separate language.
But by having macros directly in JS, instead of having to use a whole language that compiles to JS, you can combine syntactic features from different sources. For example, right now there's no way to use one feature you like from CoffeeScript with another feature you like from TypeScript. You just can't combine them. But with macros, you could import two different syntaxes from two different libraries and use them in the same code.
On top of that, if we actually had macros in a future version of the standard, you wouldn't even have to precompile the macros offline, and you wouldn't need a preprocessing step at all. (For latency purposes, you might want to preprocess macros offline as an optimization. But for development, not having to do a preprocessing step is more convenient.)
Dave
Re: The State of JavaScript - Brendan Eich
#197This presentation saddened me. The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical…
Sorry, missed the Yoda misquote at the end, I must respond!
Yoda said "where you are" but you used "was". Possibly just a tense-typo, but it matters. Tracking where JS is is a part of the TC39 job, but only a part. It's easy to fall into a trap where we standardize only what developers can express given the language's current semantics and so miss the chance to extend those semantics.
But I'll take the tense-corrected bait: yes, I talk about the future. The past (including its most recent instantaneous sample known as "the present") is greedy. With no one to look ahead or synthesize ideas from compile-to-JS and other languages that win user support, JS will tend to stagnate, all else equal. Champions (not just me) must fight for a better future.
Stagnation on the web is a social ill. It costs developers tons of time. We know this not only from IE6, but from Android 2.x WebKit. Some not-disinterested parties might want to make use of a crisis of this sort, to force a "new JS" (Dart? remember WPF and WPF/E in the past) to be adopted for want of anything to relieve the stagnation.
Not me. The cost is too high, the lessons learned in JS will be half- or three-quarters-lost, and too much code and developer brainprint will be thrown away. I'm reminded of the XML Utopia that was planned in w3.org to save us from bad old HTML, before a few of us called b.s. and started the whatwg.org to do HTML5.
The web is an evolving system, JS is part of the web standards and must evolve too. Skate where the puck will be. Or to wannabe Yoda on ice: where the puck will be, you must skate!
Re: The State of JavaScript - Brendan Eich
#198Earlier quoted context omitted.
There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to…
The link he cited still does apply. It discusses several different issues. PNaCl's portability only covers a subset of them.
Thanks! I happen to agree with with Dan Gohman (http://comments.gmane.org/gmane.comp.compilers.llvm.devel/43...), but I'm not sure where Chris Lattner ended up on this.
Much is possible in software, so perhaps some day, or under some transformation, LLVM bitcode would be suitable as a stable long-term object file format.
There's still a point here: PNaCl is pushing a stone up a very tall hill. ANDF and other Universal Object formats go back to the 70s if not earlier. It's very difficult to standardize such things, never mind Pepper.
Re: The State of JavaScript - Brendan Eich
#199I would expect to hear something like that not from a respected tehnologist but rather from yet another "cool kid". He could just say "JavaScript is awesome" on a single slide and that wouldn't tell much less than what the whole presentation did. > First they said JS couldn't be useful for building rich internet apps Who said it is? Rich - yes. Anything near to match complexity of the desktop apps - never(think Photo…
Photoshop is a notorious pig. I know many designers who have already ditched it for in-browser development. See the latest JSConf.eu talk on this topic: http://2012.jsconf.eu/speaker/2012/08/29/because-f-k-photosh... (slides: https://speakerdeck.com/u/nrrrdcore/p/js-dot-conf-dot-eu-201... -- but you probably had to be there).
I sense trollery here: "but you can add bindings to all of this stuff for virtually any programming language." Who said otherwise? The bogus claims against JS (going back to the "RIA" era, where IBM and Macromedia/Adobe made such arguments) already fell.
The issue is not what languages can program the GPU somehow -- because only JS is supported directly in browsers, the issue is whether JS cannot. Clearly (WebGL, River Trail, even GLSL embedded in an unknown-type script and downloaded via JS) that's false. But it seemed true once, which led to the false anti-JS prophecy.
At the risk of feeding a troll, I suggest you use the down arrow on the "goto L0" slide to see how JS enables compiling control effects without goto.
And play BananaBread, for crying out loud (https://developer.mozilla.org/en-US/demos/detail/bananabread). You simply do not know what you are talking about by your next-to-last paragraph.
Yes, typed arrays were ad-hoc (so are many incremental web standards that win). Binary data (arrays and structs, which compose) as proposed in ES6 are not.
Re: The State of JavaScript - Brendan Eich
#200This presentation saddened me. The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical…
Sorry, missed the Yoda misquote at the end, I must respond! Yoda said "where you are " but you used "was". Possibly just a tense-typo, but it matters. Tracking where JS is is a part of the TC39 job, but only a part. It's easy to fall into a trap where we standardize only what developers can express given the language's current semantics and so miss the chance to extend those semantics. But I'll take the tense-correct…
> The web is an evolving system, JS is part of the web standards and must evolve too.
I don't see too many language gizmos in the presentation which reflect the requirements of web standards. Most of them are extensions to a language which desperately needs modification more than extension at this time. Evolution in a language is a matter of where you spend your development resources. &rest-args, weak maps, modules, and so on would be nice to have. But I would gladly sacrifice them to the gods to get rid of JS's global variable issues. It seems to me that ES is mostly building more and more features on top of a foundation of sand rather than taking a breath and revisiting how to reinforce the foundation.
Apple did this recently. OS X 10.6 (Snow Leopard) was an entire release that consisted of almost nothing but cleaning house. Few new features, just heavily revised internals. It's probably the most important release Apple has done in a very long time.
Now one can make the argument that fundamental fixes to long-standing language flaws is a challenging thing to produce given the bulk of development work which relies on the old language. That's a different discussion and one worth having. But moving forward with gizmos simply for the "future"'s sake, without considering the current sad state of the language, is I think misguided. I would strongly urge the committee to take a step back and identify the top twenty most problematic features of the language, and how they might be able to develop a "strict" version of the language which fixes those features, yet retains interoperability with code files written in non-strict form. Then they can go back to adding new gizmos.
(BTW, the "was" is due to the original Empire quote). http://www.imdb.com/character/ch0000015/quotes