[Development] Fornux C++ Superset

[Phil Bouchard]

Edward Welbourne <edward.welbourne at qt.io> wrote:
> Phil Bouchard <philippeb8 at gmail.com> wrote:
>>>> - Fornux C++ Superset
> 
> On 04/27/2018 04:18 AM, Edward Welbourne wrote:
>>> Nothing as yet persuades me that we need this one.  Of course, once your
>>> compiler can handle Qt's C++ code, you'll be at liberty to combine the
>>> first three above with whatever you like, including your favourite AI
>>> engine.
> 
> Phil Bouchard (27 April 2018 14:20)
>> I'm just trying to help speeding up development here.
> 
> It remains that you have failed to persuade folk on this list that
> Fornux would in fact speed up development.

That’s because:
- I am putting the cart before the horse and I haven’t provided a trial
version yet
- The projects need to be reasonably complex to notice a divergence in
development speed

>>>> I think that’s much better than wasting your time supporting Python or
>>>> Javascript that can be easily reverse engineered because of their
>>>> interpreted nature.
>>> 
>>> Your obsession with not being easy to reverse engineer suggests you
>>> don't really understand the nature of Free Software; our source code is
>>> publicly available, so who would need to reverse-engineer it ?
>>> We gladly share it and save them the bother,
> 
>> I'm referring to Qt's customers who wants to release commercial apps;
>> they won't like to know part of their code can be deciphered.
> 
> Well, first: copyright protects their work.  The fact that someone else
> can decipher it is incidental - even if they publish their source code,
> no-one else can *use* that without their permission.  Beyond that, as
> long as the code runs on users' computers, some form or another of the
> code is out there and the folk who are any good at reverse engineering
> are going to discover its secrets, if they care to do so.  Trying to
> keep your implementation secret is consequently mostly pointless.

- It’s always better to patent important algorithms
- But outside North-America and Europe, companies do not care about
copyrights and patents
- That’s why there are tools to protect your software from being reverse
engineered such as:
https://www.intertrust.com/products/application-shielding/

>> Performance does play a role as well; you don't want to bottleneck the
>> app with any garbage collector at all.
> 
> Garbage collectors have their advantages and their costs; the principal
> advantage is that developing in a garbage-collected language is
> significantly easier (you have fewer irrelevancies to pay attention to),
> which means a broader pool of authors can contribute - notably, those
> who are good at UX/UI design aren't always also good at the finicky
> details of keeping track of memory allocations.  So garbage-collected
> laguages tend to be good for rapid prototyping.  That's good, because
> you get to ship a useful (and useable) product sooner than your
> competitors.
> 
> Of course, the haphazard timing of garbage-collection runs can be an
> issue, although many garbage-collected systems seem to manage this
> without ever causing me annoyance (e.g. web browser ECMAScript engines,
> most obviously).  Java programs sporadically annoy me with this.

I would then suggest GC languages should be optional and not mandatory. At
the present time, QML forces us to use JS.

> Still, with QML, you then have the option of moving the
> performance-critical parts of the code (once the UX-competent developers
> have prototyped it) from interpreted JavaScript to compiled C++.  So you
> get the advantages of rapid development and deployment, combined with
> the ability to fix the performance issues that go with
> garbage-collection.  Python, similarly, lets one recode a module in C.
> 
> Performance of your development team (getting a useful product to market
> quickly) is at least as important as performance of your run-time
> program: and, with an interpreted language layered on top of an engine
> that you can augment in a compiled language, you can have both in
> practice,

Agreed.


Regards,
-Phil