I see programming in four parts. The writing part, the reading part, the recording part, and the compiling and running part. For most of the languages currently available, the first three parts are the same part. What we write is what we read, which is what being recorded on storage, which is what commonly referred to as programming language. And for some interpreted languages, even the last part overlaps with the former three.
What is wrong with that?
The four parts of programming have different properties and require different optimization to reach best efficiency.
When a programmer writes program, he is tring to express what he had in mind. People often thinks much faster than one can express, so the language for writing should be as quick as possible. For example, when writing, one desire short variable names and hate capitals and special symbols. Having to spend a few seconds in thinking of how to type the words correctly is very disruptive to one's thoughts. Another most inhibitive feature for writing which exist in many languages are parenthesis. Parentheses are always in pairs, and our mind hate matching pairs. To match one pair is OK, but to match the 7th pair is horrible. There is a famous rule, human mind can only track five plus or minus two items at any time. At 7th pair of parenthesis, one is bound to forget which block he/she is closing and have to throw away some of the current items in the mind to pick up what he/she has to match, which is a break of thought. I suspect many programers have the same habit of putting closing parenthesis down right after he writes an opening parenthesis. It is much better than later to match but is a slow and disruptive process since one has to write the closing parenthesis and then go back one line or character and start writing again.
When we speak, we use "he", "she", and especially "it" a lot and use incomplete sentences often. So to write efficiently, one expects the parsers to maximally understand context. This not necessary true for reading. It requires a lot of intelligence for computer to understand context, but some effort on this are very welcome. Some examples are type inferrence, scoped variable.
Reading is the comprehesion part. I guess the most efficient form for reading is a good visulization. However, as a good visulization often is difficult for a human mind, it is too much to ask a computer to do it. A bad visulization is definetly worse than none. But for the least, a good form of program for reading should be well structurized (which means consistent and good indentation). If the platform allows, it should utilize the GUI. For example, I would enjoy seeing different blocks have different shades of background, consistent syntax hilighting, and extensive use of symbols. For the last one, I am thinking of the expressiveness of maths. I agree that maths are not always easy to comprehend for an untrained mind, but there is no reason programming has to compensate for non-programmers.
On the contrary to the writing part, the form for reading should try to reduce context dependence, as very often one reads a program non-linearly and figuring out the right context is often quite cumbersom. Some features used in languages to reduce context dependence are Hungarian Notation, Perl's '$', '@', '%', and '&' symbols.
Since reading is still a human mind thing, the five plus or minus two rule still apply. So it helps if only a few levels of program codes are being displayed at any moment while other levels are displayed as a symbol or icon or completely hidden. Many modern ide have the ability to expand or shrink recognised blocks into its firstline, which is very nice.
Recording is not the perfect word for what I am referring. What I am tring to describe is the internal representation of a program as well as its on disk format. As long as one realize it is not necessary to maintain the same form of a program for writing and reading, it just come natural that the recording form of the program can be different than either what is written and what is to be read.
An efficient way of recording form does not necessarily need to be readable (can be in binary or semi-binary), or space efficient (either disk space or memory are getting cheaper by the minute), however, it should maintain as many infomation as possible to ease the manipulation and later retrieval. An good recording form should maximize program reusability.
In my current opinion, the most efficient way to represent a program internally and on disk is to use functional design. I could list all the benefits or advantages to functional design, but I choose to add it later. There are plenty of opinions on the net on it.
This is the final and ultimate stage of programming, the ultimate goal is efficient machine intructions with as few bugs as possible.
Automatic garbage collection goes here for the goal of minimizing bugs.
Optimization goes here for the goal of efficient code.
An effective debug mode, as well as an effective profiling mode goes here for helping the programmer manually achieving either goals.