VB History- effect on Xojo?

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?


1 Like

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

1 Like

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.


1 Like

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.

1 Like

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

1 Like

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 :stuck_out_tongue:

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

  1. A project schema (one for each platform)… takes 2 seconds to create each one
  2. Compiler directives in the code base to fence off code that is platform specific. iOS and tvOS share ALOT of stuff, so usually the directive is #if !os(macOS), where some #if os(iOS) and #if os(tvOS) sprinkled in

So I don’t see Xojo needing to handle a single code base much different

1 Like


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)

1 Like

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.



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 :slightly_smiling_face:

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 :stuck_out_tongue:

It was a strategic decision senior management had to take.