Why Xojo?

Just wanted to add this blog post: http://pengwindev.blogspot.co.uk/2015/07/why-xojo.html

But you need to remember ONE VERY IMPORTANT fact in these type of PRO/CON comparisons…

The end result it not directly tied to the tool used to create it. It is tied to the COMBINATION of the tool AND the developer.

Can Developer A create an application with XCODE (ObjC or SWIFT) that RUNS faster than Developer B creating the same application with XOJO? Certainly. But if Developer B is better at optimizing XOJO than Developer A is at optimizing ObjC/Swift then the opposite is true.

Can Developer A create an applicatino with XCODE (ObjC or SWIFT) in LESS time than Developer B creating the same application with XOJO? Probably NOT. (possible, but less likely). So while XOJO doesn’t have the built-in tools for code-signing etc, the TIME to market is usually less (and since TIME is MONEY, one has to include that in the comparison as well)

So which is better XCODE or XOJO? The answer is of course… wait for it

IT DEPENDS

Nice review. As I said in a comment on your blog, I don’t think referring to the Xojo language as BASIC makes sense. It shares very little in common with BASIC. It uses the same principle but language-wise, it’s more similar to Java and VB.

Isn’t VB a BASIC language?

@Dave S that was kind of my point. As I said in the blog, using Xojo has actually made me a better programmer by making me optimise my code. And your right that, whilst even having to use third party tools for some things, I can still create most applications, start to finish, in less time than it would take in ObjC.

@Geoff Perlman I only refer to Xojo as BASIC due to its heritage. I am well aware that it has evolved beyond that, but (for me at least) it still a “BASIC type” language in the same way that VB Is.

Marketing aside, and while indeed Xojo is a very modern OOP language, it does have origins in Basic. Let alone by the vocabulary and a lot of the syntax. Should that be taken against it ? I think not. But language snobs are what they are : ignorants in disguise. I doubt denying Xojo’s family roots will change their attitude.

One thing missing from Mark piece is the fact that using Xojo is a darn good competitive advantage.

An opinion:
The direction of the new framework is making it less usable and ‘friendly’.
I feel it’s also going to eat into the productivity that Dave talks about.

[quote=202802:@Jeff Tullin]The direction of the new framework is making it less usable and ‘friendly’.
I feel it’s also going to eat into the productivity that Dave talks about.[/quote]
Maybe.

If so, it will for take some days / weeks / months to be up-to-date and then we will know if the change was good for our applications (speed / lower footprint, etc) only or also for our productivity.

I cannot talk about that because I do not use it.

Part of that will also be questionable for the 32/64 bits changes.

On the other hand (with fun):

Yes Mark, this is a good question: “Why Xojo ?" I sait it again: “Why Xojo !" (with fun in the voice !)

[quote=202802:@Jeff Tullin]An opinion:
The direction of the new framework is making it less usable and ‘friendly’.
I feel it’s also going to eat into the productivity that Dave talks about.[/quote]

For historical reasons, RB/Xojo has for the longest time avoided changing its syntax. I often cite this 2002 source code I exhumed in 2013 that went into the MAS with probably no more than ten lines changed.

Problem is, new frameworks do require namespaces, and evolving the language as well. I will risk again a comparison I made during iOS beta with mixed appreciation. Until the new framework, it was amazing how many users switched to Xojo from VB6. Fact is, to evolve, a modern language does need namespaces, as well as higher data coherence. Microsoft made the switch back in 2002 already with VB.NET which, like our new framework, used namespaces and new syntax. VB users where less lucky than current Xojo users, as they had to move directly to the new framework. Xojo Desktop and Web still use the classic code, and will as I understand, do for a a very long time.

New framework only eats productivity when used. Or when discovered. If one simply uses Desktop and Web as ever and does not need new framework things, no need to learn : it is the good old tool. My famous 2002 code still runs unchanged. And I have no intention whatsoever to rewrite it for the new framework until the writing is on the wall. At which date the app will probably be obsolete anyway.

Even if iOS did not use the new framework, it would require a learning curve : smaller screen, different controls, different UI concepts. Lest not forget either wrapping techniques such as XojoiOSWrapper I was glad to see mentioned by Paul Lefebvre in his XDC presentation. I was able to use most of the code of a 2013 app just wrapping new functions in the syntax of the classic framework, instead of rewriting all. That is a valid way of keeping assets, while making the transition to the new framework.

Now, for the “usable and ‘friendly’”, I will concur with Xojo engineers. Being too friendly is like not telling a friend his laces hang. He will fall to his face eventually. Too much tactfulness is sometimes not the best service. The classic framework string and its encoding quagmire being an example. Text requires a bit more work, but does away entirely with the hateful question mark in a lozenge. Functions that return incorrect values because they are too ‘friendly’ is another one, like a friend who tells you what you want to hear. Then ensues difficult to find bugs because instead or going up in arms, the thing swiped the problem under the rug.

In the transition stages certainly, but once autocomplete becomes “using” aware productivity will resume. Of course using the full namespace does autocomplete now, and you are not compelled to use any of the new framework for desktop/web projects.

I thought the blog was well done and balanced.

Thanks @Mark Oxley.

I am not sure of thet.

I agree with that. IMO the new framework will make the product less approachable to those new to programming.

IMO it will also make it less RAD because of overly trying to protect us from ourselves.

  • Karen

Agree, we should shake off any association since Xojo is far beyond what the BASIC, referred to here, ever was.
Every once a year I have to maintain some VBA stuff (MS Excel and MS Access) and every time I get crooked toes of it, and be happy being a Xojo developer after all.

@Wayne Golding - I’ve read last week that, as a Windows developer, already adapted the new framework in you libraries. That sounds great. It means that you are ready to receive the 64-bit compiler in you projects.
I’ve got two questions:

  • how did you organize updating your libraries ? (code change - testing etc.)
  • how are you going to deal with outstanding projects you have ? (updating to new framework for next release would take quite some effort and could introduce new bugs. )

Is the new framework almost complete for desktop?

@Joost Rongen When I first started working with WE projects a few years ago I embraced the Observer Pattern methodology. This has meant that (largely) I have been able to upgrade my business logic with little impact on the observers being windows, containers, webpages, webcontainers and now ios views. When I say largely that means I’ve had to update the observers to convert text to string etc. But this is simply a matter of analyzing the project & fixing the reported issues.

I did have to write my own encodebase64/decodebase64, encodehex, and a mechanism to generate a sqldate from the new date class. So there was some pain, but then the new framework introduced http1.1 at just the right time to save my bacon, so that eased the pain somewhat.

However my applications are business apps, & beauty isn’t an issue (although it’s becoming moreso). Luckily the bod’s designing the OS UI’s these days are attempting to make it look as ugly as my apps.

Thanks for your reply Wayne. Although it’s just fixing reported issues as you say, guess it took you quite some time. But I am curious what approach you take concerning applications in production in the field and only now and than need some feature-updates or fixes. Are you going to move these Window- and webapplications to the new framework too ? The customer won’t even notice any difference.

[quote=202802:@Jeff Tullin]The direction of the new framework is making it less usable and ‘friendly’.
I feel it’s also going to eat into the productivity that Dave talks about.[/quote]
Can you provide some examples?

[quote=202847:@Karen Atkocius]I agree with that. IMO the new framework will make the product less approachable to those new to programming.

IMO it will also make it less RAD because of overly trying to protect us from ourselves.

  • Karen[/quote]
    Can you provide some examples of this?