I've been programming for over 2 decades, but maybe there already exists a programming language that does these things, but here we go.
A language where there isn't multiple ways to do the same thing.
The biggest distraction in software engineering is that there is not a clear cut way to do something, instead there are many ways and it is ambiguous as to what is the best way, in fact the best way can change under different conditions. And at times finding the right way can take trial and error.
A language that doesn't let you optimize.
One of the reasons we end up writing code in multiple ways is in order to optimize it, but this can make code a lot less readable, it can end up consuming more memory and it means you need to economize memory (what is the best use of memory to improve critical performance areas). It can also lead to bugs, and as they say "premature optimization is the root of all evil".
But lets take for example a collection of objects and we want to apply an operation to objects that meet a criteria. Unoptimized, we would need to iterate through every object checking the object matched our criteria and apply our operation, but if we are clever we can optimize by storing in each object a boolean that says an object has passed our criteria before and not need to check each time the operation is applied, and if we have memory we could store the objects that match our criteria in a separate collection so that we can simply iterate without having to check objects match.
But these clever ideas consume time in figuring out, since you need to test each one to see how much they improve performance and how much extra memory is consumed, if they are safe and not buggy, or if they are even worth doing at all.
Automated optimization at compile time through unit tests or at run time.
So ideally the language doesn't let you write optimized code, but rather the compiler or VM automatically detects how code uses data and creates optimizations automatically. It could also take unit tests which represent the kind of data and operations the program uses and based on those unit tests create optimization strategies.
Systematically as well it could do load balancing, for example it can create extra object collections to cache results, and if memory is running low it can destroy these caches sacrificing performance but reducing the memory footprint. In a larger of an operating system, it can ask the program to lower its memory footprint for another higher priority program, similar in a way to virtual memory will load and unload blocks of data as they are needed.
Built-in Database
In some respects what we want is a bulit-in database. Where you have a collection of objects and can query into the objects and apply operations on them.
Simply adding a database though wouldn't be enough since the database doesn't have much knowledge of how it will be used, where as an interpreter/compiler will have this knowledge. So in reality what we are talking about is really integrating/bridging knowledge from an VM or compiler to a database, such that the database could optimize the code that uses it.
One interesting fact is that web browsers treat their document objects as existing in a database, and a CSS file essential does queries in the database and applies properties to objects that match it's query. Having learned that I had considered what it would be like to have such a file that rather than apply style properties could also do other operations written in javascript such as automatically adding/creating event handlers.
Early Validations!
The biggest cause of bugs in software is either lack of validation or late/lazy validations.
An example of the lack of validation is of course the buffer overflow. Which is or was a common way people could hack programs and/or computers.
Late validations on the other hand usually put a program into a bad state and engineers can at times not know how to deal with the state and may not cleanly restore the system to a good state. This is not always entirely bad, a lot of software should never allow the user to put the system in a bad state, and a bad state in those programs would represent a bug in the code or a bug in the data controlled by the software developers, rather than representing bad user input or user data. Video games are an example of that kind of software, and they usually use a lot of asserts on state which halt the program so an engineer can look at it but they never ideally deal with bad states, unlike for example a paint program which the user can tell it to load a corrupt file in which rather than have an assertion failure the program must gracefully handle bad data.
Strong Typed Objects
One way to solve late validations is to use strong typed objects. For example having a general Date object and having PastDate and FutureDate objects guarantees that a date is relatively in the past or future of another Date object of your operation. Another example would be to have an Integer object where you specify the min/max of that integer, when the integer is loaded from a file or user enters it into a widget, the value is immediately validated rather than validated later on or using the data to modify a buffer later on (potentially causing a buffer overflow).
Doing this allows engineers to see how late they are validating, it can also produce warnings to engineers that they are not handling a validation failure, or they are altering state before data is fully validated (meaning they will need to revert changes if validation fails).
State Control
Alternatively state changes could just be accumulated and applied at the end of an operation or applied by a 'flush' call, so if it fails the changes are never applied or only applied to what is safe and validated and optionally you can capture a failure and present an error to a user and/or in a log, or even more generally the whole state can be dumped in order to give to a developer who could retry the operation and see why it failed in detail.
Visual Programming (Maybe)
An interesting thing I've seen is the rise of visual programming "languages". In many respects it is basically like creating a flow chart that actually is the program itself. One of the best examples you can see with Unreal Engine in this video.
Well, that is it for now, are there anythings you all are looking for in a future programming language?
For me programmer is not someone who writes code, but someone who can inspect every and each aspect of complicated system and decide on low level how new implementation should be integrated with existing one.
Business perspective is and always should be much wider. It will be not a surprised for me if in the new future there will be more visual programming. Code is not necessary for development but developers will always need a way to describe requirements in very detail way.
That's why I prefer 'software engineer' or 'engineer' over 'programmer'. They are used interchangeably but for example, you can program a VCR to record at a specific time, which indicates you know how to program it but doesn't indicate a person knows how a VCR works, can maintain, repair, or upgrade one.