Short-circuit evaluation

I know what short-circuit evaluation mean.

Has it crossed your mind that maybe, just maybe, the ERP world has a bit different priorities?

Also:
Why, exactly, this:

OperationSuccessful := CustomerExists('1000') AND CustomerUpdate('1000', 'ABCDEF') AND UpdateExternalSource('1000');

you deem far more superior than this:

if CustomerExists('1000') then
 if CustomerUpdate('1000','ABCDEF')  then
     OperationSuccessful := UpdateExternalSource('1000');

A real agrument, not an opinion please.

Yes, I can see exactly that: you say you are a programmer.

Thanks for pointing me in the right direction. Perhaps you could recommend some.

I love to read and widen my horizons...

miOnKeyb wrote: »

Because this of this?

OperationSuccessful := CustomerExists('1000') AND CustomerUpdate('1000', 'ABCDEF') AND UpdateExternalSource('1000');

instead of writing this:

if CustomerExists('1000') then
if CustomerUpdate('1000','ABCDEF') then
OperationSuccessful := UpdateExternalSource('1000');

No person who writes code whats to do the lower option in my opinion.
Short-circuit evaluation is found in almost any compiler today and as NAV is welcoming interop by .NET and aiming for programmers this feature should not be forgotten. To adapt C/AL to this should not affect any older code. If it does, the code itself is to be blamed as bad code.

The longer form is much better because you can test, debug the code by commenting out lines.

Please understand that the whole is not meant for super professional programmers. It is meant for functional consultants who are capable of learning a little bit of "scripting" and customize the code without having to waste time with things like writing a detailed spec to real developers.

They would not be able to test your one-liner by splitting it into multiple lines and commenting it out selectively.

Your long for example is very easy to test and debug. I change it to if CustomerExists('1000') then begin message('customer found') and so on, add similar stuff to the rest of the lines.

Maybe if there was a very good debugger where you could check each return value by hovering over the function calls could replace it, but that would be again something maybe too difficult to use for mostly functional consultants.

I personally can use the debugger because I am doing this for 15 years now, people do learn something in 15 years, but really I just prefer putting MESSSAGE and ERROR into the code, it is just simpler, more obvious that way.

So that is why.

Your point of programmers vs. ERP programmers is valid, but I see it the other way around. We rarely need "real programmers". Real programmers usually don't know about stuff like accounting. So we waste time writing long specs for them. Rather we take functional consultants who have a little bit of programming ability (can understand the idea of function, if then, repeat until) and train them to code. While for large add ons and suchlike you need more programming ability for that, customizing the standard code that is enough. And then instead of writing long specs the same person who understands the business need, who has the ability to check if it is in accordance with accounting principles and regultions, can also develop.

Not all ERP is like this, for example Compiere is fully Java and developed by real programmers, but this has always been the specialty of Navision to be able to turn functional consultants into "scripters" and thus save specification time. This is very necessary for smaller business who cannot afford to buy more than 50 days for a project.