I am taking an AI course this semester in which we are learning Prolog. Our lecturer has told us to try and avoid using cuts in our assignment, however, for a couple of the questions I can't seem to avoid using them. I'm just curious why are cuts considered a sin (lecturers words)? I understand it's kind of a short cut but I have used them knowing exactly how they effect my program.
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.