I first programmed (FORTRAN IV) in 1972. At the time, the main program "editor" was a key punch machine that punched 80 column cards. You assembled  a deck with your program and certain control cards, possibly even including a copy of the Fortran Compiler into a deck and you submitted your deck at a window to another person. In a small shop, that person might be the operator and the computer might even be visible somewhere behind the operator - through a window, as computers were noisy and had to be enclosed. Twenty four hours later, you picked up the results at a window.
If there was any error in your program (or elsewhere in the deck), what you got was a failure report and went back to the keypunch to correct it. When done, you started another twenty four hour cycle.
As you can imagine, getting the syntax correct the first time was extremely important.
Now, I program using Eclipse. The system is so efficient that it finds and highlights my syntax errors as I make them. It also finds and maybe corrects lexical (spelling) errors. It completes statement blocks and indents as I go.
There are two lessons here. One is that "getting the syntax right the first time" was much more critical then than now. But also, Eclipse error highlighting and correction actually teaches the student over time not to make the mistakes that are the least important of all. Semantic and intent mistakes are what we need to focus on, and what the teaching (and grading) should focus on, not the kinds of things that tools like eclipse can (a) find/correct and (b) teach us incrementally.
It is useful to be able to write code by hand. Sometimes you are on a bus and need to capture an idea and all you have available is a pencil and paper. But you don't need perfect syntax to capture the idea.
The answer here from Peter notes that in some extremely important tests, students will need to write out code by hand. But the comments currently listed with it also indicate (correctly IMO) that the grading is very gentle on the kinds of things that tools can help us with.
tl;dr: Use good tools in teaching. Focus on the higher level concepts and let the tools correct errors of the formal language as well as help the students see what they should have written.
If you want them to really learn to get the syntax right the first time, use a key punch and 24 hour turnaround. Other forms of abuse might work just as well. But.... well, no, don't do that.
 The term assembler (or assembly) language comes from this physical construction of a card deck.
==will lead to logical errors, because it almost always evaluates to
true- as in , "why yes, this value can be or just has been assigned to that variable". So... test on debugging code. Both syntax errors and logic errors. Add in testing for edge cases, and you are part way on to teaching how to create unit tests :) $\endgroup$