What goes up must come down. Spinnin' wheel got to go 'round.
A colleague asked me why I hadn't written any new blog posts in a while. He's not wrong. I have been remiss. I asked if he had any suggestions and he said something along the lines of "Two neutron stars orbiting each other".
Smart aleck...
So, given these detailed and specific requirements, I did what any self-respecting developer does in this day and age; I procrastinated as long as I could and then asked ChatGPT.
First Attempt
I gave ChatGPT the following prompt:
Using the FireMonkey framework in Delphi, write a program that shows two objects orbiting each other
Which produced this working solution on its first attempt.
I don't know about you, but I think this fits the brief. Checks all the boxes. Passes muster. Job done.
It isn't very satisfying, though. It's just two TCircle components following a fixed path and it isn't very interesting, visually.
We can do better...
Many Attempts Later...
At a bare minimum, the objects should have some mass and exert a gravitational force. The combination of these forces could then be used to determine their movements dynamically instead of using a fixed path. They would also have some initial starting point and velocity.
While I was procrastinating, I also thought it would be interesting to have some kind of field to show the effects of gravity on the space around the two objects.
After more back-and-forth with ChatGPT, a few missteps and some manual tweaking, I think this looks much better. Almost hypnotic:
And finally, I added sliders for some constants and reset buttons so I could play with different values on the fly without having to recompile.
Source Code
The code for Gravity01 is exactly as I received it from ChatGPT. Good and bad.
The code for Gravity02 has been tweaked significantly. There's still room for improvement (duplicate code, tight coupling with the UI, etc), but it is just an example, after all.
The source code for both projects is available on GitHub and is compatible with the Delphi Community Edition.
Lessons Learned
The Good:
There's a lot to like about using something like ChatGPT to help solve coding problems.
Sometimes, getting started on a project is the hard part. If I can use AI to create proofs of concept quickly and easily from a brief description, it gives me a head start and I can get to the interesting stuff faster.
After the initial hurdle of getting started, if I can iterate through proposed ideas quickly without investing a lot of time on any given detour, I can get to a final design sooner.
AI is great at generating tedious code or boilerplate way faster than I can type it. Anything from SQL statements to translating JSON into another format to prefixing all local variables in Delphi with an "L" (as they should be). Let the computer do the boring stuff.
It can be faster to ask ChatGPT for an explanation of a piece of code than it is to look it up in the documentation or with Google.
Basically, I have a short attention span.
The Bad:
ChatGPT will (sometimes) cheerfully and confidently give you wrong answers.
The most obvious example is making up methods or properties that don't exist. Fortunately, these are easy to spot (they just won't compile). I'm more concerned with some of the more subtle "oversights".
Did you know that since Delphi 10.1 (I think?) the Stroke.Kind property of the FireMonkey canvas is set to None by default (for some reason) so that even apparently correct code doesn't draw properly? ChatGPT didn't.
In the PaintBox's OnPaint event, if you use the dimensions for the form instead of the paintbox, things work fine as long as they are the same, but it might not be obvious why things don't paint as expected when they aren't.
Just to name two. If you don't know to look for these things, then you might wind up with code that you don't fully understand and can't reliably troubleshoot.
Code generated by ChatGPT may also include things that I would consider to be bad coding habits.
- Lots of comments. Some more useful than others.
- Including a mix of regular and inline variables in the same code base.
- Duplication of code.
- etc.
Be aware of the potential downsides and be careful about the quality of the code that you add to your projects.
The Conspiratorial?:
In spite of any reassurances, I'm more than a little concerned that anything I paste into an AI tool could become part of its training data or otherwise stored or used outside of my control.
I would think twice before pasting proprietary code, anything with user names or passwords, PII or (even worse) PHI or other sensitive information into someone else's web site.
Just sayin'...
Otherwise, have fun!
4 comments:
Thanks, Bruce.
It's so interesting for someone like me who hasn't worked with FireMonkey before. It really piques my interest.
Also the "Lessons learned" part.
Great read! As the "colleague" in question, I enjoyed the journey from procrastination to gravitational simulation. However, I must confess, the original suggestion was slightly more ambitious. While two neutron stars orbiting each other is a great start, I was actually hoping to see a gravity wave simulation for a trio of neutron stars —- a classic three-body problem!
But hey, I can’t blame you for starting small. Baby steps, right Bruce?
Keep up the good work, and I look forward to the next interstellar FireMonkey adventure. Who knows, maybe the next time you can toss in a black hole for good measure?
Cheers,
Colleague.
Requirements that aren't mentioned until after delivery don't usually make it into the first release.
I don't know about a gravity wave simulation (sounds hard), but that three-body thing seems simple enough.
We should be able to get to this in the next two to five business months.
Excellent post! I don't think OpenAI uses our prompts for training because this architecture isn't based on incremental learning, and it also needs clean data for training. At least for now, I hope it doesn't use our prompts for learning.
Post a Comment