Writing a blog post help me clear my mind and get feedback to my idea’s. Some of my readers are very loyal in their interactive feedback while others just sporadically leave a reply or contact me via the contact page.
For this post I also hope to get some feedback.
Before we get started, I am not a huge fan of either of the languages we are going to discuss today so it feels a bit like comparing two types of beer you don’t fancy while the good stuff is waiting in the fridge.
About Programming Languages
There is no such thing as the perfect programming language, every languages has good things and bad things and every language should be reflected to the era it was designed in.
AL – The 1980ies
The AL programming language which is used in Microsoft Dynamics 365 Business Central is a product from the 1980ies which is important to know to be able to understand it’s context.
In those years there was a big debate about object oriented programming and computers where just getting fast enough to enable OOP from a memory perspective.
I cannot recommend the video’s and books from Uncle Bob often enough and he has a very good way of explaining working with the stack and how in OOP objects have constructors and why.
In those years OOP was considered complicated and inherritance was considered smart. We know now that inherritance should be handled with care and is a fast road to a huge mess then over-implemented. (Also look for video’s where Uncle Bob explains the diamond problem)
AL is based on Pascal and is not object oriented. This is for a good reason because Navision was not targeting the product to be customised by developers. Navision was targeting the product to be customized by accountants and end-users.
This is why the vast majority of the developers in our community, including me, do not have a proffesional programming background.
In a sense the language could not be more different from AL even though it just looks like that.
Why Did Microsoft Keep AL?
Millions of lines of code are scribbled down in AL. Probably much more than nessesairy because of the lack of clean code which I explain in this video.
All of these lines of code are at compiletime converted to C#. I explained a little bit of that in my previous blog.
A lot of new-generation developers have asked Microsoft for a long time why it is not possible to write C# code directly. I may explain more of that when I write a blog of how Extensions actually were supposed to work and where Microsoft went off-track with the initial design.
Pressure from the existing NAV partners is probably the reason why AL still exists.
Converting C/AL to AL
These days many, if not all, NAV partners struggle to convert their C/AL code to AL and Extensions. Most partners, or actually almost all without exception, find out that just converting the code is not going to make the magic happen.
A lot of solutions have to be re-evaluated. People have to go back to the drawing board.
A Perfect Momentum?
One could debate if it is smart to carry forward twenty year old code in a non-object oriented platform full of duplicated code.
If one has to rewrite most of the code anyway, in Business Central or outside, why do we not revamp the language too?
But it is true. In ForNAV reports you can declare table objects as global variables and perform Get, SetFilter, CalcFields and what have you.
Imagine if one guy (true, not your average one) can make that work?
This video shows what how it actually works.
Ever since I learned Object Oriented programming I cannot write any AL code anymore without thinking “What if…”.
I try to mimic OOP as much as possible in my code. The database I work with has dozens of tables that I only use as a class and it makes my life somewhat easier. The amount of code that I refactored into classes in NAV is huge and the code became so much more robust, stable, performant and testable.
Last year I did a small project in TypeScript and I fell completely in love. It was as if all the good stuff from the languages I worked with were put together.
It will probably never happen, but boy, if you want to make me back enthousiastic about Business Central and Extensions we should move to TypeScript in small projects without object numbers.
Just kill AL, please.