Three silver bullets that have been forgotten

I recently thought about what my ideal programming language would be. Just for fun, I googled "ideal programming language" and read the first five hits. Man, was I disappointed! It seems that nobody who has any imagination has ever written about the topic in a way that brings them high up in the Google results. Basically all five authors described their ideal programming language simply by listing features from existing languages!
Here's a ruff list of requirements for the ideal programming language that I came up with:

• has only a few built-in features so that it con be customized for different domains
• uses the same core syntax as a basis for all kinds of third-party supplied DSLs 
• allows much better tool-supported factoring than any current tool for any current language provides
• allows IDEs to show the code in different views, rearranging methods, even graphical and tabular representations (see also light table and subtext)
• can scale from being a scripting language for a third-party module up to writing your own DSLs and modules to be used by others
• allows literate programming, support for verification, and also tests. IDEs should understand the verification annotations (such as preconditions, postconditions, invariants) to point out possible errors and better support refactoring.
• is explicit. I think that languages with implicit type conversion, implicit defaults, and other automagical things scale badly, because in a larger program, you'll have a mix of implicit and overwritten stuff and need to keep track of when the defaults are used or what else happens "behind the scences". integrating the language with the IDE means that the defaults can be put into new programs and modules by the IDE thus keeping the advantage of quickly starting a project but also gaining the advantage of staying agile by always seeing where everything comes from and being able to change it just right there.

Interestingly, tool support for different views and verification and flexibility to create DSLs all require that the core language has as few features as possible!

Even more interestingly, as I read Fred Brooks famous essay on "no silver bullet" again, I was easily convinced that new programming languages don't actually make that big of a difference in programmer productivity. Basically, there's been nothing really new since Smalltalk and ML! On the other hand, Brooks convincingly argues that the fastest way to write a software is to not write it at all, but to buy it! Or more generally, reuse existing modules! 

While Brook's essay lists a lot of other technologies and methods from which he doesn't expect any significant improvements in productivity, he also mentions three things which actually do have potential in his mind. In short:

1. Buy, don't build.
2. Develop incrementally from prototypes.
3. Find and develop great designers.

Interesting that he mentions incremental development back then in 1986. Agile ain't that new after all! And defining the minimal product hasn't become easier either. It's still one of the essential complexities of software engineering.

Edit: Added "explicitness" in response to Max' comment.