Modern IDEs are not text editors. They are heavily augmented with syntax highlighting, completion, code-folding, refactoring, squiggly red lines. This requires an IDE understanding your language and is effectively parsing the tokens as you type. I would suggest that a lot of the features we talk about have arrived already, it is just not explicit, and is tremendously complex to implement, simply because programmers are old die-hards and refuse to try different ideas.
Then there is the issue of reasoning about working systems. The job of the IDE ends when a software is built. If you encounter a bug though, having a runtime that has the smarts so that you can go in an poke around allow and even encourage experimentation, and improves comprehension.
Finally, there's the issue of code organization. A well artichected piece of software is tidy, because everything is in the right place. While a language-aware IDE can make sure you put the words in the right order, it has no concept of the architecture. A higher level DSL that is supported by the development environment directly might help. If we can somehow raise the abstraction level of the IDE, certain classes of programming problems could be as easy as filling in a form.
> Modern IDEs are not text editors. They are heavily augmented with syntax highlighting, completion, code-folding, refactoring, squiggly red lines.
How do any of those features make something 'not a text editor'? I'm pretty sure vim is still a text editor, and my vim does all of those things, with the possible exception of refactoring (and I'm not sure I want a program doing my refactoring in the first place).
A plane with auto-pilot may be still a plane, but the pilot's ability has been heavily augmented.
Incidentally, I spoke to a guy who had been developing Java on EMACs for 12 years. He tried Eclipse a month ago and was won over. Large languages - rightly or wrongly, like Java, benefit from having tight tool integration.
Then there is the issue of reasoning about working systems. The job of the IDE ends when a software is built. If you encounter a bug though, having a runtime that has the smarts so that you can go in an poke around allow and even encourage experimentation, and improves comprehension.
Finally, there's the issue of code organization. A well artichected piece of software is tidy, because everything is in the right place. While a language-aware IDE can make sure you put the words in the right order, it has no concept of the architecture. A higher level DSL that is supported by the development environment directly might help. If we can somehow raise the abstraction level of the IDE, certain classes of programming problems could be as easy as filling in a form.