Why Xojo?

  1. ‹ Older
  2. 4 years ago

    @Ulrich B And you're right: Using the compiler pragmas usually is no real booster.

    In my experience the #pragma statements DO make a huge difference in speed. William, which ones did you use in your code?

  3. Eric W

    2 Aug 2015 Pre-Release Testers, Xojo Pro

    OS vendors can discontinue tool support/sponsorship when it doesn't suit their larger business objectives. So it's super-impressive that we can mix classic and new framework calls in the same line of code. Quite frankly I almost fell over when I saw this because I'm not used to being treated by a tool vendor this way.
    The ability to compile code that's 10 years old with little or no modification, potentially even for another platform, is another aspect of how my investment can be protected.
    No wholesale rip-and-replace saves big $$$ in both development cost and developer training cost. One only needs to get burnt once to realise the value.
    If anyone offered a dev tool insurance policy for all the other tools out there by offering these Xojo benefits for the price of a Xojo subscription (which of course would be an impossible risk for the insurer) it would be snapped up. But for that price we get the tool itself with the vendor's support. When viewed from this perspective I think Xojo is very hard to beat.

  4. William J

    2 Aug 2015 Pre-Release Testers

    Gregg, I normally use pragmas as below:

    #pragma DisableBoundsChecking
    //#pragma Disablebackgroundtasks
    #pragma StackOverflowChecking False
    #pragma NilObjectChecking false

    I have to be careful about using the disable backgroundtasks pragma or my GUI will become non-responsive.

  5. Karen A

    2 Aug 2015 Pre-Release Testers

    @William J I have to be careful about using the disable backgroundtasks pragma or my GUI will become non-responsive.

    Might that be a case in a GUI app (when using the pragma Disablebackgroundtasks) where judicious use of DoEvent calls may be safe and justified?

    - Karen

  6. Michel B

    2 Aug 2015 Pre-Release Testers RubberViews.com
    Edited 4 years ago

    @Eric W OS vendors can discontinue tool support/sponsorship when it doesn't suit their larger business objectives. So it's super-impressive that we can mix classic and new framework calls in the same line of code. Quite frankly I almost fell over when I saw this because I'm not used to being treated by a tool vendor this way.
    The ability to compile code that's 10 years old with little or no modification, potentially even for another platform, is another aspect of how my investment can be protected.
    No wholesale rip-and-replace saves big $$$ in both development cost and developer training cost. One only needs to get burnt once to realise the value.
    If anyone offered a dev tool insurance policy for all the other tools out there by offering these Xojo benefits for the price of a Xojo subscription (which of course would be an impossible risk for the insurer) it would be snapped up. But for that price we get the tool itself with the vendor's support. When viewed from this perspective I think Xojo is very hard to beat.

    Anybody who invested in VB6 can attest to the traumatic experience of having to jump to namespaces and new ways of doing things, in fact kind of a new language, like being thrown in the pool without a chance to get one's feet wet first. Not to mention losing one's VB6 sources.

    Most recently, the implementation of the sometimes convoluted iOS architecture in a rather elegant and easy to use IDE and framework is a feat that demonstrates Xojo's amazing know how.

  7. Kevin G

    2 Aug 2015 Pre-Release Testers, Xojo Pro Gatesheed, England

    @Karen A Might that be a case in a GUI app (when using the pragma Disablebackgroundtasks) where judicious use of DoEvent calls may be safe and justified?

    - Karen

    Not sure about the other pragmas but disableboundschecking doesn't actually do anything now. I discovered this when migrating some code from RB to Xojo. The Xojo version would sometimes crash with an out of bounds exception while the RB version never did. It turned out that the pragma in RB was actually masking a bug in our code so the fact that Xojo didn't respect the pragma turned out to be a good thing in the end.

  8. Tim H

    3 Aug 2015 Pre-Release Testers Portland, OR USA

    @Karen A Might that be a case in a GUI app (when using the pragma Disablebackgroundtasks) where judicious use of DoEvent calls may be safe and justified?

    Gaaaaah! Blasphemy! I must sacrifice a chicken to cleanse myself after reading such sacrilege. :)

  9. Eric W

    3 Aug 2015 Pre-Release Testers, Xojo Pro

    Anybody who invested in VB6... losing one's VB6 sources.

    I've never tried but I suppose a fair bit of VB code could be adapted to Xojo. Microsoft is giving VBScript, ActiveX and COM components (many of the latter two were created in VB6) the chop in Windows 10's default browser. These programs probably should be written in something else sooner or later...

  10. Michel B

    3 Aug 2015 Pre-Release Testers RubberViews.com

    @Eric W I've never tried but I suppose a fair bit of VB code could be adapted to Xojo. Microsoft is giving VBScript, ActiveX and COM components (many of the latter two were created in VB6) the chop in Windows 10's default browser. These programs probably should be written in something else sooner or later...

    Actually a good number of Windows developers here come from VB6. For some reason I was content with VB4 until I bought Real Basic to port a program to Macintosh. Then just to see I generated a Windows executable, and when I saw it worked just perfectly, I was sold.

    You will often see posts in the Windows channel starting with "In VB6 I do this..." ;)

    I still keep VS handy to be able to create Universal Apps, or to build custom DLLs to have access in Xojo to certain functions not available out of .NET. But my main development tool has been RB/Xojo for over a dozen years.

  11. Dave S

    3 Aug 2015 San Diego, California USA

    @Kevin G Not sure about the other pragmas but disableboundschecking doesn't actually do anything now. I discovered this when migrating some code from RB to Xojo. The Xojo version would sometimes crash with an out of bounds exception while the RB version never did. It turned out that the pragma in RB was actually masking a bug in our code so the fact that Xojo didn't respect the pragma turned out to be a good thing in the end.

    You misunderstnad the use of disableboundschecking pragma.
    It means "I, the developer am extremely confident that my code will NOT exceed the defined bounds, so I am instructing XOJO to not add the overhead to do these checks"

    It does not mean, "Heck I don't know if I might have an issue, so please check"

    So the fact that it crashes when you invoke this pragma, AND exceed bounds is exactly what is expected.

  12. Eric W

    3 Aug 2015 Pre-Release Testers, Xojo Pro
    Edited 4 years ago

    Actually a good number of Windows developers here come from VB6.

    I've noticed things in Xojo seem to work like VB -- array dimensions are zero/one based for example. But other things are different, such as putting code in threads to keep the UI free. (However VBA has a different UI model to VB anyway.) Another difference is the VBScript/ActiveX combination executes on the client, whereas Xojo Web creates mini-Web servers or piggybacks onto Apache. So to get the architectural equivalent (more or less) of a VBScript/ActiveX solution in the Enterprise would I think require a total rewrite in JavaScript and Java without any code reuse. In my opinion Xojo Web also has a better security model than that plus potentially fewer client-side maintenance issues over time.

  13. Michel B

    4 Aug 2015 Pre-Release Testers RubberViews.com
    Edited 4 years ago

    @Eric W I've noticed things in Xojo seem to work like VB -- array dimensions are zero/one based for example. But other things are different, such as putting code in threads to keep the UI free. (However VBA has a different UI model to VB anyway.) Another difference is the VBScript/ActiveX combination executes on the client, whereas Xojo Web creates mini-Web servers or piggybacks onto Apache. So to get the architectural equivalent (more or less) of a VBScript/ActiveX solution in the Enterprise would I think require a total rewrite in JavaScript and Java without any code reuse. In my opinion Xojo Web also has a better security model than that plus potentially fewer client-side maintenance issues over time.

    I was not saying Xojo is the same. Just that a lot of people seem to come from VB6, and some have said they kind took refuge from VB.NET. It is indeed a different product, with a lot of advanced features missing in the old MS product. I also think the IDE presenting event handlers in a separate editor is a brilliant idea, as opposed to the kind of messy stuffed together presentation of VB where one has to search for the proper handler in a sometimes awfully long list.

  14. William J

    7 Aug 2015 Pre-Release Testers

    I've just spent the last week converting enough of my Big Integer class to Apple's Swift to do some comparison between Xojo and Swift.

    In the process I found some things that I like better in Swift and some things that I like better in Xojo. For instance, the tuple capability in Swift is wonderful and leads to much cleaner code where you return several values from a method. On the other hand I really really dislike how Swift handles exceptions. If a method throws an exception, you must catch that exception in any method that calls it. There seems to be no way to allow the exception to progress up the call stack as you can with Xojo. In my code I make extensive use of exceptions (divide by zero, ....) and the way Swift handles exceptions makes coding math functions ugly.

    Now for speed, the Swift code was only two times faster with the -fast optimization set. I was surprised that there would not be a greater speed difference. If my testing is representative, then it may be that Xojo and Swift will be close in performance when LLVM comes to Xojo on Mac and Windows.

  15. Bob K

    7 Aug 2015 Pre-Release Testers, Xojo Pro Kansas City

    @Eric W In my opinion Xojo Web also has a better security model than that plus potentially fewer client-side maintenance issues over time.

    We have a client that does security testing for big, big corporations. They love to use Xojo for web apps because out of the box it's pretty safe/secure. They have a 20 step testing process and they can get Xojo apps to crash on step 8 but nothing is compromised. To put that into perspective most web apps they test fail by step 3.

  16. Phillip S

    7 Aug 2015 Pre-Release Testers, Xojo Pro

    Every so often, I get frustrated with Xojo because I'm not able to do everything I want without buying a bunch of plugins, so I go out and buy the latest Xcode book and say I'm definitely going to learn it. This time around I started learning Swift. I like the language, and I think Xcode is a better IDE than Xojo. However, I get about halfway through the book and realize just how much effort its going to take to learn it all and I go back to Xojo. The Xojo/VB way of doing things is so ingrained into my head that I have a hard time getting used to the Xcode way.

    Bottom line is that Xojo makes enough things easier that I can overlook the other stuff. I really would like to learn Xcode/Cocoa someday but Xojo makes it really hard to. :-)

    Phil

  17. Eli O

    is not verified 8 Aug 2015 Europe (Berlin, Germany)

    @William J There seems to be no way to allow the exception to progress up the call stack as you can with Xojo.

    Swift does support a kind of error propagation (as of Swift 2). Plus the Foundation framework supports a kind of UnhandledException event by using NSSetUncaughtExceptionHandler.

    Personally I never understood why so many programming languages support exception propagation. I've never used it and I don't know of one case where I could have used it. Either a method works and at its end the application is still in a consistent state or it is not and the application has to terminate.

  18. Kevin G

    8 Aug 2015 Pre-Release Testers, Xojo Pro Gatesheed, England

    @Dave S You misunderstnad the use of disableboundschecking pragma.
    It means "I, the developer am extremely confident that my code will NOT exceed the defined bounds, so I am instructing XOJO to not add the overhead to do these checks"

    It does not mean, "Heck I don't know if I might have an issue, so please check"

    So the fact that it crashes when you invoke this pragma, AND exceed bounds is exactly what is expected.

    No, I fully understand what the pragma used to do. I think you've misunderstood what I wrote.

    Unknown to us, one our functions had a bug that could trigger an out of bounds exception depending on a specific set of situations. After our initial QA, we added the pragma to help with optimisation as we assumed all was well. The out of bounds was happening but the pragma was suppressing the exception and by chance didn't trigger a more serious crash.

    When we moved the code to Xojo (including the pragma) we started to see the exception being triggered. We originally thought it was a bug in Xojo since we hadn't had any problems in RB. It turned out that there was a bug in our code and the pragma does nothing in Xojo.

  19. Eli O

    is not verified 8 Aug 2015 Europe (Berlin, Germany)

    @William J Now for speed, the Swift code was only two times faster with the -fast optimization set.

    I made the same observations. My conclusion (by using Instruments) is that two things in Swift are painfully slow:
    – object creation
    – setValue:forKey:

    A year ago I wrapped the mysql client in Xojo and I translated the code at that time to Objective C. The Objective C version is about 7 to 8 times faster to load 20 k records from a MySQL server (running on the same machine for test purposes). Very impressive. The Swift version is 1.5 to 2 times slower than the Xojo version. I didn't believe it first. But it seems that the type-safety and other stuff like nullability and bridging into Objective C make Swift very slow (while all other stuff, computations, loops, etc. are as fast as Objective C).

  20. Joost R

    8 Aug 2015 Pre-Release Testers, Xojo Pro The Netherlands

    It strikes me that we are quite often talking about other programming environments which are mostly tied to one dedicated OS.
    The reason I went for Xojo is RAD combined with the benefit of not being tied to just one OS anymore. Which "competitive" does offer all that ?

  21. Michel B

    8 Aug 2015 Pre-Release Testers RubberViews.com

    @Joost R It strikes me that we are quite often talking about other programming environments which are mostly tied to one dedicated OS.
    The reason I went for Xojo is RAD combined with the benefit of not being tied to just one OS anymore. Which "competitive" does offer all that ?

    Not everybody uses Xojo's cross platform ability. Some people never go out of their Mac. And I bet there are people using Windows who never compile anything for Mac. Then XCode on Mac and Visual Studio on Windows may have some appeal.

    Each one offers the full variety of controls, properties and methods for their target platform. But precisely their complexity is an impediment to rapid development.

  22. Newer ›

or Sign Up to reply!