AL vs. JavaScript

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.

Both JavaScript and AL are very old languages but AL beats JavaScript by almost a decade or so I guess which might explain some differences.

Some programming languages are backend languages or frontend languages. Both JavaScript and AL can be used for both serverside and clientside programming although AL, to my best knowledge, is always executed serverside even if it is programmed on the UI.

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.

JavaScript – the 1990ies

JavaScript is a born in the cloud programming languages to solve the problem of cross plaform business logic.

In a sense the language could not be more different from AL even though it just looks like that.

By the time JavaScript was growing up Object Oriented programming was probably considered the only way to code.

Without going too much into details I do want to mention JavaScript is not type-safe (a Dynamic Language) and it uses prototypes rather than classes.

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?

JavaScript & AL merged together?

About a year or so ago I was forced to learn JavaScript for my job as ForNAV. Michael Nielsen who is one of the developers of ForNAV decided to use JavaScript as a scripting language for the reports.

I was not super-exited because I had some failed attempts before to understand JavaScript. Lucky for me Michael was patient enough to teach me the basics and with YouTube and W3Schools I can find my way around.

Later on I was way more exited when Michael told me he had made C/AL database access work within JavaScript. I could not believe my ears.

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.

My Dream?

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.

TypeScript

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.

Post navigation

1 thought on “AL vs. JavaScript”

I have worked previously at a partner, but my current perspective is as an in-house programmer at an end user.

We have only just upgraded from 2009 R2 classic client to 2016, and that was a massive change for the users here! I realise that we are a bit behind the times.

Even with the change from classic to RTC, there are a lot of features that were lost from the client. Small things like find and replace. Enough small things to make retraining difficult for some users. Every change breaks someones’ workflow, right?

My concern is that Microsoft are changing the product too quickly, and have not thought out a lot of the implications of what they are doing. (See Extensions)

The main appeal of NAV is that it is customisable, and it’s quick and easy to implement new features or change existing ones. I’m not against moving into Visual Studio, but as a NAV developer I have certain expectations.

* Code that I have written previously should continue to work without too many problems.
* A small change to one object should be quick and easy to deploy.
* Everything that is currently possible in C/AL should be possible in whatever new language they choose before they even think about killing off C/AL.

My company (and I’m sure many others) has invested many years and millions of dollars on developing their NAV system to tailor it exactly to their business requirements. If I have to spend many more years and many more hundreds of thousands of dollars converting all of that functionality to a new version that doesn’t include C/AL, the question will become “what is the benefit to the business?”. We would have spent all that time and money just to get what we already have to work.

I’m not against change – I love the new filtering and saved views that are possible with the RTC – but Microsoft really needs to think about how they approach this, because they run the risk of alienating many thousands of existing customers.