Are cuts that bad in programming?
I agree with @dasblinkenlight and @mbratch. Additionally, I think it's helpful to think in terms of green cuts and red cuts.
A green cut is one that doesn't affect the logical behavior of the program, just the performance. They're a way for you to tell Prolog that you know if it keeps going it's not going to bear any fruit. Green cuts are never necessary—they just improve performance. There's so much else to get a handle on when you're first learning Prolog, it just seems like adding extra complexity for a small benefit.
A red cut does affect the behavior of the program. As @mbratch said, new users often throw cuts around to "tidy up" the output. New users often treat the Prolog query prompt as the user interface for their program. These cuts make their predicates less general and less useful in the process of making the output nicer. There are also some alternatives that are clearer, like once/1 which gives you a single result. Experts use red cuts very delicately—there are situations where it is much more efficient than a logical approach—but if you have access to a purely logical formulation it's preferable. Often predicates with errors in the use of cut have problems with "backwards correctness" that arise later on when you're depending on the predicate as part of other predicates. These can be difficult to debug and fix.
I'm not sure I'd call them a "sin" but I mostly agree with your professor for beginners. It's best if you get experienced at solving problems logically without using the cut. Then the cut can be introduced later when you have a better sense of what is easy and what is hard. Using it too much early on makes you depend on it as a crutch for procedural programming.
In the beginning, try to focus on the pure declarative part of Prolog for a simple reason: It is that part which distinguishes Prolog from other programming languages. Focus on the pure, monotonic part of the language and avoid cuts altogether. How else can you expect that you immerse in this programming paradigm?
However, you will certainly encounter certain challenges. In particular when trying to encode if-then-else constructs and general negation. When the condition for such a construct needs to succeed for the if-part and needs to fail for the then-part, you are into non-monotonic code. However, Prolog was never built to handle such code in a clean manner
Instead, Prolog knows only if-then rules. So essentially you will have one rule for one part and another for the other part. That will look to you quite unusual in the beginning, but it permits you to experience very pure code.
See my page for examples of pure code.
See also: Features of good Prolog code? Funny that the interesting questions always get closed on SO.
For green or red cuts, simply take for granted that there are almost no green cuts. For, if you want to use cuts in a safe manner you will have to add extra conditions ("guards") that do not make any sense otherwise. It's really something for optimizers, compiler writers and the like.
Prolog without if and else statements
Knowing when to use cut in prolog
Why double negation doesn't bind in Prolog
To keep my answer a bit more balanced, here is an example of a clean way to improve efficiency with cut:
- Prolog append with cut operator