The benefit of having a real Roadmap

[ivan]

Another key to the success of this companies is that they have REAL roadmaps with actual release dates.

[npalardy]

you mean like

What's next in .NET? | .NET

oh look ways to get involved in planning even !

Swift.org

Would be good to see Xojo do something like those public discussions ahead of time instead of getting to BETA to “surprise everyone” with some new feature thats so far down the road the likelihood it could get altered/debated/fixed is effectively 0

< cough > API 2 … DESKTOP control renaming … < /cough >

[ivan]

@npalardy

you mean like

Yes, the oposite of the “Maybe sometime in the uforeseable future but dont count on it” from xojo.

@npalardy

Would be good to see Xojo do something like those public discussions ahead of time instead of getting to BETA to “surprise everyone”

It actually surprises me the many times Xojo had said: yeah, it sucks but it is to late to change it.

@npalardy

DESKTOP control renaming

actually for this where public discussions, many people said it wasnt going to work but (not for the lack of imput, but pure stupidity), they didt it anyway and had to retire a whole release LOL)

Cant understand why some people were so excited when they anouced the “new” controls when it was obvious that it was just the way to fulfill the foolishness.

[npalardy]

I’ve given up trying to guess at what motivates them to do the things they do since they seem immune to feedback from their user base

Unless of course its praise

[bkeeney]

Roadmap is only a guide if you have real processes in place for software development. Xojo does not. It’s very much seat of the pants, let’s start down that road with our first idea and by golly, even if it’s a bad idea, we don’t have the time/patience/fortitude to change directions.

[bkeeney]

I mean, Go debated for several years, before closing their loop variable ‘bug’. For more info on it see Fixing For Loops in Go 1.22 - The Go Programming Language. We don’t, and won’t, get anything like that with Xojo.

[jalih]

@bkeeney

I mean, Go debated for several years, before closing their loop variable ‘bug’. For more info on it see Fixing For Loops in Go 1.22 - The Go Programming Language . We don’t, and won’t, get anything like that with Xojo.

Go chose to remove some potential programmer errors at the cost of a little performance loss. Personally I am not sure that the change was necessary, it’s not that hard to make a copy of a loop variable.

[npalardy]

[npalardy]

And here we go
More surprises! revealed in Germany
Copied from MBS Xojo Developer Conference: Thursday - Events - Xojo Programming Forum

Database connections without code are coming
They show up in the ide and have separate connections for dev, alpha, beta and final
They can connect on start

meh

Xojo shows off an AI help chat bot to answer questions based on the Xojo documentation.

meh

Xojo is getting pre-emptive threading.
opt-in via Type property and can be changed at runtime.
Not recommended for beginners since you need to use Mutex and Critical Sections.

Xojo Inc. will go through framework classes to make some of them thread safe, so you can use them safely in the preemptive threads. Also add-on vendors will have to check which classes and be adjusted to support this.

You will probably play with this and report problems where it crashes.
Don’t touch UI from preemptive threads! This will raise exceptions or crash.

Debugger will only do cooperative threading, so preemptive only works in build applications.

This is kind of a surprise as it hasn’t been on the roadmap!

This is much like workers which is frustrating as hell since what works in debug MAY NOT work at all in a build
Preemptive threads are hard enough
NOT being able to realistically debug them IN ACTUAL USE will be super shitty

Libraries are coming to share code between projects
Android plugins for instance will use this

This has been on the “coming soon list” for many many year
Since before I departed and that was 5 years ago

[bkeeney]

@jalih

Go chose to remove some potential programmer errors at the cost of a little performance loss. Personally I am not sure that the change was necessary, it’s not that hard to make a copy of a loop variable.

For a language that prides itself in being easy to learn and understand that change is absolutely a good idea. I mean, sure, the workaround is not hard but it should not have been needed in the first place. The only reason I learned about it was through a code review where I flagged the copied loop variable. My flag was wrong (and the explanation took me down the rabbit hole) and I got schooled by the architect on why it was correct but it’s not immediately obvious.

My point, is that the change involved hundreds (if not thousands) of comments from the community and the plusses and minuses of doing so. They thought carefully about it and added a new test so that existing code would at least be warned if it impacted them. Xojo does not think long and hard about changes. Doesn’t consider the impact to large existing projects. They write half assed implementations that don’t work like we’d expect and then spend years fixing said implementations.

[Torsten_B]

Threads - Swift has concurrency since years, Java has it since many more years…Xojo’s limping along well behind the crowd. Will be another eternal beta, like API2 and DBKit.

A shoutout to @MonkeybreadSoftware! Christian knows how to organise and run a conference!

[ivan]

@npalardy

Database connections without code are coming

Wow Xojo is getting closer to what VB had almost 30 years ago

@npalardy

Xojo shows off an AI help chat bot to answer questions based on the Xojo documentation.

The documentation sucks, cant trust an AI trained with that.

@npalardy

NOT being able to realistically debug them IN ACTUAL USE will be super shitty

More half baked stuff just because is to hard to change the debugger for the current team?

@npalardy

Libraries are coming to share code between projects
Android plugins for instance will use this

Another BIG idea they had with no input from user. Kind of waiting the disappointment.

[HalGumbert]

It’s all still vaporware until it ships. If it’s like other things, there will be no discussion about how the features will work before it’s baked in. Then it’ll ship and likely be half baked due to no dicussion.

Just like how API 2.0 had no discussion or conversion map before just “changing stuff”.

Nothing has changed. And nothing will get better until Geoff is no longer in charge.

[Jerry-Fritschle]

Preemptive threading? Sounds like the 1990s have arrived.

[ivan]

@Jerry-Fritschle

Preemptive threading? Sounds like the 1990s have arrived.

Multicore CPUs and Multithreading was more like a 2005 thing

[npalardy]

yeah they’ve talked about this sine way before I started working there and the answer was ALWAYS “we need to make the entire framework thread safe” and that has always been such a huge undertaking that its just never happened

No idea what they think has changed enough to make it possible

For what I need I create a helper in Go, Rust, C#, Java or some language I can debug threads in and then just use Xojo as the UI

[npalardy]

Huh should tell that to my 1995 self writing Multithreaded code on Vaxes in PL/1 and other langs, or in Java on Suns

its been around WAY longer than what showed up in desktop OSes

Either way its been a LONG time coming and may still be

[Tim]

@npalardy

No idea what they think has changed enough to make it possible

Clamoring for dear life.

[ivan]

@npalardy

its been around WAY longer than what showed up in desktop OSes

Wherent those multi CPU instead of MultiCore? And in hardware not for consumer use?

[npalardy]

some were multi cpu for sure