It's not AND/OR/etc. that is the problem, it is looking at code and converting that to a model of what that code does. in one's mind.
You and I and many others here can do that without even realizing that we do it, so we don't care if we are using LAD or ST or FBD; to someone who does code for a living, it is not so simple.
I read English without thinking about it. From past schooling I can look at Deutsch and usually get a rough idea, though with a struggle. If you put Svenska* in front of me, I might be able to guess at a few words, but the meaning would be a mystery to me.
Some electricians can look at LAD and understand it better than either of us; there is value in that, but the magnitude of that value will be situation- and application-dependent. Show those same electricians some nested if-then-else clauses and the best they can do is blink.
* Svnesk? See what I mean?
First... I don’t generally agree that an electrician can look at LAD and understand it better than a programmer. Can you find “some” electrician that’s better than “some” programmer? Sure. But I don’t think that’s the typical case. They often make mistakes and misinterpret that it would function as
actual schematics rather than what it is which is a series of instructions, often with asynchronous interrupts. And the difference in that interpretation makes a difference. Add anything even remotely non-schematic like and they’re done.
Second, comparing natural languages to programming languages is a false equivalence. For many reasons.
C has 32 keywords. Most natural languages have tens or hundreds of thousands.
With the exception of undefined behavior, there is exactly one way to execute a set of program instructions. Natural languages are ambiguous.
Look, learning a programming language is
not the hard part.
Programming is the the hard part. And they’re different things. This is even the point
you’re basically trying to make. It’s something non-programmers generally don’t get.
But that’s not the same as all languages are equal. I’ve already enumerated some of my preferences.
And LAD specifically...geez. What a waste. It’s only benefit (which you
almost appear to agree with me on) is a vague resemblance to schematics. It’s better at showing simple Boolean logic for people who don’t otherwise understand programming. I’ll give it that. But then that’s it. It’s a one trick pony and its trick kind of sucks. Anything that doesn’t abstract well to an electrical schematic is a complete train wreck in LAD compared to a text language. And modern control systems are more complex than that simple Boolean logic. It’s not that it can’t be done in LAD. It’s that LAD is extremely limited in what it is good at and the trade off isn’t worth it.
So, why not just use LAD in the snippets where it’s not a massive pile of garbage? Because that involves context switching as you navigate different sections of the code and again, the use cases are so trivial that I think the negative impacts of context switching negates any gains the fake schematic code has.
[edit: also, if requirements change, you don’t have to rewrite in ST when it has to change to something beyond what LAD doesn’t suck at]
But what about the electrician that has to troubleshoot the system? Look, I’ve already said that the program is for debugging and the HMI is for troubleshooting. Defaulting to the program as the main source of troubleshooting is lazy and doesn’t work as soon as the electrician finds something non-trivial. The industry went the wrong way with this one in my opinion.
Don’t take this the wrong way. I’m not bashing electricians. I’m bashing the idea that programs have to written in ways for non-programmers to read and use. Sorry. Not interested.