I thought y’all might be interested in an experiment that I ran on Monday night.
I have a simple app that I use at work for keeping track of how long I spend on the things that are assigned to me in Jira. This app was originally built in Real Studio and migrated over the years as I’ve needed improvements.
I made a backup copy of the project and an empty folder for the Buoy result. I then opened a Claude Code terminal window and instructed it to convert the project to Buoy with permission to use the provided examples, documentation and the new online docs as well as the online Xojo documentation. I also told it that if it ran into anything that it could not figure out, gaps in Buoy or it came across any bugs during the process, that it was to put the gaps and the items it couldn’t complete into a markdown file and report the rest as bugs in Buoy.
This is not a big project by any stretch of the imagination, but it’s also not a hello world app. I watched it for about 30 minutes before going to bed. In the morning I found that it had run for about 90 minutes and found a few things that I had completely forgotten about:
- Clipboard Access
- Windows System Tray Items
- UDP multicast and broadcast
- Disclosure Triangle
- DateTime Picker
- SpecialFolder
- Folder Creation
One of the things that came up (and we addressed in 0.28.0) is Variants. Both Norman and I have talked about how evil they are and that they go against all we hold dear about strongly typed languages.
Overall it was a good learning experience and I’ll be doing this with more and more of my projects to get our conversion code as good as it can be.
Cool reports about your experience
Such attempts will point out the gaps and over time that gap list should shrink dramatically
How many lines of code have the Xojo and the converted Bouy app?
does it means you will have a conversion program to convert xojo code to buoy code??
if using Claude Code is still necessary, what prompt do you give Claude code to to the conversion??
I also assume you are using the source control version of the code instead of the binary or xml version
We’re hoping. As I mentioned in last nights release notes, we added an already deprecated Variant. We anticipate this will be part of a Xojo shim that would be needed to get things up and running faster. You’ve noticed that for some things we’re choosing different names. Buoy has genuine type aliases and so the shim will attempt to have the smallest impact on performance as we can get.
As I’ve mentioned, we’re not targeting any particular AI. That said, using one of the ones that particularly excels at code gets you the most mileage. The prompt was:
ok, I have a challenge for you. I would like you to convert the xojo project that is in <source> into a buoy project and put it in here <destination> convert as much as you can and make a markdown report to the desktop containing any items that you were unable to convert, updating it as you go. If you do come across items that appear to be bugs in Buoy, make a bug report using the buoy-bug-report skill. You may use:
* /Applications/Buoy
* /Applications/Xojo 2024 release 2.4
* https://www.stretchedout.com/buoy
* https://docs.xojo.com
Yes. 99% of my Xojo code is in source control format.
Don’t know off the top of my head. If you said “hello world” = 1 and the Xojo IDE = 10 on a logarithmic scale, I’d say this was about a 3. I’m not saying that 90 minutes was great, but certainly doable as a starting point. It spent a bit of time trying to make workarounds. For instance, there’s an unfinished SQLite package included with Buoy right now. It made a SQLite database class and a RowSet class and pointed it at the raw SQLite package. That was impressive.
Xojo could have avoided a lot of trouble with this feature. Like have Add and Append be the same thing with two names. Same for e.g. Listbox and DesktopListbox.
Methods and types are different however. Also don’t forget, Norman and I were working there during the API transitions. We (the engineering team) had a lot of discussions about what the goals were, how it would be implemented, what kinds of impacts it would have on the users. That failed API 1.5 namespace thing in the middle… the concept was a good one. Separate the similar functionality into nested modules/namespaces to make the language more discoverable. What could go wrong? What Xojo always had trouble understanding was that legacy users needed different things than new users. The namespace thing worked great for people who were just starting out, not so much for people who had years of code and experience under their belts.
And don’t get me wrong, there were things in the old API 1 that would constantly trip me up, having to remember if this function or that needed a zero or one-based index. Getting that mostly figured out in API 2 was the right direction to go IMHO.
What I’m aiming for in Buoy is what I always believed was the “right way”. String and text functions use 1-based positions, because that’s how people think about text. You want to grab 3 characters starting at position 5? Mid(5,3). No mental math. Arrays are different. Indexes represent memory offsets and it’s important for developers to know the difference and not just try to “magic that away”. Doing so not only makes it hard to move away from your language but it also makes it unnecessarily difficult to move to your language or in conjunction with others because you always have to remember “oh, I’m in Xojo now, indexes and positions aren’t always what I expect”
TL;DR
We’re doing a lot of things with Buoy that Norman and I saw as gaps in Xojo. Adding modern language features that users can grow into so they’ll want to stay with Buoy, but we are not under the illusion that it’ll be users’ only tool in their toolbox. Choosing to change tools to something new is a hard lift for anyone (I had to learn Groovy for my new job, blech), but we’ll be happy to be the place where Xojo developers go after they’ve outgrown what that language can offer.
We are extremely grateful for those of you that are putting in your valuable time to play with Buoy and give us feedback. The bug reports and feature requests we’ve gotten have led to finding important gaps, many of which are showstoppers for a 1.0 release. Please keep exercising the framework and don’t be afraid to speak up if something doesn’t work the way you expected. It’s entirely possible that we missed something crucial in the original design.