Many customers have a firm opinion on what they want. They tend to have a less clear picture of what they need.
1 Like
Or worse they have a clear picture but they are addressing a symptom & not the problem
1 Like
Your’e right, it is a really good code completion. Assisting in completion is working. But it is not writing complete Systems and not engineering the entire mechanics, electronics, firmware, software and Web/Cloud-software for a product. It is, simply, not replacing the engineer but assisting the engineer.
May be that it will come to that place once. But it is far, really far away from that. There is no AI replacing all engineers in a project. It reduces project time when completing code but not when doing the engineers job.
1 Like
I greatly respect your opinions. My recent experience with ChatGPT has been that when I have a bug in code, I can copy the code (including the ability to drop images of screens (using Screenshots on Mac)), it has reduced the time finding code erros significantly. It finds typos and even found a secure bug today. Of course, I had to tell it which verison of Xojo I was using. As for writing code - hiot or miss unless details information about what one is trying to do, then the basic structure gets started quickly.
Just reading about AI and Xojo. You know real AI using has not only suggestions when coding but also an AI chat. But the most useful is the suggestions generator. Writing Software and getting suggestions to spare tons of time while using the suggestions or parts of it in realtime in the IDE. So for Xojo there is no AI model which could be used inside of the IDE and there is no possible solution for it. AI with Xojo is not even half baken. It is rare and not even ready to be placed in the baking oven.
When using VSCode with Go, the linter will find errors as I type them. It will have its own suggestions but Copilot integration offers its own suggestions. Auto complete will also look at what you’ve already done and often, correctly, suggests a whole block of code that is just a tab away. Add a comment about what you want to do and Copilot suggests, again a lot of the time correctly, the code you want. Other IDE’s and languages can offer similar experiences.
The problem with Xojo is that their IDE is locked down and only they can update it. There’s zero way for any of us to modify it. Their auto complete has been a mess since I started with RealBasic 3.5 twenty-five plus years ago and you don’t find errors until you compile. What I described above would be a heavy lift for them if not impossible. They just don’t have the expertise nor the willpower to do what the rest of the developer world is already getting.
Sure, you can do you what you’ve done but YOU’RE the one doing all the work. AI and IDE tools are supposed to make our lives easier.
If there would be any other IDE in competition with them it would not be a good end for Xojo. While the IDE and their codecompletion and syntax check are so outdated and dead there is no chance to compete with for example Netbeans from 2005. That said I realize:: that is twenty years ago and they did not get that they are outdated. Since long time. And there can’t be any acceptance for this. Writing even without any AI the code completion shows y<ou syntax errors when writing the code and not after. Exactly that makes development much more productive. The facts that I have the documentation as inline hint if I want it so makes it also more productive. That is so with Eclipse, with Netbeans and with many others also.
TBH a LOT of the issues are to do with “Not Invented Here”
The IDE used to be written in C++
And it was all moved to RB way back when (2006 ish) more to prove you could write something complex in RB than anything
It may also have made it easier to find people to work on the IDE since you no longer had to be a C++ expert to do so
But it comes at a cost
The compiler is NOT tightly integrated in a way it can be leveraged to provide feedback as you type. The autocomplete system is NOT provided by the compiler - its entirely separate code in the IDE and IF it isnt identical to what the compiler does you may get suggestions that wont compile, or get no suggestions for code that will compile.
And thats just the start of the issues
But REAL / Xojo get to say “The IDE is made IN RB/ Xojo”
Not sure that marketing point is that valuable any more
Maybe at one time it was
An IDE based on JetBrains IntelliJ platform could probably be created and then leveraged to provide a much better experience since its already able to leverage AI and is quite extendable
Does anyone who writes C# using JetBrains Rider care that Rider ISNT written in C# ?
Or that their PHP IDE isnt written in PHP ?
1 Like
No, nobody cares. But that was a decision which went the wrong way. They could develop somehting else in the meantime. Listening that it costs hours to compile…sorry. JetBrains IntelliJ and also Netbeans costing both not that much tiome to build and compile. Netbeans takes even a bit longer to build. But at the end we are speaking about 4 or 5 minutes instead of hours. That shows that it is not a good Idea to use Xojo for complex projects.
at the time the complaints were often that Real Software development team didnt see the issues users were seeing because they didnt use the tool all day every day
They wrote in Visual Studio and Xcode or whatever tools and built the IDE compilers etc in C++
So the thought was that IF the IDE were written in RB then the devs would use RB all day every day and they see more of the same experience users had
Not an entirely unfounded expectation
BUT RB and Xojo have spots where they are not well suited nor perform well enough
Let me say it so: it was a bad and also stupid decision. Instead of going that way it would be better to take care of better testing and listening to the users. And here we go. Testing is even today a leak. They do nothing. They only speak about: we are the ones.
C++ specialists are better to hire. Xojo specialists you may find a hand full on this planet being able to work on it. C++ you will find a million. I can’t understand how comes that they thought that they will be better.
In my opinion it is more or less so that they decided: ha, that we can do in house without a specialist so let`s do it. BANG. So GP by self could work on stuffs what made it not better.
Again I think at the time it was to make sure that the team experienced the same issues users did
The goal wasnt horrible
But the reality has turned out to show that REALbasic /Xojo isnt up to certain aspects of such a complex piece of software
The Code editor has always been iffy esp with large chunks of code
If they’d made that a plugin then speed might not be the issue it is today where it seems to have been modified with a number of timers which make the experience weird and IMHO worse than before
And the hope was, when they found such things that they would fix/enhance/upgrade RB/Xojo to be able to do it well and thus benefit us all… which did not happen!
- Karen
Spot on. They were more interested in squashing dissent. Ironically, Dana is gone after banning people and hiding posts and threads. Maybe if they listened things would be different.
It still amazes me how I rarely read about Xojo on the web or in publications.
Imagine if they fixed bugs and marketed instead of berating customers.
1 Like
Oh there were a lot of bugs fixed before they ever left the shop
But what didnt happen was things NOT used in the IDE (reports, iOS,web apps, console apps, etc) didnt get a lot of kicking around because there was no compelling reason or need to. They weren’t used in the IDE at all.
So only the very core controls got used a lot (there are several standard list boxes in the IDE in various places, message dialogs etc)
The switch to the new Xojo UI meant that a LOT of controls were completely custom written (the navigator, the property inspector, and several others) that were NOT part of the standard toolkit so the amount of desktop controls that got used a LOT diminished some
And none of those new controls was generic enough to add to the default set of controls for everyone to use
That sucked
2 Likes
Which is the “problem”. in any product (ANY) all items that are “customer facing” need to be subjected to a strenous QA process.. .some that we all know Xojo doesnt have a clue about
3 Likes
Absolutely agree
Pushed as hard as we could of that and .. well ..
It never happened
Inertia ? Complacency ? Reliance on “they’re good coders they will test it themselves” ?
All of the above ?
It got to be too much
What I meant was not primarily UI stuff. I was thinking about performance/reliability bottlenecks both in each platform and across platforms… (I was only concerned with desktop)
One expects some degree of UI issues across platforms, but non UI stuff should be performant, rock solid, underlying technologies kept current AND ensure it behaved the same way as much as possible X-Platform for non-UI stuff.
If Xojo concentrated more on that, (if it meant working on the compiler or the libraries used) I think it would have been in a much better place than now.
- Karen
Again IF the IDE used it and there was an issue it probably got looked at
Esp if I happened on it because I’d hassle William or Joe about it 
If not then it was probably looked at if it fell into the various criteria : Pro+ user, paid fix, lots of users reporting it, etc
Lets just say that losing Joe was a decently large hit for ALL the criteria you listed
Not that no one else cared but he was almost obsessive about those things
And that was good
1 Like