Phil Bouchard <philipp...@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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development