On TOF there was link a link which contained a link to an article on the history of VB…
That article quotes a blog post made on a Microsoft blog about the transition on VB 6 to VB.net. It said:
Of course Xojo has operator overloading and polymorphism, but why do I think that Geoff read that post in 2012 and took it to a extreme?
-Karen
Interesting read! Thanks!
The assumption in the TOF Thread is that VB6 died
Trust me its far from dead
There are still ways to use & create brand new app using VB6 even this long after its official discontinuation by MS
Do you mean “and tried to turn Xojo into the tool to enable fighter pilots” ?
If so I’d suggest you’re way off
They’ve steadfastly refused to add those things that would make it a fighter pilots tool
Lambas ? Closures ? Async Await ?
And the one serious attempt to refactor the existing monolithic framework that would have made it possible for the compiler to strip out even more unused cruft, theXojo framework, was shouted down by folks who lamented the “wall of code”
Xojo started out with promise and then got stuck as a “prosumer” (?) tool by refusing to add things that “average users wouldn’t understand” - regardless of whether they were optional or not (like the Xojo framework)
So now we get the same gigantic monolithic everything in the global namespace framework where every time they add something the risk that it clobbers existing code because the framework just takes over some method or control name remains exactly as it did in 2012
Xojo hasn’t moved “forward” very far
Actually You took that 180° from what I meant! (I still have to learn people don’t think they way I do!)
By 2012 the product already operator overloading and polymorphism IIRC… so already was more “advanced” than VB6…
The blog writer was saying that the reason VB.NET did not gain the traction that VB before it had is BECAUSE they listened to the
pros and people who wanted advanced features (a small percentage of the user base) … and the blog writer believed that was what made it less appealing to “citizen developers” - though he did not use that term.
I don’t agree - although I never used VB (I was on a Mac even at work), I suspect it is how MS did it more than the added capabilities.
My point is that Geoff might have read that blog back then and came to agree with the blog writer and so came to believe in terms of profitability adding such features was not a winner… The opinion in the blog alines very well with how Geoff has managed Xojo since then… (in prior years, that did not seem to be the case)
It may also be why he came to believe he did not need a complier expert on staff with LLVM.
-Karen
Fair
It wasnt clear to me which way you were thinking about that
RB/Xojo did extend itself about the 5.5 / 2006 time frame to have operator overloading and many other “advanced” language features
Introspection came along after that
And no cities developers were chased away by them
IMHO what did VB.Net in was the complete rewrite of the language itself
Instead of it being “VB that now compiles to .Net” it was a complete overhaul of the language that users had come to be familiar with
So instead something like RB’s transition from compiling for Carbon to compiling for Cocoa, with the language unchanged, VB6 to VB.Net was such a jarring overhaul that many balked
That said VB6 is far from dead
I used VB6 (from when it was VB3) and liked it… But when VB.NET came out, it was just their “C” product with a different lexical… I used it because I had no choice, but never thought it was a good direction to have taken. When I switched to Mac (Microsoft VISTA was the reason), I needed something to use personally, and found RealBasic… which was great until it wasn’t
Since I was 100% commiteed to the Apple platform by then, I decided to scope out the new fledgling SWIFT, and while that journey was a bit rocky at times, the current state of things (in my opinion) is FAR FAR ahead of any place Xojo has ever dreamed of.
Tooling - yes
x-platform framework though ?
Xplat? no, but then neither is Xojo really. Multiplatform? perhaps… XPlat… not really
And then what percentage of Xojo clients care? Some do, yes, but I bet most don’t.
Inside Apple’s ecosystem 100% yes. Swift on other OSes is still in its infancy.
I am definitely not a professional coder but now use closure, async await and other features, because Swift makes it available and accessible to coders of all levels.
Compared to Swift and Xcode, using Xojo feels like riding a 20-year old bike that has a number of technical defects.
Xojo has some story about xplat there
I’d say more than swift does at least in terms of UI toolkits
Swift console apps can run on many targets already
This is akin to MS claiming “cross platform” when things ran on CE, ME,NT
Its silly
Of course it bloody well better be x-plat between Apple Ones - they write em all and they are all derived from the same base system with specifics for each (iOS, macOS, tvOS, watchOS)
Supposed THIS is precisely what Xojo purports to do (or did)
We do the stuff that users cannot do for themselves
Like build a framework, fix framework bugs, the compiler, etc
But they have missed those opportunities with things like async await etc
The one thing that Swift can do that (@Torsten_B eluded to) was have support for ALL Apple devices in one code base. Something that Xojo can do only for its desktop platforms (and to be honest in a similar manner) … But for Xojo to meet the definition of XPlat, it would have to do that for everything (desktop, mobile and web), and of course it doesn’t
This is a function of Xcode and how it manages projects as much as anything - not Swift itself
But yes that Xcode makes this possible is SUPER nice !
Xojo could do well to try & get to that as well
I’d started some work in this vin but have no idea if it still exists or not or if anyone ever did anything with it
I think It could do that but would take some effort because the legacy or projects that already exist would be nice to preserve
They could ask me if they cared to know how 
In the case of Swift (same as would be with Xojo), There is the project file, which is created/edited by the IDE (or Xcode), and sent to a compiler… the XPlat in Swift is handled by two things
So I don’t see Xojo needing to handle a single code base much different
Exactly
That Xojo’s IDE cant handle a single project file having more than one output type in it is really where the problem lies
TBH it always made me wonder, given what I knew at the time, why Xojo used different project types for different outputs.
Wasnt for some time that I came to realize that this might actually have been the antithesis of what they intended. But since there was lots of code in place already it was just easier to keep doing that and add a new project type for Web, then iOS, etc than to go back and fix it so you could have several types of targets in one project
20/20 hindsight I guess
The Xojo IDE’s inability to handle this is partially my fault as much as anyones
EDIT : correct a typo (given hat I knew) to (given WHAT I knew)
I think ether most or a large minority do… After all free (Mac tools and Visual Studio Community edition on Windows) with access to all platform features is pretty attractive even if more difficult to learn.
-Karen
ok, the issue is OUTPUT type, not INPUT… that actually might be what the Xcode schemas do, an Xplat project needs one for each output platform, and you choose the one to compile with, its just a mouseclick so it is super easy
Not more difficult, just new. Brain gym 
Yes
Each “project type” in Xojo results in a different output type - desktop, console, web, iOS, android
There’s no compelling reason that has to, or had to, be that way
It just IS - because thats how the original couple of targets (desktop & console) were set up
So for every new addition after that it was just easy to perpetuate that set up
but again, there’s no compelling reason that has to be that way
I came to realize this well after I started there and by then it would have been such a massive rewrite of the IDE to NOT do this that it was just never done
But it could be
Maybe it needs to be a NEW IDE that can ingest an old project but spits out a new type on save
Or just adding something to existing projects
Really hard to know as I’ve never spent time looking into the details of it and that IS kind of hard now
It was a strategic decision senior management had to take.