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

[Phil Bouchard]

Thiago Macieira <thiago.macieira at intel.com> wrote:
> 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.

Well I had a Samsung (Android) before and the damn garbage collector was
kicking in everytime I had a phone call so it obviously failed to predict
when to kick in or not.

>>> 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?

No. Like I was saying the errors are reported at compile time so you'll
spend less time trying to reproduce a bug at run-time.

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

It depends what you are doing. But these days people are not playing Unreal
Tournament all night long in Javascript because no such process exists! But
if you make it possible to build one and play all night long without any
lag then people will use it.

> 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. 

I think for somebody coming from a C++ background then he will be able to
find similarities fast enough. Somebody coming from a Javascript background
might have more problems indeed.

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

True but whatever's powerful people will buy into it quite fast.

>> 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.

No not yet obviously. I will try to write a Youtube presentation tonight.