Brandon Staggs

I don't see any language bias in this. The outlets I follow have lots of people trying to be rational about this and most of them probably don't know Delphi still exists, LOL. I am impressed by these tools to be sure. But I also know what they are, and I also know that when I ask AI a non-trivial question that I already have expert knowledge about, I am surprised at how bad the answer is. So, I am extremely skeptical when it comes to using it for things I am NOT an expert on. Is that unreasonable? Also, it's a simple fact that these are not any form of intelligence. The mainstream reporting on this issue has been mostly absurd and with far too much cheerleading or doomsaying. This is how these tools work: https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-doing-and-why-does-it-work TL;DR: it's autocomplete. Very complex and impressive autocomplete. When you ask ChatGPT a question, no entity is giving it consideration or thought, no abstract reasoning is occurring, no intuition is being exercised. An algorithm is scraping its database with a "this word should come next" algorithm. A really complex one. Knowing how it works should make anyone skeptical about broadly generalized applications of the technology. I don't think I am being unreasonable at all.

I don't buy this line of argument at all. ChatGPT will try its best to give you want you say you want, but it will try so hard that it will give you completely useless time-wasting information. If I tell an intern to write a base class for me that uses multiple inheritance in Delphi, I would not expect to be given a unit full of plausible-looking code that cannot compile. I would expect to be told that what I asked for cannot be done in Delphi. ChatGPT fails that basic test. Who has time to check that kind of work product? Sticking with your workplace analogy, wouldn't you fire someone who blithely pretended to fulfil your request like that? I wouldn't put up with it.

Tell ChapGPT to show you how to write a class with multiple inheritance in Delphi. It will confidently show you how to do it. Of course, you can't do it, and the code doesn't work. How useful is this stuff when you have to already be an expert on the topic to make sure you aren't being fed complete BS? Programmers ought to know better than to trust a massive auto-complete algorithm with any real work.

No. Unless you call an async function, whatever Win32 API you call happens in the thread you are calling it from and then returns.

I found this to be far more trouble than it was worth. Obviously it depends on the project, but I would rather make a clean break than try to fake it with something that can compile "alot" of my Pascal code. Learning the syntax is a breeze, so that is not an issue. You're going to have to change frameworks and learn the "way" of development with .Net. May as well just do it.

As for the compiler, I am more interested in Embarcadero moving away from compilers they maintain to an open architecture that doesn't depend on Embarcadero developers for improvement at all. But I do not agree that code efficiency is the primary issue. Faster binaries are great. But an IDE that doesn't choke on its own syntax is far more important to me. Editing features that are taken for granted in other IDEs and text editors getting implemented in Delphi impact my daily work far more than a few unused x64 registers.

We have had problems with minor Delphi point releases changing things in rtl/vcl that introduced new bugs on minor updates we build off them. It would be very helpful if any version of Delphi could be installed in parallel with others without resorting to VMs (not all applications can be developed in a VM, ours cannot; too much stuff happens too close to the metal). They already support alternate registry locations for an instance of the IDE, they ought to be able to let us install 11.2 and 11.3 on the same file system.

In the past I have fixed problems like this by deleting all of the .dsk files after updating Delphi. Worth a try, and a very low-impact thing to do even if it doesn't work.

The OP links to an article that shows how this can be useful. As one option for generating simple base classes it looks good. Also produced by ChatGPT today: When my wife was working with our daughter on a math problem, we wanted to check an answer that was clearly wrong in the answer key. Out of curiosity I typed it into ChatGPT. I attempted to tell ChatGPT it was in error and the session crashed on me.

This is a design flaw in FMX.

Are you using the PAServer package from the Delphi program files folder? I had problems like that until I downloaded the one from the website directly on the Mac machine.

The first, because in the latter, you are saying the first parameter is const but the others are going to get local copies. Also, for strings, there is no memory issue here you are solving. I really doubt any memory issue can exist with integer or boolean parameters. If so, probably you need to look at some kind of data structure you pass by reference. Strings are copy-on-write. In this case you are just telling the compiler not to allow setting a new value to the string in that function. You are just preventing the reference count from being incremented at the beginning of the function call, you are not changing how the compiler passes the string reference.

But what can they do? They have to sell their tools to stay in business, unlike many of the companies today that give away tools that support their business (Microsoft!). Their existing customer base is using Delphi mainly out of legacy requirements, so if they do anything to harm those customers or make their projects more difficult to update (bad tangents like ARC, for example), they harm their existing revenue. And if they make changes to chase modern coders (like, say, making their mobile compilers use ARC), their existing users don't benefit (at best) and those modern coders still don't have any reason to switch to Delphi. I don't have a solution. I continue to use Delphi because it serves the projects we still maintain and develop well enough, and throwing out millions of lines of code to start over somewhere else is still going to be more costly than a few Delphi subscriptions. The writing is on the wall, though. Delphi coders I know are planning their retirement and younger coders aren't interested in learning enough to understand real coding anyway! I just watched some guy's youtube video about how to get a job coding, and he called algorithms and data structures "theoretical" and "trick questions interviewers like to ask." The future of coding is hopeless if ridiculous stuff like that represents the industry trajectory, and anyone with an attitude like that is completely unqualified to write OOP code that requires basic memory management skills. And people who are skilled enough to write non-trivial applications in Delphi don't want the black hole on their resume that working on a Delphi application represents!

Just to be clear, the nil object method call to Clear was deliberately designed to cause an access violation. I am more concerned about the non-obvious things that happen outside of our control. In fact, my primary concern (not stated) is dealing with access violations inside of library calls; libraries we have to use but to not have control over. And in fact, I don't actually need to worry about that in particular, since calling a function in a dylib that leads to an AV will return to our function and execute the finally block anyway. Again, thanks for your explanation.

Thank you. I think I was being too restrictive in my search (always looking for something including "MacOS" or "Mac") and that was keeping your posts from me. Thank you for the details, it is very helpful!