-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Erik,
Am 07.03.2011 10:46, schrieb Erik Corry: > 2011/3/5 Christian Mayer <[email protected]>: >> 1) A printf compatible format string >> ==================================== > > This seems like a library and not a language issue. Why not just pick > one, add the stuff you need, open source the result? Unless you are > willing to wait several years for browsers to support your project you > will have to do this anyway. It's correct that this belongs into a lib and not the basic language syntax. But for me (please correct me if I'm wrong), the ECMAScript language comes with a library that contains stuff like the "String" object. Exactly there should this request go to. BTW, I'm currently using already an external library for exactly that functionality. Searching the best lib for my project it seemed to me that I'm not the only one missing that feature - so I volunteered to tell "upstream" that there's a little (and, I guess quite easy to implement) thing missing that could help lots of people. >> 2) A binary type conversion including float >> =========================================== >> >> My project is using AJAX technology to transmit measurement data over >> the net in JSON notation. This data contains IEEE float values, encoding >> their bit and byte representation in hex values. > > That seems like a poor decision for an interchange format. ASCII fp > values work rather well. What is the space penalty for decimal vs hex > of gzipped data once you have already taken the hit for the JSON > overhead? Please don't judge the world only by your own point of view - it's larger than that. There are many use cases that need to encode and decode binary data into native data structures. E.g. (binary) file handling. Or in my project (binary) field bus traffic is converted by a little deamon as a gateway to a JSON structure (bytes converted to hex to stay in ASCII) so that my application can fetch it with the AJAX and COMET pattern. As the gateway can't know the context of the messages and if it's an integer value, a float, a string, ..., the JavaScript client has to decode them according to a given context. To continue point 1) - yes I'm already using a lib for converting to IEEE 754 as I can't wait multiple years till each mobile device has a new enough JavaScript version... >> 3) A fast library for small, fixed size vectors (numerical arrays) > > How fast does this need to be. Did you already do benchmarks on > modern browsers for the stuff you need. Of course: http://jsperf.com/object-vs-array/3 But that doesn't cover this request, it scratches only on the surface. After moving 2D and 3D paint events from the script interpreter to native code (and there currently from the CPU to hardware acceleration) it's the next logical step in increasing the computation performance. This is something where an interpreted interpreter can gain extremely performance (just compare Matlab loops with Matlab matrix operations). But also the JIT "interpreters" that are popular these days could take massive advantage of this language / library extension as those know in advance how to efficiently map it to CPU instructions. And it even gets better: this stuff is easily parallelisable to SIMD and (in the arbitrary dimension case) to threads when you take care of informations known in advance (i.e. at compile time of the interpreter itself) - but not so easy any more when done at JIT compiler runtime. >> So I hope I didn't write my ideas to the wrong list (if it is so, please >> correct me!). And I hope you can tell me if those additions could make >> it on the next spec of ECMAScript. > > In general I am of the opinion that if the language already offers the > building bricks that you need to do your task then it requires some > special reason why you can't just make a JS level library that fits > your needs. Basically, you need to have tried it and found that it > doesn't work for you for some fundamental reason. I'm with you that it's a tough decision where to draw the line between a complete and a bloated library. Let's revisit the three points: 1) This could be "easily" done with the current language and library set. So it wouldn't fullfill your requirements. But: it would round of the current library with a feature that has a great use and is asked for by many programmers. As it's just one additional method I argue that it's worth it. 2) This is very hard to do by the current language set. (Of course it's not impossible - but ECMAScript is a general purpose language so nearly everything is possible no matter how complicated it is...) Taking this hardness to do, it's easy implementation in the language of the interpreter (assuming C/C++, other languages probably also) and the current trend of web development (+ other uses of ECMAScript that aren't in the web context) I also argue that it's worth it's addition to the spec. 3) The requested feature set can be easily achieved by writing a little pure ECMAScript library. (This could also be used as a fallback when the interpreter doesn't support it natively). But: this library takes care of usually speed critical and/or computational intense stuff that would profit extremely from a native implementation. And: This library would only be complete if the arithmetic operators would be overloaded - but that's currently not possible in ECMAScript. A very important point for deciding if a feature should extend a language or not is for me to look at the "relevance". I.e. how many users (= programmers) would use it or not (and relate that to the other points that speak for or against a feature): Feature 1) is something that I can imagine to be used in most programs using ECMAScript. Feature 2) is far more specialized - but I see a bigger need in the near future and it's hard to get it done currently. Feature 3) has a *huge* potential. Not only the 2D and 3D world would eagerly need it, it also has uses in all sorts of sciences as I wrote in an other mail. And although it's easy to implement it in pure ECMAScript it has a massive speed gain by implementing it in native code. > Speed is not > necessarily an argument, since performance is improving all the time > and improvements to the optimization of JS code is the rising tide > that lifts all boats. I want to disagree here: although the big iron is getting bigger, lots of "small iron" appears. Just think of all the mobile devices that appeared during the last few years. For them not only speed is important but also energy efficiency. Ah, and those are getting more and more 2D and 3D applications (all the different "Apps" like games) written in ECMAScript... > Adding the library you need to the platform has > several disadvantages: > > * It makes the platform large and unwieldy. This worsens download > times, security surface, learning curve. > * It takes years before you can rely on support. > * It locks down the API prematurely, where JS based libraries are free > to evolve. An early lock down can be very good in some cases - e.g. to avoid that everyone heads into a different direction and has to do big refactoring (including changing proven algorithms) later on when that lib comes. > The role of a language standards body is to say no most of the time. > Anything else leads to a monster of a standard. I perfectly understand that. And I'm just offering my thoughts during my current project. Take them as feedback from the community and real world - - or leave them. It's up to the standards body. CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk11P+QACgkQoWM1JLkHou0ITgCfSC0S1GQYVoO7ePeld3nXiRAD CWgAn0nxSmDI10pjS8lQ711/+3MrIE2g =vt13 -----END PGP SIGNATURE----- _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
