Edward Welbourne <[email protected]> wrote: > Phil Bouchard <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
