Proposal: Database Engine for D

[Walter Bright via Digitalmars-d]

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.