71–75 of 75 posts
Earlier quoted context omitted.
mozilla does not have the power to create a new lingua franca. JS is the language of the web they are in the mittle of the standartisation why would the complicate stuff even more?
Rust is not for the web. It's an ahead-of-time compiled static systems programming language, for goodness' sake. Please read the FAQ before posting.
Earlier quoted context omitted.
mozilla does not have the power to create a new lingua franca. JS is the language of the web they are in the mittle of the standartisation why would the complicate stuff even more?
Rust is not for the web. It's an ahead-of-time compiled static systems programming language, for goodness' sake. Please read the FAQ before posting.
Earlier quoted context omitted.
His argument against Bytecode is unconvincing, in particular version hell and optimization limits in bytecode. The part that is convincing is the fact that we can't get vendors to agree on a bytecode. It's unfortunate that the most popular platform in the world will continue to look like it was cobbled together by CS 101 studwents who weren't particularly great students, and were drunk. People thought Windows 2.0 was…
My "argument" against bytecode on the basis of inevitable version hell and bytecode-lowering tending to overspecify against alternative implementation and optimization strategy is fundamentally an observation: both Java and .NET were designed for one particular language first, and the intermediate code design reflects this in many hardcoded and hard-to-change ways. Not only in what was put into the bytecode, but what…
This would be a long lead item, but one worth doing. I know the Mozilla folks got a kick out of the recent IE9 DCE issue, but I think most people who don't really care about your rivalry, agreed with your assessment, but thought that it continued to show how broken that JS is as an IL.
The point of doing this is to really get a bytecode that will allow language designers to build performant languages that still are first class citizens in browsers.
Unfortunately, the end result, as you say, is that we as developers need to simply get over the fact that we should expect more of our vendors.
It's ironic that people speak of everyone will build webapps with HTML5, yet when Apple and Palm pushed web-centric apps, no one showed up. When they moved to a "desktop"-model, the apps came. Its apparent why. The web doesn't care about devs -- and unsurprisingly the shallowness of most web apps is the result.
Earlier quoted context omitted.
Thanks for that. It wasn't clear from the linked article that Rust was started before Go. The overall impression that I got from TFA was that Rust is another instance of the garbage-collected system language fad.
I think the fact that Rust is older and yet Go has 1000s of active programmers is indicative of something. "Ship early, ship often" springs to mind. The Plan9 community has been working like that for years, almost every day an updated version is available (the distro cdrom is rebuilt every night) with bug fixes / improvements / new stuff.
Earlier quoted context omitted.
My "argument" against bytecode on the basis of inevitable version hell and bytecode-lowering tending to overspecify against alternative implementation and optimization strategy is fundamentally an observation: both Java and .NET were designed for one particular language first, and the intermediate code design reflects this in many hardcoded and hard-to-change ways. Not only in what was put into the bytecode, but what…
F#, IronRuby, IronPython, COBOL.NET, Fortran.NET? Arbitrary standards compliant C++ even compiles down to MSIL (the resulting bytecode is ugly, but works). But in any case, I wasn't suggesting we use the JVM or the CLR. I'd be fine with a bytecode that wasn't supported by either. This would be a long lead item, but one worth doing. I know the Mozilla folks got a kick out of the recent IE9 DCE issue, but I think most…
That IE9 Dead Code Elimination JS optimization that seemed strangely overtuned for one SunSpider test has nothing to do with JS source vs. bytecode. It does show how poor the industry-standard benchmarketing tests are (Apple is fixing to use the result of the loop, btw).
If you assume DCE happens upstream of transformation to bytecode, you assume more tooling than most web developers I've spoken to prefer to run. And anyway, web developers generally don't write useless yet computationally expensive loops!
But let me agree that it's possible a bytecode for JS could catch on, if only it could be standardized and implemented in all the top browsers.
Then we would have the versioning and future hostility problems I've mentioned, along with some other languages than JS being developed, which might or might not catch on.
So why don't we standardize some (or any, to read your comments) bytecode? I listed reasons including NIH and patents. Those are the "bad" ones but they're real. I don't think they afflict Mozilla, so kindly spare me your inflamed sense of grievance against "vendors".
Regarding web-based apps vs. native apps, see:
http://www.avc.com/a_vc/2010/11/html5-mobile-apps.html
and also
http://www.emarketer.com/Article.aspx?R=1008010
Opinions vary, but web-based apps if not "web apps" are trending up, not down.