Where should Delphi develop instead of where it is developing now?

That's what we, the developers, really need? Today I just thought about it - I threw in a few letters, first with a comment , and then I decided that it would pull on the post:

First of all, it annoys me terribly that all the development under Windows has been trying to transplant away the level from iron several times already. More thick pads cram between the application software and the processor, between the smooth software and the OS. IMHO, closer to the native code, you need to strive, closer to the hardware, closer to the OS! To any hardware, to any OS. We need to develop Object Pascal as an alternative to C ++, characterized by advanced OOP tools, syntactic sugar, for which we love Pascal, a powerful IDE and a native fast single-pass compiler.
')
In addition, we need advanced integration capabilities with third-party libraries. This, in comparison with C, is not enough. There are many libraries around, all sorts of interpreters are not able to do anything, but for Delphi libraries you will find figs now, and as a result you do it yourself with a certain amount of work. And then rework when updating the API. For this purpose, thin wrapper generators are needed. Lazarus has an odd job called h2pas, but you need to develop it, and even integrate it! Would they, eh? .. And even better - try to comprehend and make transparent use of modules in different languages ​​in one project - in particular, the direct connection of h-files of libraries. I am sure that the linker can be made so that he would deal with it.

Built-in assembler - was pokotsali it ... Assembler inserts now can not, you can only the whole procedure. Why? .. xs. It is necessary to return it, and develop, document (documentation on the built-in assembler has never happened!), Make support for all modern instruction sets for processors and co-processors!

Tools for integrating external compilers instead of your own. Changeable compilers - for different platforms, from different manufacturers. For example, I saw that Intel did an optimizing compiler for its processors - it would be great to be able to use it for Delphi programs.

Included are built-in syntax access not only to the dll (it’s been there for a long time and that’s good) and through ActiveX (which’s been there for a while, but not as beautifully designed as it could be), but also to the .net and Unix libraries , MacOS, iOS, Android, etc. - in general, support for platform-forming libraries. Although, I did not see how it was designed for FireMonkey, maybe it is already there ... But it’s strange that they don’t buzz on all corners louder than they do on FireMonkey itself. But about the ability to use the power of native Delphi libraries. Net, I did not hear.

Accordingly, on those tools it would be right to have wrappers for the API of the base libraries. Net, Cocoa, iOS, Android SDK, to the X Window System, etc. It is possible that they are generated on the fly by those generators of thin wrappers, about which I spoke above ... And the documentation to them so that they can be linked from any sources, both local and online.

On top of them, as the level of abstraction of the VCL type is a thin wrapper to Qt or even a Qt port for Delphi. As an alternative to VCL, a patient with hereditary diseases, complicated straps of packages of components on packages used by the IDE itself. There should be support for changing the form designers and the storage format of these forms, there should be independence of the designers' code from the code and the basic libraries of the development environment, so that you can use a modified VCL or not a VCL in the designer.

There should be two-way online conversion of code and forms into anything, plug-ins on an open API, and not just something built into the ModelMaker diagrams. In particular, it seems to me that it is possible already on the fly to convert the code not only into C ++ code and back (which, by the way, is one of the excellent options for implementing importing h-files) and into assembly language (both are useful for using third-party compilers GNU and Intel's), but also directly into the binary executable code, that is, compile to do on the fly, so that the launch could only work the linker, throwing out the unused and forming the executable file.

And by the way, assembly of packages and distributions for different platforms are also plug-ins, so that the community can participate in the expansion of spheres of influence.

The only question is what is there and how to sell? What could be a successful monetization strategy for such a project? Lazarus with FreePascal is catching up, and theoretically it can do it all too ...

UPD: In the post " The Future of WinRT or Going Native 2.0 ", a certain Alexandre Mutel echoes me about "code conversion to anything" and the usefulness of native