I’m a big enthusiast of Business Central, but I admit, when I teach it to people with no background knowledge, it always gives me pause and makes me look at everything with fresh eyes. It’s like playing or cooking with children – they have no preconceptions and just see everything as new, both amazing and confusing. I recommend everyone teach a rookie every few years to experience it – it’ll challenge your assumptions and understandings.
There’s a great little bit I reference a lot from David Foster Wallace:
“There are these two young fish swimming along and they happen to meet an older fish swimming the other way, who nods at them and says “Morning, boys. How’s the water?”
And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes “What the hell is water?”
So many of us have been working with NAV before BC, and our knowledge and understanding comes along with us for each stage. We often begin to forget that there’s “water”. I was walking someone through the Gift Basket sample the other day, and I realized that we take for granted a lot of parts. Let’s consider a basic Setup Table example:
There’s a lot of assumptions baked into this, but a few I want to highlight:
- You understand databases enough to know what tables and fields are, as well as Keys and TableRelations (foreign keys), along with understanding that fields have to have an ID, a Name, and a Type, along with decorators like Captions and more.
- You understand that this is a sort of object, which means it can have variables of a global scope (but global just to an instance of this object!) and methods (procedures, which are really slightly wrongly named, as a “procedure” on an Object is a method of the object)
- You understand that an instance of this Object (in this case a table) knows how to think of itself (Rec).
The challenge I’m talking about today is one specific aspect, though, which is the title of the post, “Dr. AL and Mister C/AL”.
The first 34 lines of this file are all a markup/decorator syntax that LOOKS like a sort of pseudo JSON, but isn’t. You have curly braces to define the object itself, then the various building blocks (fields, keys). Each of the building blocks has assignable properties (Caption being a common example). All of those have a (generally) clear and common syntax. Declarative, open brace, properties (assigned via =), child blocks, close brace.
But then…
Kerchunk!
You hit the coding part of objects. In our Setup Table example, you hit line 36 and all those understandings and patterns get thrown out the window. Our Dr. AL suddenly Hulks out and we’re in Mister C/AL land.
You have a new building block called “var” with no braces, no assignables. Soldiering on, you hit the procedure building block.
This has a completely different declaration footprint, such as these procedures and triggers:
Different assignments, different ways of marking ranges (braces vs begin/end). To understand the way this type of code works, you’re now working with pseudo-Pascal, inherited through the ages.
I realized trying to talk someone through all these things that they were having to learn two entirely different languages and rules, both with their own assumptions.
And crazily, you DO have mixing and matching. A page object could have the Field block use as it’s “source” a var or even some of the code. Properties can (sometimes) use variables and codes as their dynamic source as well.
I’m not saying this is anything we specifically have to fix or change, but I think it’ll change my understanding of how I teach people, of how I document it. I might also suggest we need to talk to this challenge in all of our ‘newbie’ focused materials, including the Docs folks.