This makes no sense. The name is just marketing, Xojo has nothing to support any of the PI features, it is just good look that Linux Apps compiled for ARM run also on the PI
Ditch Mobile if they cant have a decent product
A full year of Bug bash. Starting with improving the IDE speed and accesibility.
After that Bug bash, focus on the standard features they lack.
And finally, release a propper LTS version with montly fixes
TBH THIS would be quite reasonable as trying to retro fit some things into the existing code base would be hell. There are assumptions baked into code that is very old that preclude certain things from ever happening.
You shouldn’t. It is Xojo Inc’s duty to get this in order before releasing it. No alpha-beta business.
Yeah a complete rewrite at this point, or more exactly a complete re-engineering, is almost a certainty.
I’ve had the rare pleasure during my career of building the same complex processing system 3 times for 3 different companies. In efforts 1 and 2 (both very successful), I inherited some baseline implementation but the third time’s apparently the charm as I inherited nothing. What I found is that I did not fully appreciate how hamstrung I was working around design decisions that had been made even for just a year or so before I came on. It isn’t as if the initial implementation was ugly or fundamentally flawed, yet … for example someone built a data intake system that loaded raw data to a .NET DataTable, not considering that eventually files too big to fit in memory would be the result. I think back in the day you hit that wall at around 1.5G of memory consumed by the DataTable – it’s better now but still I had to craft an adapter pattern that would “chunk” about 10K incoming records at a time and spool them out to a DB temp table … it worked transparently to the client code which could still talk to the DataTable but it was still a kludge around a fundamental lack of foresight. The temp table overhead, the extra reading and writing, the extra management code all took its toll – and it’s all gone in this iteration. Gone, too, is MDAC and OLEDB and .ini files, replaced by a fast-forward CSV reader of my own design, with OS buffering optimized accordingly.
The new system runs at least twice as fast (in some situations 3 and 4x faster), has less runtime load on the DB that’s serving up API responses, has a more flexible internal design. Even the DB itself is relentlessly and ruthlessly simple compared to the old one, partly just better foresight in the design, partly leveraging functionality and system resources not available in 2008.
Now if I extrapolate from that experience to a product like Xojo that isn’t just encumbered by a couple of design flaws but many, and by lack of investment in the right things … and smoke and mirrors to provide something resembling functionality that would require a lot of rewriting to do correctly … I am just about drop-dead certain that the existing design is hopeless crap. Significant chunks of code could probably be salvaged / reused, don’t get me wrong, but …
Consider just one aspect. I’ve mentioned another idiosyncratic / semi-retro product here before, Lianja. Lianja lets you choose from several languages (going by memory, JavaScript, PHP, FoxPro /Xbase, C#) on top of its abstration / framework / designers. We DO have development systems / IDEs married to a single language (e.g., Swift) but why limit yourself if you don’t have to? Lianja brings in the greybeards who know and love Xbase, but by supporting the other languages it’s sending the message that it’s not JUST about that. If there are 3 or 4 choices including at least a couple of major / popular ones, then it sweeps aside objections to having to learn a new language with possibly poor or flash-in-the-pan market uptake – or that you think will damage your brain to even use it.
But Xojo is tightly bound to a specific language – nay, a specific DIALECT of that language of its own design – and can’t take advantage of any 3rd party ecosystems out there (pricey captive library vendors don’t count here). If you really believe in that dialect, fine, go ahead and offer it …but providing other bindings to other major languages only makes sense. But right now that would be cumbersome (in practical terms impossible) for Xojo. The only extensibility mechanism is a C/C++ plugin. With that, sure, in theory you could put in shims/adapters for other language bindings but it would be inelegant at best and slow at worst. I’m talking, pick the language at the project level and provide first-class code completion and documentation right in the IDE. That, Xojo can’t currently even properly do for it’s own lonely little language dialect.
I’m sure that anyone thats worked on the product over the years has their own ideas about If I could go back and do this over I would do …
I know I do
And thats why the first cut of anything should be thrown out
You learn a lot - esp about how NOT to do it because you may end up painting yourself into a corner that you didnt think about when you started
I can think of a few places in Xojo’s IDE I have that sort of “gee if I had known this then I would have done it differently”
20/20 hindsight
Yeah I am sure that even going beyond the “second system effect” on my 3rd system there are things I’m going to wish I had foreseen despite an accumulated 27 years in the specific vertical out of 40 in my entire career. And part of why the third time’s the charm is that I have learned and grown over those years and have almost a muscle memory of what needs doing. So … when it comes to Xojo even if if it had been properly designed and built without all the web1/web2, api1/api2 thrashing … if this were an ideal world where it were still called RealBASIC and it had eked out a 3% market share and a healthy ecosystem and happy customers – by now it would probably be ready for at least an eventual / rolling complete rewrite. No system can endure for 20+ years without one, IMO. It’s just that the need is flashing-red-light critical now.
The force of FOSS languages is that there is a core team and many contributors, development does not depend on only a few people and one genius.
Planned additions and modifications are published as RFCs. Feedback is taken into account. Not exactly how Xojo Inc functions.
Indeed the FOSS methodology is more community driven
Community involvement is a BIG plus
Many points of view get represented - something that the MVP program seems to have severely limited . But that was BY DESIGN
- To act as an informal advisory committee. As we develop Xojo, we appreciate getting feedback in the early stages of a particular change we might be making, which is manageable with a small group. We are discussing our product planning with them and giving them very early access to features in development to get their feedback.
Well, at least one MVP was very busy with suppressing opinions that did not coincide with those of the supreme leader. It was a disgusting spectacle that made me leave TOF. And whoever was in charge of Xojo’s forum delivered a spineless non-performance. Shame on them.
There’s really nothing wrong with the language itself.
Some very bad decisions were made and I truly believe that it could have been a couple billion dollar company.
I am wondering if Geoff Perlman himself is reading the INN forum. Any idea, someone?
I am wondering because if he does, he should learn his lesson and take action.
I hope Xojo can be saved but like many of you, I am pessimistic about that.
The language (not the frameworks) maybe needed a few updates & additions
Async Await would be nice. True generics would be nice.
But on the whole “the language” - which is everything available in XojoScript - is reasonable
Its all the fussing around the edges & changes to the frameworks thats annoying(Open vs Opening and other property renames)
The IDE probably needs a complete rewrite as it has some assumptions baked into it that limit it
of course it would… xojo still holds the trademark btw. it’s the same lame (and wrong) argument I hear from ppl, who do not understand how free and open software works.
The fundamental thing to save Xojo is to focus on growth. You don’t grow by telling your biggest asset (evangelical and enthusiastic customers) to fuck off.
In order for Xojo to even begin to get this ball rolling again, they need to focus on the kind of customer who will go out of their way to promote the product and create resources to help other developers get up to speed with the product as quickly as possible.
In this industry, if you’re not growing, you’re contracting, which is potentially fatal.
Yeah I don’t think these ideas are viable. They scream “bring back the way it was” as if Xojo’s problems are entirely self-inflicted.
Xojo’s core issue is that it’s become well behind the competition. Decisions like API2 are symptom of that problem. A desperation move to feel more modern with the limited resources they have. They won’t be able to catch up by going slower, abandoning platforms, reverting decisions, or anything of the sort.
To catch up, they need outside money. I don’t see any other way. They need staff. Absolute minimum would be one developer per platform, one for the IDE, one for the compiler, a technical writer and bug triage, and a project manager. I’m not including support staff in this. That itself would be a decent investment, but I think they probably need more than that for at least a couple years, because there is a lot of catching up to do.
This happened because Xojo’s target platforms have exploded. It used to be that they had three similar platforms that didn’t change a whole lot. The team size worked well enough then. I started there in 2008, just a year after the first iPhone was released. Think of how computing has changed since then, and we had a larger staff than they have now. Mac and Windows evolve rapidly now, and they have three additional platforms that are barely similar. They are in a tight spot, and the small team size will not work anymore. It hasn’t in a while.
If I had to “save” Xojo - though I don’t agree they are doomed - without seeking an outside investment, it would be controversial. Given the team size without the ability to grow it, I’d have to ditch the native UI. I’d go the Electron route. Use Xojo’s cross-platform binaries, but build the UI from HTML that works consistently across all platforms.
The trouble with such a plan is it essentially kicks every existing developer to the curb. Success would require attracting a whole new set of customers, making it an incredibly risky idea. If the transition could be survived, I think Xojo would be in a more maintainable position. But it’s far from practical, which is why bringing on additional staff is significantly more realistic.
And hence fall even further behind by tying up the meager resources on some lipstick that chased away long time users.
-Karen
Well when 3-5 devs (xojo staff) and one stable genius are using the IDE - this is I would not consider as “dog fooding”.
Reminder to myself: Tech Industry is a pretty fucked up industry 
?? what is the competition ? it sounds like premade sentence
???
electron will outdated soon by others