You don't shoot yourself in the foot in the same way one does in C. With carelessness, you more... suffocate yourself with your own towers of (probably useless) abstractions. It's like having a power drill when all you knew was a screw driver... and then drilling holes and driving screws every chance you get without regard to a larger structure.

Unlike C, the powerful (and safe) language features are a boon to software engineering projects, as long as you're doing was dreamcompiler said: software engineering and not "just programming".

I disagree with the thesis that the more restrictive one is, the better it is for software engineering. We've empirically disproved this time and time again with every supposedly "simple" language evolving way, way past its original design goals. Python, Go, and even Scheme are great examples.

That's a great way to put it. With C you can build a car. With Lisp you can build a better car but it's also very tempting to build a car factory, and a motor factory to supply that, and an iron ore mine to supply the motor factory, and just for grins let's go ahead and reinvent physics in a way that suits our purposes and hey, faster-than-light spaceships are probably a good idea too so let's build those, and pretty soon you've completely forgotten about the car.

Lisp: With great power comes great responsibility.

I am not trying to extol the virtues of C. I find C a low bar to improve upon, and I'd prefer Common Lisp over it in many cases.

What I am talking about is having to rely on people to do the "right" things when your toolset could be enforcing many of those things. We've empirically shown time and time again that people are poor at consistently avoiding pitfalls. This is especially true as the size and complexity of a project grows.