Make no mistake, I got your point. But Xojo is a development tool. Respectfully, your analogy to finding alternate uses for oatmeal and pool toys was quite extreme–i.e, quintessential “straw man”. 
In defense of Xojo, I will point out that neither of two very popular programming languages, JavaScript or Python, have multithreading built into the language either.
Both of them have ways to do concurrent threading, but with many limitations as well.
1 Like
Both of which are sort of scripting languages where then usually the host application of the scripts splits it into threads. You do not really see full applications made in Python.
1 Like
If Xojo is worried about giving this to the masses, make it a Pro feature. Then your basic user base don’t have to worry about it. The user’s who actually use Xojo to make money can use this very useful feature and have the skillset to know what they are doing. I am constantly looking to see where .Net is with cross platform, currently still terrible, but they have 2 huge things I need, Preemptive Threads and Class Libraries. Xojo is still a long way ahead of the game for me over .Net but falls short on these two items. I see Libraries coming, soon I hope. I can “Just” get away with helper apps, but I really would like background threads to speed up the GUI in my app.
Accommodating to the lowest common denominator alienates the more advanced users.
3 Likes
True, the lowest common denominator approach is terrible.
Besides, IMO it is a good business practice to target the pro developers because they are those who make great, commercial apps that can shine a light on the framework used to build their product and thus attract more users.
6 Likes
I think the answer to that question varies on who answers it.
From my perspective, I would rather Xojo have worked on preemptive threads and a ton of other improvements to the quality and capability of Xojo made applications, directly benefiting the products I sell.
Xojo felt a good use of their time was API 2.0, Web 2.0, DesktopControls and a less helpful Language Reference. These things offered no actual improvements to the end result, instead creating unnecessary upheaval to existing customers and kneecapping newbies.
I haven’t renewed my Pro license since 2019, Xojo knows how many others also haven’t. Maybe to them it is worth it, to try entice some of them back (speculating that there are more like me).
10 Likes
For API 2.0 and DesktopControl, it has vaguely been mentioned that it could harmonise several platforms in Xojo code (I don’t recall if this was official, or just someone guessing), but I can’t see any improvement from these. Worst, API 2.0 splits the community and DesktopControls, among other defaults, make typing them harder (autocomplete with ton of objects with the same prefix is a pain) and easy confusion. Frankly, I don’t see how this is an improvement, now or in the future (and we don’t have any hint given by Xojo about how it’s a progress).
11 Likes
Let’s try to get back on the topic of preemptive threading rather than rehash API 2.0 arguments again.
5 Likes
In nearly every case I can think of when a user’s app is crashing due to something in the Xojo language or framework, we consider that a very serious bug.
After a user reported it, I filed an issue a month ago about a hard crash in macOS using a TextArea (#71476, Hard crash using TextArea.textColor when there is a lot of text). I created a simple project and it was reproduced. I hope this is considered a serious bug.
No, it’s not. If you are the only affected person then the bug is your problem. This is the reason why using the MBS plugin is so critical.
1 Like
It affected at least one of my users (who first reported it), if that counts. It’s an edge case, to be sure, but it’s a hard crash using pure Xojo code. FWIW, running on a new M2 Mac Mini with macOS 13.2.1 I don’t see the hard crash (there is still an OOB exception), so it may be OS- or CPU-dependent.
On the contrary. If there’s a bug report that produces a crash and it is easily reproducible, I’d expect it to get solved very quickly.
1 Like
FWIW, I’ve now found that the hard crash occurs in Ventura 13.2.1 on an Intel iMac but not on an M2 Mac Mini. I’ve updated the Issue with the crash log.
I’m asking one of the engineers to look into it.
Thank you.
What I really want to see is a better way to utilise the shift to a multi core world. All vendors (Intel, AMD and Apple) are moving to more and more cores. Xojo’s Workers are a nice idea but they do not achieve the required goal since they have too much memory overhead and debugging them is challenging to say the least.
If, as @Björn_Eiríksson sugggests, there is an easy path to limited improved threading with caveats then why not pursue it for those of us that need it? I understand crashing is possible but this level of programming is way above the typical Xojo user and I don’t understand why you would treat your pro users like children. As @Kem_Tekinay and others have stated, there are already plenty of ways to crash Xojo apps (declares and Ptrs to name two), not to mention long standing bugs in the framework we all work around.
7 Likes
For what it’s worth, if Xojo does give us preemptive threads, they’re unlikely to be debuggable at all.
1 Like
I think thats fair and all right. The non debuggable. It took Visual Studio years to make thread debugging nice. So I do not think we would expect much in that regard.
1 Like
One does not need to be a pro user to be able to do (or learn by doing) that level of programming… and for those who really only care about desktop (or Web or mobile) but need preemptive threads , it’s another reason to move to another tool.
It should be a core feature of the language IMO as are Pointers and declares…
In the old days, believe it or not, Xojo initially made made Container controls a “Pro” (at the time it was called something else IIRC) only feature…
That IMO was a mistake, a they eventually realized after a few years…just as including this feature only in the Pro edition would be a mistake IMO…
-Karen
2 Likes
I actually think this would be the correct approach, at least initially. Get it out to a limited subset of users, who are more invested in Xojo, possibly more proficient, who will be more likely to engage with feedback and troubleshooting and pre-release work. It may take quite a while to hammer all the issues out of preemptive threads, and ideally you’d do that with as few people as possible. The Pro license holders thus get a little extra value out of their higher purchase price and Xojo theoretically offers up another reason for people to get that level of license.
Maybe they eventually release it to the general userbase, but if you look back at the people who have been banging the pre-emptive threads drum on this thread – they’re almost all Pro license holders. It could become a compelling reason to upgrade.