> we shouldn't attempt major changes that aren't backwards compatible?
I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting.
As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.
I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting.
As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.