AEL in asterisk

Recently, quite a few articles on the asterisk have appeared on the hub and in all articles the authors use the standard extensions.conf to describe the dial plan. I will not describe the recording format in extensions.conf here, but just try to briefly describe its differences with configuration files in the AEL format (extensions.ael), which are actually quite few, but ael adds a lot of convenience. In the future, for convenience, I will call the dial plan described in extensions.conf the "normal" format, well, and ael - respectively, ael. Let's look at an example of a simple dial plan'a in the usual format:
;

[internal]
exten => s, 1, Answer                                                             
exten => s, n, Background (someivr)
exten => s, n, Read (intgroup ,, 3)
exten => s, n, Goto ($ {intgroup}, 1)
exten => XXX, 1, Dial (SIP / $ {EXTEN})
exten => XXX, n, HangUp

And this is how the same context will look in the ael syntax:

context internal {
	s => {
		Answer;
		Background (someivr);
		Read (intgroup ,, 3);
		Goto ($ {intgroup}, 1);
	}
	XXX => {
		Dial (SIP / $ {EXTEN});
		HangUp
	}
}

So the differences are obvious. For me, one of the main advantages of ael is the convenience of reading the config: even with this small abstract example it can be seen that reading and understanding the config is easier. Although, I admit that this is subjective. The second thing that immediately catches your eye is the lack of priority (s, n in the code above, however, as noted in the comments , priority is no longer required there) in the description of dialplan.
Why aren't they? Or rather, why are they in the description of a regular dialplan?
If you did not deal with the asterisk and its regular dialplan, then you will be surprised to learn that it does not have cycles or conditions. There is only a conditional transition (gotoif), with the help of which, in principle, even cycles can be organized, but the convenience of this approach is very doubtful. Let's imagine the simplest ael code that will output true or false to the asterisk console:

if ($ {var} = foo) {
	NoOp (true);
}
else {
	NoOp (false);
}

In normal form, this condition will look like this:

exten => 1,1, GotoIf ($ [$ {var} = foo]? label1: label2) 
exten => 1, n (label1), NoOp (true)
exten => 1, n, Goto (end_of_if)
exten => 1, n (label2), NoOp (false)
exten => 1, n (end_of_if), ...

Not only have we lost “readability”, we also have to either statically assign priorities everywhere (and get absolutely non-extensible code), or come up with labels for every sneeze. Yes, ael also has labels, only the need for them practically disappears, since the syntax allows you to get away from goto as such.

s => {
	Answer;
	somelabel:
		HangUp
}

In addition to the direct conditions (if / else) in ael, you can use the switch statement with the usual syntax:

 _777X => { 
         switch ($ {EXTEN}) { 
              pattern N11: 
                   NoOp (You called a N11 number-- $ {EXTEN}); 
                   break; 
              case 7771: 
                   NoOp (You called 7771!); 
                   break; 
              case 7772: 
                   NoOp (You called 7772!); 
                   break; 
              case 7773: 
                   NoOp (You called 7773!); 
                   // fall thru- 
              default: 
                   NoOp (In the default clause!); 
         }; 

Now try to describe the same configuration, but in the usual format? The same thing.

Now imagine that you have a more or less complex dialplan, which will grow and expand over time, new functionality will be added, there will be many conditions, queues, and so on - here without ael everything will be pretty sad. For work, you periodically have to set up an asterisk and customer requests are quite exotic. Solving these tasks without ael would be much more difficult.

In fairness, it should be said that the asterisk converts the ael configuration to the “normal” format and works with it already (you can check through asterisk -rx “dialplan show”), so its syntax is also necessary. But ael can make life much easier, especially since you see that its syntax is pretty obvious, and if you have experience writing regular dial plans, switching to ael will be easy.