Short-circuit evaluation

miOnKeyb

Why doesn't C/AL use short-circuit evaluation when it is so important in an ERP environment? if cust.get('100') and cust.name='mr-ape' then die();

Slawek_Guzek

miOnKeyb wrote: »

Why doesn't C/AL use short-circuit evaluation when it is so important in an ERP environment? if cust.get('100') and cust.name='mr-ape' then die();

Why do you think it is so important in an ERP environment?

miOnKeyb

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.

miOnKeyb

To clearify short-circuit evaluation, I mean that in a IF statement, the first fail that makes the conditions to broke should stop the execution of the rest..

If a() and b() and c() then COMMIT;

When a() returns false, b() and c() is not tested as they can't make the IF statement to be successful. This is a normal behavior in common (and smart) compilers.

Slawek_Guzek

I know what short-circuit evaluation mean.

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

miOnKeyb

Well, why should I by-pass a fundamental feature? why are you? Are you an ERP-programmer or are you a programmer?

Slawek_Guzek

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.

miOnKeyb

I make pseudo-code or example code, but as i dont wanna get cobol-fingers I have this reaction. And I guess C/AL is the last language/compiler that doesn't profit by short-curcuit evaluation today. Thats the reason for my reaction, I dont wanna hear sob stories from you that ERP-languages has other priorities.

miOnKeyb

My argument: I would like to make nice code and not stumbling code... even in C/AL..

Slawek_Guzek

A real argument, please. Put some weight behind your opinion.

If you have anything supporting your view...

miOnKeyb

nope, sorry.

miOnKeyb

wrong attitude, your play is very wrong..

miOnKeyb

whats your opinion of bitwise operation within C/AL? as MS made an eqauls between options and Enums..
But I guess you have no idea what im talking about?

miOnKeyb

Thats why Im a programmer and you are an ERP-programmer..

Slawek_Guzek

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

miOnKeyb

Try a programmers book, pls, this forum would love a differnent voice from you.

Slawek_Guzek

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

I love to read and widen my horizons...

SilverX

I see you guys have some kind of "discussion" here. While I tend to identify with the opinion of miOnKeyb, even though the arguments "only" good style, the use of short circuit evaluation are common practice in most high-level languages and he has certainly only registered for trolling, one should never forget that this behavior has existed in AL for decades.

Hundreds of developers have developed solutions on this basis and a change here could cause existing code to not run correctly. Especially bad developers, and of whom there are unfortunately more than I like to see in the Dynamics NAV world, often write constructs that I assume would fail with such a change.

I am myself an advocate of modern development, my colleagues can sing a song, almost a lament, of it. And I hate bad style. Nevertheless, the compatibility argument cannot be denied and I have to fully support the opinion of Slavek.

A year ago I had a case with Microsoft about problems in the standard application due to missing short circuit evaluation. But I do not close my mind to reasonable arguments regarding compatibility.

miOnKeyb, if you really don't only want to troll, then I recommend the discussion with the product managers at Microsoft. Because a change will only work this way.

Miklos_Hollender

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.