FreeDelphiPascal

I hope (at least in EU) they will introduce some regulations around AIs.

I assure you, Copilot is doing a lot more than that !!!!!!

I am not talking about building their own AI, but IDE-AI integration as copilot...

I expected that the transition to AI will be a bit more gradual, but it seems, Devin is already able to create a full application from a prompt. And I mean the proper way, not ChatGPT style.... So, all kind of questions are coming to my mind. For example, since we know that Microsoft is using GitHub to train its AI, for which later I will have to pay a shitload of money to use it, should I retract my projects from GitHub? Also, what is Embarcadero doing to stay on top? Will we continue to write code line by line in Delphi IDE, while other programmers will have no IDE anymore but a small chat box where they can enter a prompt? Since Devin will cost a load of money, how will independent developers (and even small companies) be able to compete? Will we all work for megacorporations that afford to buy the AI?

I agree. There are way more 32bit apps out there than 64bit.

Come on David, you know it worth trading the "less convenient" way of programming in Delphi, for the speed we get from a Delphi program. I won't even dare to put Python in the same speed chart as Delphi.... 🙂

DDevExt also has this capability https://github.com/ahausladen/DDevExtensions

DDevExt also has this capability https://github.com/ahausladen/DDevExtensions

Sometimes Ctrl+Click simply won't work. It is probably related to this setting.

A solid question! I don't know all the languages out there, but Java and C# (which are more memory safe than Delphi because of their GC), loose quite a bit of speed because they have to spend some time to check the GC and decide what to clean up (release). EVEN if they would spend very little on this task, they have to "stop the world" from time to time. There is no way to use such a language in time-critical systems (I worked on such a system in the past). Therefore, these safer languages, have to pay a price for their safety. I am curious if there is any language out there that is as fast as Delphi and more memory safe. From what I heard, Rust is not using a GC, while still being fast and safe. I would like to see some speed comparison between Delphi and Rust. I heard that its speed is only slightly smaller than C++'s speed (and from here we can extrapolate to Delphi's speed). But its compilation time is even higher than C++ compilation time, which compared to Delphi... well... we all know how ridiculous C++ is at this chapter. 🙂 Also, Rust cannot do GUI natively, like Delphi. So, you cannot even compare Delphi and Rust at this chapter. In Rust, you must opt for GTK, QT (ha ha ha) or do some web-based GUIs - with all their known drawbacks. So, I would say, Rust is more oriented towards "systems" (DB, servers, automations, embedded systems, robots, etc.) not towards desktop apps. So, as you Lars said, I would like to see a language that is memory safe and executes fast, and compiles fast and comes with 500 visual components out of the box. __________ Note: Note: When I say Delphi is safe, I assume that the programmer played safe and didn't abuse the pointers and didn’t override Delphi’s strong typing system. I worked on a system that look like it was written by a C programmer. Procedures like DoSomething(var P); all over the place, and half of the parameters passed are raw pointers. But as somebody said above, give a bold programmer a safe language, and it would find a way to abuse it. It would take a bit more creativity than in Delphi which puts the pointers (almost directly) on the table, but sure you can screw up in the end.

But aren't you supposed in the end to put the PixelFormat to pf8???? I need the final image as pf8. But if I set its PixelFormat to pf8, some wavy patterns appear in it (like when you convert a high color image to 256 color GIF)

I have seen nasty sh*t in my life. So, I am totally for this!

Yes. I totally understand and agree with that. Because of this, I went in my post above, and I changed the word "error" with "issue", to eliminate any interpretation. I like to be pedantic 🙂

LLVM is not quite a programming language. So, you are right in a way: you could recover at the hardware level, but LLVM fails to do so. But then, let's not blame Delphi language itself for this. So, I would correct myself and say that the issue is between the hardware and the language, in the LLVM. Do you agree with this "technicality"? 🙂

I don't think you read Dalija's article. It clearly states that it is hardware related, not language related.