[Development] Fornux C++ Superset
philippeb8 at gmail.com
Fri Apr 27 15:36:20 CEST 2018
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
> 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 am putting the cart before the horse and I haven’t provided a trial
- The projects need to be reasonably complex to notice a divergence in
>>>> I think that’s much better than wasting your time supporting Python or
>>>> 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:
>> 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
> 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
> 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
More information about the Development