IMO it is always better if the compiler can tell your intention than the documentation (which no one reads if not necessary)
j
Joe
03/15/2018, 4:31 PM
Yes, 100% agree
r
Ruckus
03/15/2018, 4:32 PM
This is probably drifting a bit #random, but I'm still of the opinion that if you can't trust your team (or at the very least the process your team has in place), that is the issue that needs to be addressed, and no amount of language features or compiler kung-fu will save you. There's always a way to get around any guarantees the language or compiler give, so you need to trust your team to not.
If you can't trust your team to read the documentation or have some sort of code review process in place, you should address that concern, and not expect the compiler to fix it for you.
r
robstoll
03/15/2018, 4:35 PM
maybe #random, but since it is in an own thread now, I guess it's fine. For me your arguments are kind of the sort of, why using types at all? Use a dynamic language and as long as you trust your team everything works out fine.
that's not wrong per se but will more often fail due to knowledge and not because someone is sneaky or something
that's at least my experience
r
Ruckus
03/15/2018, 4:38 PM
I think you're missing my point then. Such features are definitely helpful, but they can be worked around. You can find plenty of ways to get around the type system for example. You have to trust your team not to. While these features are great, at some point you have to trust your team. If you can't, the issue isn't the language.
You should expect the language and compiler to help you and your team, not protect you from them.
r
robstoll
03/15/2018, 4:42 PM
maybe we are talking about the same thing then. Of course you need to trust your team (otherwise it sucks working together :D) but you should also avoid pitfalls where possible. And if the language helps you avoiding them, then even better
r
Ruckus
03/15/2018, 4:45 PM
I can agree with that, but at some point you have to draw the line when to stop adding "features" to the language to account for bad coding (due to diminishing returns). This is probably just a pedantic argument of you and I wanting that line in a slightly different place 🙂
If such a feature was possible, without increasing the complexity of the language and compiler too much, and without sacrificing other language features or possibilities for improvement, I'd say go for it. but the language design can't account for every edge case, so the line needs to be drawn somewhere.