Why Xojo?

  1. ‹ Older
  2. 4 years ago

    Bob K

    7 Aug 2015 Pre-Release Testers, Xojo Pro, Third Party Store 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.

  3. Phillip S

    7 Aug 2015 Pre-Release Testers

    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

  4. 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.

  5. 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.

  6. 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).

  7. 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 ?

  8. Michel B

    8 Aug 2015 Pre-Release Testers, Xojo Pro

    @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.

  9. William J

    8 Aug 2015 Pre-Release Testers

    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 ?

    In my case, when I started using Xojo (then Realbasic), my main platform was Windows and I had a lot of interest in Linux. After some bad experience with some PC laptop hardware I migrated to MacBooks and fell in love with OSX. For me the appeal of Windows and Linux is gone. I don't want to even develop for them. So .... for me the two options are Xojo and Xcode. I was experimenting with Swift because it's new and I like to dabble in new languages. But, it is too slow for my use right now (and the ugly implementation of exceptions) so I will be sticking with Xojo.

  10. Dave S

    8 Aug 2015 San Diego, California USA

    Be careful when comparing XCODE speed, XOJO speed etc.... be sure you compare then in the same environment (I'm going to not mention the old argument, about being able to write "good" code one place and "bad" code another, and assume for sake of arguement that the effieciency of both are equal).

    Code running on the iOS Simulator (depending on what it does) CAN (per Apple) run MUCH faster than on a real device. While the simulator has to emulate iOS, it is usually doing so on a piece of hardware much faster than your iPhone/iPad.

    The other is comparing speed on one iDevice vs another. An iPhone6 is going to be faster than an iPhone4s and dependng on intensity of graphic processing an iPad2 might be faster than an iPhone6 (might), as it is non-Retina

  11. Mark O

    8 Aug 2015 Europe(UK)

    @Dave S Code running on the iOS Simulator (depending on what it does) CAN (per Apple) run MUCH faster than on a real device. While the simulator has to emulate iOS, it is usually doing so on a piece of hardware much faster than your iPhone/iPad.

    It's odd you say that. I was working on an app for the last company I worked for and the app ran up to 3 time faster on the real device (estimating the times here). But, that may have been because we were using SceneKit for 3D visualisation.

  12. René L

    8 Aug 2015 Pre-Release Testers Ratingen, Duesseldorf, Germany
    Edited 4 years ago

    @Joost R
    Well the only Software i know wich has nearly the same Crossplatform Power is Embarcadero RAD Studio XE8 (Supports: Windows, OS X, iOS, Android) using the new FMX-Librarys. My bigest Problem with Embarcadero RAD Studio XE8 is the IDE is only availible for Windows (and for iOS and OS X Support need an MAC via a Remote Compiler)
    After i switched my Main PC to a MacBook Pro 15", i looked around and found RS and switched shortly after. Sometimes Xojo is a pain in the a.. ;-) But the VB6-Apps of one of my Clients was ported realy easily, thx to VBMigrationAssistant. And now they can use it not only on Windows but also on Mac (of the CEO) without the need for an VM or Bootcamp.

  13. Marco H

    8 Aug 2015 Pre-Release Testers Cali, Colombia

    I do mainly backend programming. I always did plain old C but since a few years, I'm all Go(lang). For me, Golang is the perfect cross platform language for backend programming. Modern, easy, blazing fast and fun to do things with.
    As for GUI programming, I miss the old Delphi. Their IDE was so awesome to work with. RAD and full code access. (I wish the Xojo IDE worked more like the old Delphi IDE). I jumped ship after the whole Embarcadero thing and ended up struggling with the Lazarus bugs.

    I started with Xojo a few months ago because I needed a GUI App for OSX. I like Xojo because I can build things fast. I don't like the language itself so much (I'm not sure what the new framework is going to bring). I also think that the cross platform -part causes a lot of limitations and frustrations. IMHO, Xojo does the job fine and fast. It has a great community but the language feels old fashioned and the IDE has a lot of things that could have been done a lot better.

    As for Swift, I like the language itself. It's easy to learn but compared to Xojo, it requires more coding and more time to get things done. I avoid doing Swift because of Xcode. It think it's the worst IDE ever made.

    As for the future, it will be all Golang for backend programming.
    For GUI Apps, I don't know. For now it's Xojo and hopefully the new framework will work out for me.
    Now Swift is open source (next month?) and available for Linux, I'm sure it's going to be ported to Windows at some point. Maybe someone comes up with a great IDE for Swift as well.

  14. Ulrich B

    8 Aug 2015 Pre-Release Testers, Xojo Pro Europe (Germany, Berlin) · xo...

    @Mark O It's odd you say that. I was working on an app for the last company I worked for and the app ran up to 3 time faster on the real device (estimating the times here). But, that may have been because we were using SceneKit for 3D visualisation.

    Yes, that's possible too. While pure CPU code will often be faster on the simulator, there are a few GPU-based features (CIFilter being one of them) that are emulated on the CPU of your Mac running iOS Simulator. Could be SceneKit is another one of those.

  15. John H

    8 Aug 2015 Pre-Release Testers Planet earth
    Edited 4 years ago

    I guess, If we don't follow rule 1 from the book "97 Things Every Software Architect Should Know" (http://www.pdfiles.com/pdf/files/English/Other/97_Things_Every_Software_Architect_Should_Know.pdf ) . More developers would have properly used XOJO :)

  16. Michel B

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

    @John H I guess, If we don't follow rule 1 from the book "97 Things Every Software Architect Should Know" (http://www.pdfiles.com/pdf/files/English/Other/97_Things_Every_Software_Architect_Should_Know.pdf ) . More developers would have properly used XOJO :)

    I love this paragraph : "Developers are drawn to complexity like moths to flame"...

  17. Dave S

    9 Aug 2015 San Diego, California USA

    @Michel B I love this paragraph : "Developers are drawn to complexity like moths to flame"...

    I guess I am the exception to that rule..... I strive to remove the complexity whenever possible.
    Break the problem down into smaller easier to solve pieces, don't try to solve the monolith

  18. Michel B

    9 Aug 2015 Pre-Release Testers, Xojo Pro

    @Dave S I guess I am the exception to that rule..... I strive to remove the complexity whenever possible.
    Break the problem down into smaller easier to solve pieces, don't try to solve the monolith

    That is why I like that paragraph. All too often I see people embarking on labyrinthine systems when a few lines of Xojo does nicely.

    The mark of intelligence is to see simplicity behind apparent complexity.

    I hate spaghettis ;)

  19. Doug S

    9 Aug 2015 Vancouver, Canada

    @Michel B I hate spaghettis ;)

    The discussion of Vegetarian and Non-Vegetarian spaghetti code is in the OT thread... :/

  20. Indeed simplicity is beautiful. Sometimes people think too far.

    What Dave and Michael wrote, I cannot write it better. Completely agreed with.

  21. David C

    10 Aug 2015 Pre-Release Testers, Xojo Pro Derby, ITM

    I love and hate it when I've finished optimising some Xojo code to the point of shortness, simplicity and beauty, then look at it and think "it's so obvious that this is the correct code" and why did it take me so long!

    I like simplicity since I want to be able to return to code in 6 months and not have to re-learn my old thought processes. Only Xojo.

or Sign Up to reply!