On 1/9/2016 3:02 AM, Russel Winder via Digitalmars-d wrote:
[...] And also generally bad architecting of I/O in applications.
These problems have persisted since the genesis of iostreams. The problems do not exist in the way other modern languages do I/O. Iostreams was a great idea in 1985, but 30 years of experience has shown there are better ways.
There is a difference always between what you can do and what you should do. The language should not be fascist in stopping all things not deemed the one true way by the language designers. To do so stops serendipitous evolution.
On the other hand, consider the C preprocessor. It has well known problems. But this never seems to discourage the most execrable edifices built on top of it. Their designers inevitably regard them as shining examples of their creativity. And maybe they are. But do they belong in professional code? No. But the only way to stop them is to not have a preprocessor in the language. (Of course, you can always use m4 as a front end to any language, but thankfully nobody seems to do that.)
I believe there is a notion of "best practices", that some practices are simply better than others. A good language design makes it easy to follow best practices, and hard to follow known inferior ones. D is meant for professional use, and people who want professional code tend to want some mechanical assurance that best practices are followed (consider the increasing smorgasbord of third party tools designed to ferret out bad practices in C/C++ code).
There is plenty of innovation in programming language practice, I don't think it is stifled.
