This is the first part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.
-----
Xojo is without a doubt a derivative of the BASIC family of programming languages. The CEO of Xojo Geoff Perlman has said that if a user associated Xojo with the original BASIC then that would be a “wildly inaccurate association”. Xojo is very cautious to embrace their BASIC beginnings and always asserts that the languages only share a common heritage. That may be true from a certain point of view as Xojo is most comparable to Visual Basic. Visual Basic despite its popularity was always seen as the ugly step child of the Visual Studio family and today is seemingly neglected by Microsoft.
When REALbasic was ready to launch a new aesthetic for their IDE it was time to disassociate further from BASIC. The company and language were renamed to Xojo and now share only a common syntax. The best way to describe Xojo to someone unfamiliar is a “modern event-oriented cross platform alternative to Visual Basic 6”. For this I think there is little dispute so I leave it to you to decide if Xojo is a BASIC or not.
Like any BASIC language, you have your usual suspects of keywords, data types, modules, etc. You “Dim” to create a variable, you “Redim” to reset an array. You can easily create event handlers in the IDE or use “AddHandler” to alter the event flow. Container controls give you the ability to create complex UI controls that you can reuse. A good portion of the core language constructs work on all platforms in the same way. There are some platform differences especially when you go between target categories like Desktop to Web or Web to Mobile. You will most likely discover these differences the hard way as Xojo makes it super easy to compile for multiple platforms but does not always point out obvious mistakes. You also have advanced functions like delegates, cooperative threads, and declares to optimize your code paths and tap into the available underlying operating system functions.
In fact, one of the best strengths of Xojo is due to its cross-platform nature you find yourself running on all different types of devices. Xojo while not always providing all the standard functionality for each device lets you tap into the host operating system via declares. Unfortunately, when a declare is not enough or the functions you require are not provided by the operating system there is little you can do to expand Xojo’s core functionality.
One option is to develop plugins for Xojo using C++ (and possibly others undocumented or not supported by Xojo). Plugin development is not immediately intuitive I think in part because Xojo would prefer you to write native Xojo code then augment their standard library. What documentation there is on developing plugins is difficult to utilize and you also should develop equivalent functionality for all potential targets (Windows, macOS, and Linux) meaning three code bases for one plugin. Plugins cannot be written in Xojo now although they have promised the ability in the future. When that occurs, they have indicated that both plugin mechanisms will co-exist for some time.
I will write more about the framework and standard library of Xojo as well as the plugins and add-ons available in a later part of this series. For now, I want to touch on some things that they need to add to Xojo sooner than later.
Generics
While a contentious item for many software developers in various languages there is immense benefit in adding them to Xojo. One example of how generics could make programming in Xojo easier than ever is when using Dictionaries. Unlike an Array that has a built-in type such as:
Dim stringArray() As String
Dictionaries have no equivalent:
Dim myDictionary As New Dictionary
The compiler can enforce that all elements placed into stringArray are String objects (or a derivative). This happens at compile time offsetting potential errors if you were to attempt to add something else to it later. You also can catch errors at the compilation stage when reading out of the Array.
The Dictionary however does not have this protection and can hold any type of object in its collection. When accessing a Dictionary there is a potential run time exception when I assume every item in the Dictionary is a String when there is a possibility it is not. I also must cast each item as a String when I read it back out.
Look at the following:
Dim myDictionary<String> As New Dictionary
or
Dim myDictionary As New Dictionary<String>
Either of these methods would provide an immediate benefit to the developer as the compiler could catch obvious exceptions to this. On the backside when I go to read items out:
Dim stringValue = myDictionary<String>.Value(“stringValue”)
Right now I have to do:
Dim stringValue = myDictionary.Value(“stringValue”).StringValue
That raises a nasty exception at run time if the object is not a String. This could have been prevented by the compiler when developing if we sprinkled some sugar in there called generics. I would be perfectly comfortable with generics making a very limited entry into the language and standard library and expanding on it further where it made sense. They should never be required but when used provide more compile time safety.
Threads
Xojo uses a cooperative threading model and thus your application can only utilize one CPU core at a time. To potentially get better performance from long running or mostly independent functions you are recommended by Xojo to build helper apps. Essentially window-less or console-based applications that are executed by Xojo using the Shell class.
I recognize the cognitive challenges of pre-emptive threading and how that runs afoul of the easy to use Xojo language as it stands today. However, if you are to force us to use background applications to perform critical tasks then the path to doing so must be made considerably easier.
Right now, you must either pass the necessary arguments to an entirely separate process via command line arguments or IPC sockets. To develop said additional process you need to develop a second Xojo project in parallel with your first one and synchronize the necessary shared code. As they are two unique projects with two unique builds you must construct a folder hierarchy to manage how the Windows version of your command line helper ends up in the Resources folder of your Windows GUI app. Your Windows GUI app now should verify each time it starts that it has access to your Windows command line helper. You must perform these steps for each platform target and for each console helper application and it quickly gets out of control. Working in a multi-programmer environment can exacerbate these problems even further.
Fully utilizing your CPU in Xojo while maintaining a responsive (not locked up or wheel spinning) application is extremely difficult. Far more difficult than it should be and it is a real stain on Xojo when competing with newer tools with complex concurrency and parallelism. Clearly not an apples to apples comparison but Golang is cross platform language that builds a single binary with all libraries bundled in and can use all of your CPU cores with ease. I don’t expect Xojo to completely rewrite itself to accommodate these ideas as they require a different level of thinking and would break existing code.
However, Xojo could allow for sub-projects or background functions that it automatically prepares and builds the necessary console helper apps as needed. I should never have to think about how the primary application talks to the console application. Like XojoScript it could share in a very limited ability to exchange parameters to offset the fact that all parameters would be sent via command line arguments.
For example, if I have a very long running function that produces a very complex report and I want to run it in the background. I should be able to say, “Add New Background Function” and I name it “BuildReport(parameter1, parameter2, …)”. It can only accept basic data types such as String, Integer, etc. just like a command line argument would. I develop my function with the parameter names like any other function in the Xojo IDE. I then call my function from anywhere else in my program.
Behind the scenes the Xojo IDE created a console helper application, parsed command line arguments for every time I call the “BuildReport(parameter1, parameter2, …)” function and handles it accordingly. It can then return a simple datatype result that can be parsed back by Xojo using their Shell class and then ultimately raises a Done event with the result. It should automatically prepare my background function console application for each platform I build for so I do not have to think about paths, command line arguments, Shell, etc. It has all the tools to do this already and if it did would mark a new chapter in accelerating your applications.
Custom Event Handlers
Today building custom event handlers for an object that has not been sub-classed is a real waste of my time. The consensus is generally that you should create a sub-class any time functionality changes and thus you can use the hander IDE helpers to handle class events.
For me the ability to share code between projects in Xojo is very limited. One limitation is external modules cannot have classes embedded in them. This means you cannot maintain a strict hierarchy of objects in modules and share that code between projects very easily. Using external items in the IDE allows you to update all your projects with one set of modules. The alternative is copying your latest module over to your accessory projects each time which is prone to error.
This means I do not like to create tons of sub-classes because it is more items I must copy or make external and then import as external. I find myself often just not creating sub-classes and using an instance of the more generic base class. I then must use “AddHandler” to catch the events of that class and redirect it to a given method. This is terribly painful when you do it often because each time you must add methods with the same signature as the event handler and then use “AddHandler” to bind it. Over and over it gets tedious fast.
Today:
Dim myObject As New Object
AddHandler myObject.myEvent, addressOf handler_myObject_myEvent
Function handler_myObject_myEvent (sender As Object)
MsgBox("The event was raised.")
End function
This is very tedious with any complex objects like HTTPSocket. I don't want a subclass for every single time I want to use a socket.
I would like:
Dim myObject As New Object
myObject.myEvent = Function(
MsgBox("The event was raised.")
)
Final Thoughts
I hope some of these language ideas gave you food for thought and the Xojo team some ideas on how to compete in this multi-core world.
The next part of this series will take an in-depth review of the various Xojo frameworks available to you when developing on its many platform targets. We will look at iOS, the old framework, the new framework, awesome features, caveats and where it should all be headed. Stay tuned.
-----
This series is going to be my assessments and opinions on Xojo the language and framework after several years of using it on projects of all kinds. I personally enjoy using Xojo but it is not without its shortcomings. There are projects where it is not a good fit or where developer experience is going to be required to get the desired result.
Choosing a platform for your software is an important decision but not a deal breaker. Every platform and development environment has its strengths and weaknesses and Xojo is no different. Success starts with a good design, a strong business model and hiring those who are passionate about the tools and business to produce the best possible product.
I’ll demonstrate in this series different areas where Xojo can improve but also areas where it excels. I look forward to your comments and feedback while diving deep into Xojo.