Additional language features

Christian Mayer mail at
Mon Mar 7 12:28:20 PST 2011

Hash: SHA256

Hello Erik,

Am 07.03.2011 10:46, schrieb Erik Corry:
> 2011/3/5 Christian Mayer <mail at>:
>> 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:
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
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.


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the es-discuss mailing list