New Language Shortcomings

During the last 20 years, a huge number of new programming languages have been developed. In general, new languages have evolved to address the perceived shortcomings of older languages. Unfortunately, these languages may not always live up to the hype. Furthermore, new language ‘features’ may actually end up creating more complicated and unreadable code. I have previously written about the importance of simple code as well as the trap of “time saving” frameworks. However, not all new languages follow these ideals.

Recently, I have started learning Kotlin. Kotlin is a JVM language which is increasingly used for Android development. Thanks to a variety of improvements, Kotlin code can do more work with less code. However, this isn’t always a good thing. For example, Kotlin generates a significant amount of code behind the scenes. While this does reduce the burden to developers, it does not guarantee that the desired code will actually perform the necessary function. In fact, I have often found that the most difficult bugs to find are those generated by code under the hood. For example, I remember using Hibernate in the 2000’s to connect Java to the database. In 99% of my use cases, Hibernate performed incredibly well and saved significant time. However, the 1% of cases where the SQL generated by Hibernate didn’t perform properly required enough research and work to remove any possible time savings to the developer.

Another example with Kotlin, and a large number of newer languages, is the lack of requirements to actually define variables and return types for functions. While this may save time, it means that future developers will be forced to read the code more closely to determine its meaning. Likewise, the growing use of lambda functions – while incredibly useful in a broad assortment of situations – is beginning to create code that is nothing but extended sequences of lambda functions with no obvious intent. In both instances, I prefer verbose code that can be easily understood by future developers with far less chance for misunderstandings.

While many of these newer languages have some amazing features, few have actually captured much market share. Maybe it’s because of the glut of languages on the market now, or maybe it’s because developers have found these ‘improved’ languages actually cause more problems than they solve. For me, I will continue to write code with the hope that junior developers will not be wowed by my wizardry, but rather that they will be able to understand my code without any ambiguity.

QuickBooks Payment Bug

If you use QuickBooks online, please note that there is a bug on the new invoice screen. Unfortunately, if you click in the wrong text window, credit card payments will be automatically enabled. I have previously enabled ACH, but do not want credit card payments since they have significant fees that I don’t need to deal with in a service industry.

In the below screenshot, you will see a new “Tell your customer how you want to get paid” input box. Previously, the text box at the bottom of the invoice was a note for the customer. This has been moved down further. Notice how Bank, PayPal, and Venmo are enabled.

However, on this screenshot, I have clicked the text input and the credit card options automatically appeared.

On the left side of the screen, you will notice the option to turn credit card back off. However, as I worked through this with QuickBooks support, there were many times that these options did NOT appear. In which case I had to exit the invoice and create a new one.

While I made QuickBooks aware of this issue this evening, it will likely take time to resolve. So, if you use QuickBooks and do not accept credit card payments, be careful of the new interface and double check before you submit to a client!