Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code.
Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful.
Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.
That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers".
>People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases
I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.
> Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.
It's not a cultural bias. It's a critical difference in the language designs.
In python, monkeypatching is scoped to a module.
In Ruby, monkeypatching is global to the execution environment.
So in Python, you can look at the source code for a module in isolation and deterministically reason about what it does.
In Ruby, you can't. Because you can't know what the execution environment will be.
IMO, it's the main reason why Ruby projects become harder to manage as they grow. Somewhere, someone is monkeypatching, and reasoning about the code becomes harder and less local. I spent 2 years with Ruby and will never use it again if I can help it.
Monkey patching can still make horrendously unreadable python code. I agree that it's better that its scope is localized, but I still think that it's more important that monkey patching is used sparingly, and that requires a cultural bias against it.
I like to think of it as the difference between magical and mechanical.
Imagine you need to know what time it is, and you're offered two options to find out.
One is to recite an incantation, a magic word, and the current time will appear in the air in front of you.
The other option you are offered is a clock or a watch. With this option, anytime you need to know the time you can simply look at the clock face and simply and immediately know, but when peeling back the surface, you can see an intricate set of gears all working together to keep track of the time.
On the surface, both of these options are equally easy to use and useful to find out the current time, but the clock will be far more fixable and extensible.
IMO we should strive to make our frameworks "mechanical" like the clock rather than magical.
Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code.
Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful.
Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.
That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers".
>People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases
I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.