PC programming and PLC programming are radically different paradigms. I know I’ve talked about this before, but I wanted to explore something that perplexes me… why do so many PC programmers hate ladder logic when they are first introduced to it? Ladder logic programmers don’t seem to have the same reaction when they’re introduced to a language like VB or C.
I mean, PC programmers really look down their noses at ladder logic. Here’s one typical quote:
Relay Ladder Logic is a fairly primitive langauge. Its hard to be as productive. Most PLC programmers don’t use subroutines; its almost as if the PLC world is one that time and software engineering forgot. You can do well by applying simple software engineering methods as a consequence, e.g., define interfaces between blocks of code, even if abstractly.
I’m sorry, but I don’t buy that. Ladder logic and, say C#, are designed for solving problems in two very different domains. In industrial automation, we prefer logic that’s easy to troubleshoot without taking down the system.
In the world of C#, troubleshooting is usually done in an offline environment.
My opinion is that Ladder Logic looks a lot like “polling” and every PC programmer knows that polling is bad, because it’s an inefficient use of processor power. PC programmers prefer event-driven programming, which is how all modern GUI frameworks react to user-initiated input. They want to see something that says, “when input A turns on, turn on output B”. If you’re familiar with control systems, your first reaction to that statement is, “sure, but what if B depends on inputs C, D, and E as well”? You’re right – it doesn’t scale, and that’s the first mistake most people make when starting with event-driven programming: they put all their logic in the event handlers (yeah, I did that too).
Still, there are lots of situations where ladder logic is so much more concise than say, C#, at implementing the same functionality, I just don’t buy all the hate directed at ladder logic. I decided to describe it with an example. Take this relatively simple ladder logic rung:
What would it take to implement the same logic in C#? You could say all you really need to write is D = ((A && B) || D) && C; but that’s not exactly true. When you’re writing an object oriented program, you have to follow the SOLID principles. We need to separate our concerns. Any experienced C# programmer will say that we need to encapsulate this logic in a class (let’s call it “DController” – things that contain business logic in C# applications are frequently called Controller or Manager). We also have to make sure that DController only depends on abstract interfaces. In this case, the logic depends on access to three inputs and one output. I’ve gone ahead and defined those interfaces:
public interface IDiscreteInput
{
bool GetValue();
event EventHandler InputChanged;
}
public interface IDiscreteOutput
{
void SetValue(bool value);
}
Simple enough. Our controller needs to be able to get the value of an input, and be notified when any input changes. It needs to be able to change the value of the output.
In order to follow the D in the SOLID principles, we have to inject the dependencies into the DController class, so it has to look something like this:
internal class DController
{
public DController(IDiscreteInput inputA,
IDiscreteInput inputB, IDiscreteInput inputC,
IDiscreteOutput outputD)
{
}
}
That’s a nice little stub of a class. Now, as an experienced C# developer, I follow test-driven development, or TDD. Before I can write any actual logic, I have to write a test that fails. I break open my unit test suite, and write my first test:
[TestMethod]
public void Writes_initial_state_of_false_to_outputD_when_initial_inputs_are_all_false()
{
var mockInput = MockRepository.GenerateStub<IDiscreteInput>();
mockInput.Expect(i => i.GetValue()).Return(false);
var mockOutput = MockRepository.GenerateStrictMock<IDiscreteOutput>();
mockOutput.Expect(o => o.SetValue(false));
var test = new DController(mockInput, mockInput, mockInput, mockOutput);
mockOutput.VerifyAllExpectations();
}
Ok, so what’s going on here? First, I’m using a mocking framework called Rhino Mocks to generate “stub” and “mock” objects that implement the two dependency interfaces I defined earlier. This first test just checks that the first thing my class does when it starts up is to write a value to output D (in this case, false, because all the inputs are false). When I run my test it fails, because my DController class doesn’t actually call the SetValue method on my output object. That’s easy enough to remedy:
internal class DController
{
public DController(IDiscreteInput inputA, IDiscreteInput inputB,
IDiscreteInput inputC, IDiscreteOutput outputD)
{
if (outputD == null) throw new ArgumentOutOfRangeException("outputD");
outputD.SetValue(false);
}
}
That’s the simplest logic I can write to make the test pass. I always set the value of the output to false when I start up. Since I’m calling a method on a dependency, I also have to include a guard clause in there to check for null, or else my tools like ReSharper might start complaining at me.
Now that my tests pass, I need to add some more tests. My second test validates when my output should turn on (only when all three inputs are on). In order to write this test, I had to write a helper class called MockDiscreteInputPatternGenerator. I won’t go into the details of that class, but I’ll just say it’s over 100 lines long, just so that I can write a reasonably fluent test:
[TestMethod]
public void Inputs_A_B_C_must_all_be_true_for_D_to_turn_on()
{
MockDiscreteInput inputA;
MockDiscreteInput inputB;
MockDiscreteInput inputC;
MockDiscreteOutput outputD;
var tester = new MockDiscreteInputPatternGenerator()
.InitialCondition(out inputA, false)
.InitialCondition(out inputB, false)
.InitialCondition(out inputC, false)
.CreateSimulatedOutput(out outputD)
.AssertThat(outputD).ShouldBe(false)
.Then(inputA).TurnsOn()
.AssertThat(outputD).ShouldBe(false)
.Then(inputB).TurnsOn()
.AssertThat(outputD).ShouldBe(false)
.Then(inputA).TurnsOff()
.AssertThat(outputD).ShouldBe(false)
.Then(inputC).TurnsOn()
.AssertThat(outputD).ShouldBe(false)
.Then(inputB).TurnsOff()
.AssertThat(outputD).ShouldBe(false)
.Then(inputA).TurnsOn()
.AssertThat(outputD).ShouldBe(false)
.Then(inputB).TurnsOn()
.AssertThat(outputD).ShouldBe(true); // finally turns on
var test = new DController(inputA, inputB, inputC, outputD);
tester.Execute();
}
What this does is cycle through all the combinations of inputs that don’t cause the output to turn on, and then I finally turn them all on, and verify that it did turn on in that last case.
I’ll spare you the other two tests. One check that the output initializes to on when all the inputs are on initially, and the last test checks the conditions that turn the output off (only C turning off, with A and B having no effect). In order to get all of these tests to pass, here’s my final version of the DController class:
internal class DController
{
private readonly IDiscreteInput inputA;
private readonly IDiscreteInput inputB;
private readonly IDiscreteInput inputC;
private readonly IDiscreteOutput outputD;
private bool D; // holds last state of output D
public DController(IDiscreteInput inputA, IDiscreteInput inputB,
IDiscreteInput inputC, IDiscreteOutput outputD)
{
if (inputA == null) throw new ArgumentOutOfRangeException("inputA");
if (inputB == null) throw new ArgumentOutOfRangeException("inputB");
if (inputC == null) throw new ArgumentOutOfRangeException("inputC");
if (outputD == null) throw new ArgumentOutOfRangeException("outputD");
this.inputA = inputA;
this.inputB = inputB;
this.inputC = inputC;
this.outputD = outputD;
inputA.InputChanged += new EventHandler((s, e) => setOutputDValue());
inputB.InputChanged += new EventHandler((s, e) => setOutputDValue());
inputC.InputChanged += new EventHandler((s, e) => setOutputDValue());
setOutputDValue();
}
private void setOutputDValue()
{
bool A = inputA.GetValue();
bool B = inputB.GetValue();
bool C = inputC.GetValue();
bool newValue = ((A && B) || D) && C;
outputD.SetValue(newValue);
D = newValue;
}
}
So if you’re just counting the DController class itself, that’s approaching 40 lines of code, and the only really important line is this:
bool newValue = ((A && B) || D) && C;
It’s true that as you wrote more logic, you’d refactor more and more repetitive code out of the Controller classes, but ultimately most of the overhead never really goes away. The best you’re going to do is develop some kind of domain specific language which might look like this:
var dController = new OutputControllerFor(outputD)
.WithInputs(inputA, inputB, inputC)
.DefinedAs((A, B, C, D) => ((A && B) || D) && C);
…or maybe…
var dController = new OutputControllerFor(outputD)
.WithInputs(inputA, inputB, inputC)
.TurnsOnWhen((A, B, C) => A && B && C)
.StaysOnWhile((A, B, C) => C);
…and how is that any better than the original ladder logic? That’s not even getting into the fact that you wouldn’t be able to use breakpoints in C# when doing online troubleshooting. This code would be a real pain to troubleshoot if the sensor connected to inputA was becoming flaky. With ladder logic, you can just glance at it and see the current values of A, B, C, and D.
Testing: the C# code is complex enough that it needs tests to prove that it works right, but the ladder logic is so simple, so declarative, that it’s obvious to any Controls Engineer or Electrician exactly what it does: turn on when A, B, and C are all on, and then stay on until C turns off. It doesn’t need a test!
Time-wise: it took me about a minute to get the ladder editor open and write that ladder logic, but about an hour to put together this C# example in Visual Studio.
So, I think when someone gets a hate on for ladder logic, it just has to be fear. Ladder logic is a great tool to have in your toolbox. Certainly don’t use ladder logic to write an ERP system, but do use it for discrete control.
You’re dead on Scott! As a dev that stared at ladder logic for a while I’d add that the hardest thing I found to deal with is that every rung is independent. When you expected to set a value and then have something run once, it just keeps running over and over. However, with a bit of time you learn how to manage those situations and know how to handle the same cases.
🙂
A fascinating post giving a bit of insight into Ladder Logic! It’s an area I’m thinking of pursuing (PLCs, systems control and automation etc.) after I graduate and this was a nice and informative post. Thank you.
I’ve read both your post and StackOverflow question, and I don’t buy your reasoning. Using C# the way you’ve shown is – well – not the best idea.
Consider something more real. A system with say 40 pumps, 80 valves, half of them working with simple start/stop/open/close principle, the others are controlled with PIDs, inverter drivers etc.
For such a system, “You can do well by applying simple software engineering methods as a consequence, e.g., define interfaces between blocks of code, even if abstractly.” is a perfect argument in my opinion.
Abstract a kind of process devices using whatever you can – function blocks, subroutines… Define interface contract for the kind of devices. Build “higher layer” software upon this contract. Ensure that high level code do not depend on low level details.
You can express all of this with ladder logic if you want. Now, compare the time you need to implement and test such a system in ladder logic, using or not using abstractions.
@AJ: If you’re only thinking about implementation time, you’re missing the point. On an assembly line where downtime costs $5000 per minute, troubleshooting time far outweighs the time it takes to implement something. This is something that traditional PC programmers never seem to be able to understand about industrial automation until they’re standing at a laptop next to an assembly line with a production manager asking them how long it’s going to take to fix the problem, every 30 seconds. If you haven’t been in that situation, then I question your qualifications.
The C language is a language much more powerful than straight, if I see it after spending more than 6 years in the area of ​​programming in both software applications for PC and PLCs, as well as hardware design automation. The language was designed for a ladder ON / OFF and used by electricians craft operators. Today’s electronic control and logic as that used by the C language is more efficient and effective programming time as well as being simpler, occupies less area and can get to program the PLC Hardware outlining whether to change the environment of programming. Try to set a signal processing, vector control, etc.. with the language ladder and see the difference.
I Like the way he says compare it to C#
I got news for you, most micro controllers use C or C+ not C# The reasons for that is, C# is bloated, and under a bunch of patents that scare the bgezers out of manufacturers. They don’t trust Microcrap, they have been burned by them in the past. Even hobbyists use things like Arduino that are open source, and running C.
Microcrap is trying hard to brake into the micro controller world, but from what I can see, they are losing the war. As for ladder line, I think its a dead language. Flow chart languages are as fast and can do anything that C can or even C# can do. Its just that there are still a bunch of old timers out there that are still using Ladder.
I agree, Ladder is far more suited for the Industrial Automation world than C. They’re different languages for different applications.
Besides, the language has evolved quite a bit in RS Logix 5000. I use both the 5000 and 500 platforms at work and I pull my hair out when I have to use 500. 5000 actually gives you the ability to use “subroutines” of a sort in their Add-On instructions. This avoids having to program the same ladders over and over again with different addresses. Instead, you create the ladder once with parameters, and then call the blocks in your main ladder, providing addresses to “fill in” the parameters for each block. You can reduce a program of hundreds of rungs down to one or two because the program is just “recycling” the logic with different values.
Can you provide source fro this example
I don’t mean to resurrect a dead post, and while I see and understand where you are coming from, I think you are missing the point of what is practically impossible for Ladder Logic to do in any space-efficient manner. Sure it is fine for simple if-this-then-that style programming, but lets talk about data-driven programming and sequential programming for a second. What if I want to program an elevator using it’s basic if-this-then-that style: if user presses up button, go to their floor, stop, open door, wait 10 seconds, try close door, loop (if door blocked, stop, open, wait 10s try close), if inside button pressed, go to that floor, stop along the way if a user presses the up button as you reach it, etc…. This is a really huge state machine in ladder logic, but a simple sequential algorithm in a procedural language, even if it does require a few event listeners.
Here is another practical example, lets say that an assembly line needs a part-selection interface for the operators, which handles an SQL database of information for each part. Write a piece of ladder logic code to handle the transfer of bits from an RS-232 connection from this machine into the appropriate registers to use the data. Also, much of this data requires mathematical processing to handle effectively on the PLC side… Good luck. I’ve seen code like this take thousands of rungs, and I’ve personally been spending months dianosing just two of these such codes at my factory.
All this to say that ladder logic is fine for systems that you would EXPECT electricians to be capable of maintaining, such as simple processes, and code AFTER data has been processed and placed in proper registers simply waiting to be used, but if you want to apply real COMPUTATION to your assembly line, rather than just signaling, it’s absolutely dreadful.
@Ryan – Thanks for you comments. Your first paragraph is completely incorrect. Elevator control systems are definitely coded in ladder logic and it wouldn’t take much effort. I would consider such a system to be a toy compared with other machines I’ve programmed. If you want things to happen in a sequence, you just use the Step Pattern. If you want to choose between which sequence to execute, you use the Mission Pattern.
If you don’t like doing that in Ladder Logic, you can use Sequential Function Chart. But that’s not necessary.
Your idea of looping until an input turns on is usually wrong because the rest of your logic stops while you’re looping and waiting, and in ladder logic the other parts of your program keep running. Never loop on an input. And if you don’t loop on an input then you’ll have to keep a state machine going anyway, so you haven’t improved the situation.
Your second paragraph is correct. Use the right tool for the job.
Third paragraph: I would expect an electrician to be able to diagnose an elevator system. I think that’s pretty obvious. Also, if you need decent computation, why not just use Structured Text? All modern PLCs support that. I agree none of them do database access well yet, so I would definitely go to some other system or language to integrate with a database. In my case that’s typically C# and .NET, but could be anything.
Great post, Scott. As an n-tier C# developer for the last few years (understatement..) I am dipping a toe in PLC and automation.
Your explanations of the ladder are very clear, and being a developer for a while I appreciate the push back that you will always be getting from an industry that puts so much focus on almost tribal loyalty of esoterics.
I’m with you, insofar as you must use the right tool for the job, as I have seen so much over engineered nonsense in my time that seems to have been done merely to further a current fad, rather than looking at the clients concerns such as maintenance and readability.
I know this is an older post, but had to comment regarding the development and test times between a C# solution vs. Ladder.
I’ve been coding, in some language or other, since 1977. Personally I’m not the type of developer that look down on ANY programming language or methodology. I have enough experience to know that it’s the solution that needs to fit the need, not the other way around. I’ve been in this long enough to know that [any good developer] NEVER marries himself to a specific set of solutions, trying to bend and twist the need to fit. That’s an injustice to the customer and developer.
So when you showed your initial C# solution:
if(((A & B) || D) && C)
were, technically correct and would have worked. But then the solution became one of satisfying methodologies of PROPER execution of said solution…
So.. here is the question I ask. In this scenario, is C# the loser because of a limit of it’s ability to solve the need.. or is it victim of an over convoluted coding methodology?
Sometims… all you need IS a hammer, it seems.
I will only say after 20 years of both IT and Controls that if my life relies on it ladder every time. If it has no consequences for failure use Microsoft all you want.
@Ph – if your life relies on ladder logic, you’re doing it wrong. All systems that have the potential to harm you need a certified safety system that’s built with certified safety components. Both the wiring design and the logic in the completely separate safety controller needs to be reviewed and stamped by a licensed professional engineer. The entire system needs to use dual redundant components where every possible failure is detected and no single failure can produce a loss of safety function. Your choice of programming language has nothing to do with that.
After 25 years of programming experience, in multiple languages on multiple platforms and IDEs, I can authoritatively say that this article is the most uninformed pile of poo that I have ever read on the internet.
If any developer working for me tried to implement a simple, one line Boolean logic statement with all those classes and cruft they would be fired that same day.
The original line of code:
D = ((A && B) || D) && C;
…provides the EXACT same functionality as the Ladder program.
On the other hand, if I want to write a program of any reasonable complexity, I can encapsulate functions and data that belong together into a class and use TDD to test the public interfaces of that class, easily reuse that class, package that class in a library for sharing with other projects and about a million other things that are impossible with Ladder.
And you are WAY off base regarding debugging. With .NET (C# or C++) I can easily see the values of any variable during execution, including on deployed systems (just use remote debugging), step forward or backward through the code, change values on the fly, etc., etc. There is not another debugger on the planet that can touch the features of Visual Studio.
Then let’s talk about what OTHER features you’re giving up with Ladder, including the entire .NET library of about 20,000 classes for everything from JSON serialization, graphics, file and memory I/O, connectivity (TCP, UDP, you name it), etc. With the latest .NET Core, you can stand up a custom web server in about 10 lines of code. Let’s see you do that in Ladder. I can generate a graphical visualization of an entire codebase with 2 mouse clicks. I can generate automatic API documentation. If I need custom functionality that is not in the .NET framework, I can download one of the MILLIONS of .NET projects on GitHub. With a single click, I can see an annotated version of my code file that tells me the user and date of the last change on that line. I can add analytics to my project with less than 10 lines of code and get a cloud-based dashboard that shows me who used every feature in my application, and when, as well as any errors that were handled, or unhandled. I could go on for HOURS. Ladder logic and PLC programming is literally decades behind development using C#/C++ with smart I/O modules like Turck blocks.
@GlenHandke – Yeah, you’re right. I was probably exaggerating for effect. Those C# constructs are there for organizing and managing large projects. As PLC projects are getting larger, we are pulling more object-oriented ideas into our PLC projects. We are, however, risking leaving many technicians out in the cold when we do this, and we need to be aware of it. Also, visually seeing the ladder representation of “D = ((A && B) || D) && C” vs. seeing that code on the screen is easier for debugging if the person doing the debugging has any amount of electrical background.
Excellent write-up and a great discussion.
I think many of you have valid points. My $0.02 are that every language/format has places where it is better suited than others.
Simple on/off pumps? Create a function block, drop it in ladder, ST, etc.
Complex pumps that have a startup sequence and require auxillary motors? SFC.
Crazy ass high HP gas flow turbine control that no one should ever mess with? C.
There is no one right language; each language has applications that it is suited best for (and everyone has their own preference and opinions)
My goal has always been to write the most efficient and readable code for the client and their support team.
My experience with c# is limited, but I still would use any one of the IEC languages because of their simplicity, readability and reliability. I do not yet trust event driven code for PLCs.
Scott is 100% right on this one.
I was never a big fan of ladder, always used ST or IL, but recently it just clicked. Until you have enough real world experience and have been down the wrong path a few times, it is difficult to grasps this, but ladder is probably THE BEST language for plc programming. You can throw in some calculations in ST, but that’s basically all you need.
I would even say, that most traditional software programming practices shouldn’t be applied to plc programming or be applied carefully. You will get into awkward and difficult to diagnose program structures if you apply them every time. Trust me, I’ve done that…
Event driven style in plc gets difficult soon, using too many interfaces get difficult, using a lot of local data also gets difficult.
Maybe my opinion will change after a few years, but now, 4 years in – I definitely agree with this article.
@Juozas – Thanks. One thing that Glen also misses is that you can’t (or should never) “step through” a live running PLC program. The machine is moving around and if you pause execution with a debugger you’re effectively e-stopping the machine but you’re unable to let the machine react in the precious milliseconds to bring it to a controlled stop. The best example of this is with servo controlled motion. If you suddenly stop the program you can physically crash axes into each other. The only thing you can step through in a PLC program is some data logging code you wrote offline and downloaded to a test PLC at your desk.
That said, we have used interfaces and test driven development in a couple recent projects here. It can work, but the complexity is much higher. You certainly rule out having typical technicians being able to go online and troubleshoot your code (at least those parts). When you call a function block through an interface, and it can have many different implementations, it’s not obvious how you jump to the actual implementation. Likely just needs better editing and debugging though. Nothing beats good old ladder for ease of troubleshooting (and bypassing equipment failures).
Creo que casi el 100% de plc hechos en el mundo están hechos para programarlos en ladder.
@Pinzon – no, most major PLCs now conform to the IEC-61131-3 language specification, so they should support, at a minimum, Ladder Logic, Function Block Diagram, Instruction List, Sequential Function Chart, and Structured Text languages. All of these language implementations will be proprietary though.
Si la mayorÃÂa y hacen énfasis en el uso de ládder. Vi algo interesante de mitsubishi ( ládder estructurado).
Bias :
I am a fanatic of C.
Standard ISO C, that it is supported by every silicon piece that has the pretense to be called a processor.
C is the best system programming language.
Current state :
I get to do a bit of both worlds : plc programming and C / C++..C#…VB… .net.
Every time i have to write code for plc’s i mesmerize at the huge ammount of time i loose to point click place relay/coil/rungs…
8 hours of relay logic in plc’s with all the various developing environment devilish trickery of : ” you have to checkbox the n-nested checkbox in the menu to make it work”
Can be done in 1 hour of ISO C code.
Then why should we program in that stupid ladder logic ?
I got to understand it pretty fast when sending a technician to troubleshoot a 10 MW industrial furnace….
You, readers, that will come here, remember :
There are a very small number of programmers, capable programmers, especially in system oriented languages.
Our job is to write automation algorithms for systems, but one very important metric is how easly those systems are mantained.
And ladder language, unfortunately has this power of being extremly simple to debug by anybody.
It,s this simplicity of use that’s important, because not everywhere in the world you will find an available C programmer. And if you do, they will be very expensive.
( you don’t want to pay 3000 euro for 2 days just he cand find wich one of your 3 cents sensor died, you would prefer your already hired electrician could be able to do that)
So ladder, altough i hate it with all my heart, it’s here to stay. And it is our job to express with it, the simplest rules that the machines must obey.
( please , never ever talk about c# interfaces, object oriented crap with the intention of using that code and paradigm to control hardware. Never. Ever. Again. That language ( and .net) is for other domains )
Coman Nutu
Automation systems engineer
So, in summary, ladder logic is designed after concepts that technicians are already familiar with in order to reduce difficulty of learning the subject.
Reusing that mental “interface”, so to speak, eh? Very clever.
Interesting post and discussion, I do agree with most Scott says, I am from an electrical maintenance background and currently work as a Controls Engineer, Most companies employ electrical biased maintenance engineers as they can diagnose both electrical circuitry and understand ladder logic this results in one man (an experienced maintenance tech) been able to quickly diagnose faults and get machines back quickly running, if you show most electrical biased engineers C languages it would be like asking them to read Chinese when all they understand is English, I know this because I have been in that situation.
This is however a real problem in that plants are more data driven as Industry 4 and Iot is implemented, the way our comany and I know other big automotive plants have solved this is by in house or third party written process control applications, in our example we have a process control application that does all the SQL data handling and all the web based based stuff, Our global manufacturing IT guys take care of that stuff and put it into nice easy to use applications for controls engineers, It is then our job to pass relevant data from the PLC to PC application using data blocks and communicating Via open protocol or OPC. This solution works very well the machines are capable of communicating with the web/PC passing over data via Ladder and the IT guys are happy.
I am sure there are many other similar solutions used, I think comparing the two languages against each other is useless because they are so far apart in relevant uses.
P.S I actually stumbled across this thread while researching PASCAL as SIemens PLC’s have a language functionality called SCL ( structured controll language) this is based on pascal and I am sure you C/C++ maybe that is another bridge between this issue as so far I am picking it up pretty well.
Regards
Patrick
I agree on the ease of maintenance aspect of ladder, but the rest of the comparison is IMO beating on a dead horse, why would you use C# to program hardware logic? This is not the purpose of this language and I’ve never seen anyone argue otherwise.
I would argue that most of the control engineers job is to use the right tool for the job.
You will use ladder for I/Os, and other aspects you have mentioned.
You will use SFC for repeating states.
C for advanced, thoroughly tested control algorithms.
SCL/Structured text for calculations/comm. mapping/conversion, etc. (why the hell would you use numerous ladder rungs for movement and calculation of data when you can use one line of ST? If someone can’t figure Y:=REAL_TO_INT(A+(B*1000)); , he has no business accessing PLCs in the first place.)
You would not use a saw to hammer a nail and hang a picture on the wall, so don’t do similar mistake in the programming world.