[Development] [BB++] Now is 3.5x faster than Node.JS

[Thiago Macieira]

On Sunday, 23 July 2017 15:13:50 PDT Phil Bouchard wrote:
> On 07/23/2017 03:54 PM, Thiago Macieira wrote:
> > A problem that can again be mitigated by adding more RAM. Sometimes it's
> > easier/cheaper to just throw hardware at the problem than to rework the
> > software to be more efficient.
> 
> Well if you use more memory then you're clogging the bus. Regardless
> with a GC you're just postponing the problem and sooner or later the GC
> will have to kick-in. When that happens the OS is unusable.

But that's just it: the GC doesn't happen as often if you're not under memory 
pressure. You can postpone the GC to later and run it less often, when you're 
less busy. Your code can focus on being as fast as it can while the user is 
paying attention. Cleanup can be left undone until the user isn't paying 
attention.

> > You should always design your hardware based on what you expect to run or
> > design your software to run on the hardware that you have. If you
> > mis-design, then you'll have problems, clearly (and that's the bane of a
> > lot of embedded products).
> 
> True but BB++ apps are always going to be 3.5x faster than Javascript.
> So if you improve the memory chips, the bus and the CPU then BB++ apps
> still will be 3.5x faster.

But will they be 3.5x harder to write? 3.5x more error prone?

There's a reason people use interpreted languages. There's a reason why Python 
is so popular for even complex applications.

Mind you: I am a C++ developer.

> There's not much to learn:
> - replace 'var' with 'auto'
> - function parameters need to be stated explicitly
> - closures must use global variables

That's enough to relearn. And I'm not convinced you realise how much different 
it will be. 

Finally, there's also the lack of an ecosystem.

> And honestly to write an app you already need to know:
> - C++
> - QML
> - Javascript
> 
> I am not sure why Javascript was chosen in the first place in QML apps
> because all that is really useful is the XMLHttpRequest but all that

Because we had a JS interpreter already, in QtScript.

> > How does your tool deal with runtime code generation via eval() ?
> 
> First you need to ask yourself if that function is really used a lot
> because I never used it but if it is then you'll have to use it like a C
> printf to pass the parameters, embed a compiler and compile it on-demand.

I don't care if it is used a lot. It's used and that's enough.

But this answers the fact that you did not write a complete replacement of 
QML.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center