Xojo 2019 R2, I mean API 2.0, Review

Lot of chatter in the blogosphere and forums about API 2.0. What do I think? 

I think renaming the events was a mistake. Not because the philosophy behind the changes is wrong but because the IDE was not designed for it. In fact, I cannot think of any language that renamed events on their standard library classes. It just does not happen. Events are part of the core contract of the whole object hierarchy and all code developed in an OOP fashion relies on the stability of those events. In other languages they would release a new class. 

The crux of the issue is the language and standard library are presented as a single entity in the IDE. It would be ridiculously awkward and painful if new projects started with AppV2 or WindowV2. Platform makers often just create entire new frameworks like WPF, UWP or WinForms. It is ridiculous, but it gives the developer choice. If I want to stick with my trustworthy but not entirely clear when it fires .Open() event I can just stick with Xojo Desktop v1. 

When you create a project, it should ask you "API v1 or API v2" and that's it. The constructs of classes having events is the same regardless of their names so why does the IDE care which version you use? All it needs to know is which library to use for code completion. The fact that the choice is not possible or was never considered is the part that makes event renaming as delivered a rookie platform mistake.

I am not as upset as I could be as there was an even more asinine change that we luckily got reverted. The <beta> class that we all use every day had been changed in ways that are completely and utterly mind boggling. Who is driving the technical direction here?

If I sold you a plugin and it did not work and I told you that I implemented .Open() and your use of .Opening() broke my code you would understand. It makes sense. It is annoying and one questions how or why this is possible, but it makes sense.

What if I had said the reason your code does not work was a subtle change to the default constructor that made the entire object immutable? All I would get back from you is a puzzled look. Likely, you would ask for clarification about why I mentioned the default constructor. 

That's right. Depending on the constructor you use, all properties silently changed their behavior and there is no way to know this in advance. If you have any existing code, you would reject using R2 on the premise that <beta> is completely and utterly borked. Funny, when they realized this, they changed the name of the class which is actually what should have been done in all cases of event, property, and method renaming.

Some of you will not use R2 because of event renaming but I promise you it could have been much worse. Worst part about all of this is R2 is actually a good release. Lots of things are fixed and improved and the database improvements without needing horrible prepared statements are much improved. However, there is also nothing shiny or stand out about the release. Subtle changes here and there give the appearance of a release with lots of effort, but it is mostly semantical nuances.

Array's moving from Append() to AddRow() is untenable for anyone with a computer science background. My thinking is in the future arrays can likely be used as a bindable data source and AddRow() represents the action occurring in the user interface. That's my imagination and hope for the product as I seek creative justification for these mostly pointless and subjective changes. All for the sake of a hypothetical future citizen developer who didn't buy and selected "did not understand the exact timing of Window open" on a marketing survey.  

The struggle is I don't know why API 2.0 exists at all as a version milestone. It does not move the product forward in any meaningful way. If Apple had not released macOS Catalina, then this release would serve no function. I am concerned these changes were built in a vacuum not mapped to any real-world deliverable. The time to optimize is when you release new things like DateTime. Release Web 2.0 with API 2.0. Release Android with API 2.0. Release an enhanced desktop framework with new controls like a date picker and database binding with API 2.0. Allow API 2.0 to grow out of necessity and not as a milestone in and of itself. 

The fact is if I use API 2.0 it won't improve my software and at the end of the day that is what creates Xojo renewals. Did my software just get a little bit better because I upgraded Xojo? Sadly, when it comes to R2, it does not. 

For the future I recommend being less ambitious and evolve more areas of the product simultaneously so timespans between meaningful new additions is not so great. Produce more meaningful new additions. We are coming up on a second XDC with nothing new for the platform to encourage new developers to use it. 

Xojo in 2017: A Review [Part 5: When To Use It]

This is the fifth and final part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

The fourth part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part4

-----

Xojo is a significant product.  Targeting Windows, macOS, various Linux distributions, iOS, and Raspberry Pi from one language is an undertaking.  Xojo also sells a web product compatible with modern Internet browsers.

The goal here is to allow you to focus on your application versus the wide variety of platform differences. In my experience Xojo is one of the best options when considering a cross platform solution.

However, there are disadvantages to Xojo and you should know when not to use it:

• When maximum performance is required. Xojo console applications can be quite fast but desktop applications do suffer from a large framework. Application safety features can be disabled and compiler optimizations toggled to speed it up but you are certainly never going to beat bare metal.
• When maximum concurrency is required. Xojo applications can only use one CPU core at a time. There are numerous reasons for this and it is not likely to change. I demonstrate in earlier parts why the story around accessory applications to utilize more cores needs serious revisiting.
• When you are using platform specific features. Xojo’s promised “interop” capabilities should deliver better availability of platform specific features. However even then out of the box Xojo has few platform specific features. The ones they do have tend to be bare bones and not widely updated or enhanced. Xojo delivers a lowest common denominator approach. You can overcome this with extensive work.
• When you are deploying to a single platform. The lack of platform specific features makes this a sub-optimal approach. Programmers tend to be optimistic and believe that deploying to a new platform is “coming soon” so you should prepare now. If you know that you will be on a single platform for 12+ months you should focus on using the tools for that platform.

There are some great advantages to Xojo and here are some cases where you should use it:

• When you are building a line of business application. These days company staffers are using all kinds of devices. You do not want to prevent someone from working because a company utility does not run on their platform.
• When you need to build a quick and dirty prototype. Xojo is really fantastic at building working mockups that evolve easily with your ideas. Mockups and design concepts are helpful but a functional prototype helps users conceptualize their needs and delivers better results.
• When you do not have time to rewrite your prototype in a “real language”. Xojo provides full object-oriented capabilities such as classes and interfaces to allow you to build complex software. There is nothing stopping you from turning your prototype in a high-quality application.
• When you are concerned about your software documentation and architecture. Xojo with its IDE keeps every project organized in very similar ways. Excellent built in search and navigation of the code hierarchy allows for great code discovery. Its basic syntax is easily read and understand. Xojo programs are not difficult to share with others.
• When you want to share code between target platforms. Xojo through the use of modules and platform conditionals makes it very easy to share the same platform-independent logic across all targets. It is really great to write some REST API code or PDF code and have it work on all targets with little to no additional effort.
• When you want a central location for documentation, community and support. Xojo’s commercial nature is a strength for many customers. They prefer the official documentation and support channels that Xojo provides. While I advocate for the open sourcing of a subset of Xojo’s functionality I do believe in Xojo as a commercial entity and product.
• When time is of the essence. I do not think there is a faster or easier way to compile a working desktop application for this many targets anywhere. It may certainly be doable by Java and others but it is nowhere near as efficient or fun.

I personally enjoy using Xojo for every project where appropriate but it is not always the best tool for the job. I hope this series has given you some indications as to where I think Xojo is, where it could go, and why you should consider it. 

If you were discouraged about Xojo I hope this series demonstrated that a lot of people rely on it daily and it is a good product. If you are encouraged about Xojo and concerned there may be lurking problems well I hope I have presented the most challenging ones to overcome.  If the tradeoffs sound agreeable to you then you should consider it for your next project.

I will continue writing here my experiences and feelings about Xojo. This however is the end of my 2017 review series. I have some big open source and commercial add-ons being released soon so I want to focus on writing great documentation and example projects for them.

Once we get into 2018 it will be XDC time and I am very excited to meet more of the this community in Denver. Thanks for tuning in and don’t forget to sign up for our mailing list.

Thanks for reading.

Phillip Zedalis

Xojo in 2017: A Review [Part 4: The Community]

This is the fourth part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

-----

Bob Keeney writes in his latest piece that “software development is fluid” [1]. Always changing, evolving, and not easy to schedule around. It is a nice analogy and I get the underlying message. There has been a current on the forums that maybe Xojo does not do enough to resolve bugs. Perhaps they are too focused on new stuff that important issues do not get addressed. Bob is writing a piece here defending Xojo, their development style, and the complexity of what they are trying to achieve.

I think like most in this niche of software consulting we rely on Xojo being a reliable product. Our success in some ways is tied to theirs. Let me rephrase that a bit: Xojo consultants would prefer to stay Xojo consultants versus primarily using other tools. He wants to promote the tool he likes so much and so do I. Most in the community are like minded in that way.

Many of his arguments I suspect are valid and reasonable. I think for the most part you see this throughout the Xojo community. We all recognize how challenging it is to run a small software company. Some part of us appreciates Xojo on a fundamental level. We also become have become proficient with it and it enables us to get more done.

However, there are times when it holds you back. A new release breaks something or a new feature does not work as expected. The community lights up then and the argument remains:

• Why do you not give us more heads up on what you are doing?
• Why do we not get more time to test?
• Why are there not more testers?
• Why do bug reports take so long to get fixed?

It can get pretty excited at times and it is not unheard of for a thread or two to get locked shortly after a release. I love this part of the community because everyone is so invested in the product.

When you look at issue trackers and forums for open source languages it is rather dull. Many times there are few that are invested in a language because you are only one console command away from installing an entirely new development stack. The questions are highly abstract and technical and the responses are typically slow and methodical.

I comment aggressively on the Xojo forums that I wish the (Xojo) engineers would tell us more, show us more, give us more. Sometimes they fire back and have told me that being on the forums is not in their job description. Nonsense. If the Xojo engineers left the forums the community would be harmed. The Xojo engineers are not just part of Xojo they are also part of the community. They would miss us as well.

We all want to enjoy where we work. We push Xojo pretty hard and that is healthy but we also have to make sure we are not making it intolerable to work at Xojo. Like Bob said we need to do our part with bug testing, writing open source code, and helping others in the forums. However, the community is not to blame when regressions hit and progress slows. Some part of it is due to the enormous nature of what Xojo is trying to accomplish. The other part is the secretive nature in which they do it.

This is why in Part 2 of this series I suggested open sourcing the standard library; The mish mash of libraries and classes in either Xojo, C++, or third-party libraries. When bugs are encountered in the “framework” it can force you to use a different version of the product. The sad truth is regardless of the difficulty of a bug report it may not lead to a timely resolution. Often times you will get a confirmation and then wait several releases. You have no idea if they have even scheduled to start fixing it.

I feel like if Xojo is not going to commit to fixing something in a reasonable timeline then that would be a great opportunity to ask the community to attempt it. Let us earn badges or points or something. Give the top 5 every month a coupon for example. I am thinking bug bounty board meets achievement points. We don’t need any cash or prizes but recognition to the community for being involved. Most importantly let us help you chisel away at the issue list.

If there is a problem with Bob’s piece I would say my only nitpick is I don’t think software development is fluid at all. In fact, I think it is solid. Solid like a giant rock that has remained stationary for millions of years.

Software development is like sculpture as you chisel 0’s and 1’s into a rock face. You spend so much time planning and considering the subject matter and problem at stake. You design and architect the database, storage, and architectural nuances of how messages get from one method to another. You consider deployment strategies and security concepts to protect your users and not leak your database to Reddit. You do all of this in the hopes perhaps you will achieve something great. “Something great” more often than not is a tool or utility to create more software to manipulate even more 0’s and 1’s. 

I say solid as a rock because even with source control, undo, snapshots, checkpoints, auto-saves, and screen recording you can’t save a bad program. It takes too much work and the amount of effort to resolve the plumbing job of a poorly planned program is terrifying. You start dreaming up ways to convince your client or boss that it would be best to start anew. As you mature you realize this is not always a practical strategy and so you are going to have to do surgery more often than not. You are desperately hoping not to chisel the last bit of support that keeps the rock standing up.

I am not convinced software is fluid at all.

I am convinced Xojo makes for a great chisel.

I also believe the Xojo community is part of the value proposition of the product. For example I search the forums before I search the documentation. Thank you forum.xojo.com. 

-----

[1] = http://www.bkeeneybriefs.com/2017/08/software-development-is-fluid/