Then I'm not sure if "powerful" is necessarily what I look for in a language.
I have three priorities when programming:
1. Correct
2. Understandable
3. Fast
Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years.
Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above.
Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction.
(Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.)
Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson.
For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count.
Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.
I have three priorities when programming:
Priority 1 is non-negotiable (code should be correct, or the rest is moot). Priority 2 is negotiable in situations where priority 3 isn't, however I've had this happen perhaps a handful of times in the last 25 years.Being able to produce code quickly is nice, but unimportant if the code isn't likely to be correct, understandable or fast. Productivity in production code is measured in how you achieve the above.
Likewise it is nice to have code that is easy to refactor and doesn't require duplication, but duplication is more permissible than the dogmatic avoidance of duplication when it is detrimental to understanding or speed. It can also lead to unnecessarily bothersome abstraction or spending too much time creating abstraction where the domain doesn't naturally lend itself to abstraction.
(Note that points 2 and 1 tend to dictate that duplication should be avoided: it isn't about the typing saved, it is about correctness.)
Priority 3 could be elaborated as "quick response times and avoidance of unnecessary resource use". Any idiot can write code that does X. A craftsperson writes code that does X well. A valuable craftsperson can do X well and quickly. Be a craftsperson.
For rapid prototyping you can throw the rules slightly overboard, but when you write production code things count.
Abstractions and language mechanisms that can give you static guarantees are good when they help you achieve the above. They are counter-productive when they conflict with any of the above. It is easy to become counter-productive when you try to satisfy some dogma.