111–120 of 327 posts
"Date hand-ported (h/t ksmith@netscape.com) from java.util.Date" I knew it!! The Date class is/was the worst thing about the Java library. It has confused a generation of programmers about dates and time zones. The main problem is that it's not a date, it's a time stamp.
Earlier quoted context omitted.
I think that's similar to how people say JSON was discovered by Crockford. Both only use things already present in the language, but they do form something new out of them. It is sort of a middle ground between discovery and invention.
Moreover, asm.js effectively already existed, right? It's not quite the same, but it's essentially a formalisation of what emscripten and the like already produced.
Oh yeah, great, many new features. But could you please fix the damn boolean logic? And while at it, get rid of most implicit conversions. Or forget all those features and bake in a macro system, so that we can fix anything without having to wait for the next ES[N] standard to get adopted.
Brendan's talked about adding a macro system. I'm not sure if a macro system could really let you redefine everything that's built in though...
edit: Sounds like I'm behind the times; found out about sweet.js (http://sweetjs.org/).
I just wish the best language would win, not the accidentally ubiquitous one. And giving a real choice of language would been even better.
You can paper over syntactic annoyances and semantic confusion with a mental mind-shift, and once they do, they become barriers to entry for your competitors. You can't paper over an inability to deploy your software in front of a customer. From the POV of "what's a showstopper, vs. what's an annoyance", ubiquity is the most important feature a language can have.
If you haven't seen a Brendan presentation, they are quite enjoyable. Last time he was playing some zombie video game in the middle of his presentation. He insisted on not killing zombies with a shovel using instead deployable automatic turrets. I'm sure he uses the shovel when he plays alone though. Javascript's is actually growing very well and fast. It's quite surprising how soon it will have everything. In a way…
Earlier quoted context omitted.
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.
Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined.
You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture.
You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations.
Microsoft can ship the CLR for ARM, x86, PowerPC.
You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you.
Microsoft can't ship a fully functioning CLR for JS.
Earlier quoted context omitted.
> Just let me know when browser vendors are going to break down the two-tiered system, and let us run those myriad of alternatives alongside -- instead of under -- JavaScript. The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles… > Or, they could take their own medicine,…
Works on OSes. We have a choice. In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad. It doesn't really matter if you like javascript, there's so many people who don't. Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not de…
Earlier quoted context omitted.
> The point is that if JS couldn't do these things, it would be eclipsed by a competitor. It instead grew the ability to do those things, and its competitors never gained widespread adoption. REALLY ?? JS can't do concurrency by any objective performance measure against systems providing shared state concurrency; how is a competitor going to eclipse it when the lowest-level syscall interface available to target is Ja…
> REALLY?? JS can't do concurrency by any objective performance measure against systems providing shared state concurrency https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...
Where is the competitor that could replace JS because JS didn't support concurrency over the past 15 years while the entire world adopted and leveraged SMP and multi-core hardware?
Earlier quoted context omitted.
There are no end of alternatives out there today, from mobile platforms to research languages exploring a myriad of aspects of computer science. Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript. Or, they could take their own medicine, and try and write the browser in JS.
Chrome was trying to do this: https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.