[Development] Fornux C++ Superset

[Edward Welbourne]

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.

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

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

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,

	Eddy.