[Development] Using semicolons in JS (QML)

André Pönitz apoenitz at t-online.de
Fri Sep 30 23:20:06 CEST 2016


On Fri, Sep 30, 2016 at 03:43:57PM +0000, Shawn Rutledge wrote:
> On 30 Sep 2016, at 14:19, Kai Koehne <Kai.Koehne at qt.io> wrote:
> > To make a proposal: Let’s use semicolons in imperative JS parts of QML in
> > our examples and documentation
> 
> Back in Nokia times it was said that we shouldn't use semicolons, because it
> would speed up the parsing and reduce the size of resources slightly.

Hear, hear! The world of JavaScript *IS* full of miracles!

It is FANTASTIC to know that letting the parser run into an error situation,
to back up, to insert an artificial semicolon, and to retry to parse would
be SO much faster than reading and interpreting a semicolon directly.

You know -- ok, sorry, I have to admit it, I was almost thinking that one could -
erm, do -- kind of silly things like create a benchmark, and perhaps even --
*SHUDDER* -- just a little? -- *run* it?

But now, of course, I see, this would be really ridiculous. Silly me.

And this resource reduction! I mean, we are not talking peanuts here, like
World Peace or such, right - but bits, *REAL* bits, and not -- really! -- not
just ONE, not TWO, but SEVERAL of them, in a row! This is so incredible!

I really, really cannot imagine how dull the world must have been before the
magic Ten Days.

Oh man. I just notice I am talking crap. It's of course not *REAL* for bits in
JavaScript, but *DOUBLES*! Stupid C++ would have used integers for such
important things. I mean, that's not paying the right amount of deference, ok?
Why should one let an integer operation pass a CPU in, like, one or two cycles,
or possibly even less than one, if one really could spend a multiple of that on
floating points? Or even require extra hardware? That's not taking machines
seriously, is it?

> (Maybe you think performance isn’t impacted by small things like that, but we
> are at the same time investing effort into other “optimizations” for which I
> suspect the runtime performance impact may end up being similarly small.)

Even more miracles! What a wonderful world!

Ahead-of time compiled C++ code can not only be vastly improved by replacing it
with run-time interpreted code - note the word "RUN!" -- that's already making
very clear that this *must* be fast, doesn't it! -- people in the know may even
take that further and strip away those pesky semicolons from the sources to
gain even more performance!

That's absolutely great -  or, dare I say? --  AWESOME!

Andre'



PS: On the less serious side:

> If you think it’s important, then write a reformatter tool and figure out how
> to use it as a git hook.  We are wasting time bikeshedding about coding style
> (do you really have nothing better to do? 

There would be that 'consistent documentation' thing that was mentioned
in the initial mail. I think this is a valid reason.




More information about the Development mailing list