Jump to content


Popular Content

Showing content with the highest reputation on 04/19/19 in all areas

  1. 1 point
    I do have my own clinic, and I could call myself CEO, but not, not in the business. And 10 grand is nothing. The "fixer" would have to try to understand the complete source code, would have to find a solution without rewriting the entire compiler and without breaking anything. Think of a few zeroes more left of the decimal point, and not a few weeks, but a few years. And if things go wrong, he would face a lot of criticims and would probably have to fight for his fees too. And what makes you think you can find someone capable of doing or willing to do it at all? Sorry, I have no idea what you want or mean with the above pseudo-code, or with your "ARC = shared pointers backed by compiler magic". Makes no sense. It may dampen your enthusiasm, but you may want to think about that a little longer. I know what I have said. I don't care about your "ARC but not ARC" ("dead ARC"). I do care about better code generation, but not about laming ARC by not properly counting. I personally find it a pity that they are phasing out ARC instead of improving upon it. But you will not see non-ARC code peacefully coexist with ARC. Your kind of "dead ARC" may coexist with proper (live) ARC (although I even doubt that), but what would be the advantage of carrying along that much dea weight? That would not be an improvement. And of course the compiler/runtime can be made thus that they can be useful. They were almost there, but there were some issues. I'm sure these could have been solved, had there been enough time. And the main advantage would not have been shared pointers, it would have been the opportunity to manually tune records with methods and operators to make them much more lightweight and performant. Shared pointers and some other scenarios would have been a nice side effect. You could write your own refcounted types, including optimized dynamic arrays (these also suffer from the runtime typeinfo/RTTI slowdown). You could have dynarrays with COW without havin to use interfaces. etc.etc. But that is off-topic. Again: there is no indication that an open source team, well paid or not, could or would do better. FPC is already well on the way, so why didn't anyone create a new team, fork FPC, concentrate on the few platforms that make sense and make that great language you want? Because no one wants to pay for it, or has so much enthusiasm he will do it for free or is capable enough. If opensourcing had been a viable alternative, someone would have improved FPC, or a fork, well beyond Delphi already (either by a team of highly motivated and capable enthusiasts, or a team of capable paid developers). And if Embarcadero can build a great IDE and debugger, what makes you think an icnlined team of developers couldn't do the same? So there would be a better Lazarus with a proper debugger, and there would be an incredibly cool compiler and runtime. But obviously that didn't happen yet. Guess why.