Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations.<p>Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue.<p>For the former however, I don't know why I need to use different IDEs for different languages, or even different IDEs for different transforms to the same codebase in the same language (again, for the automated bits).<p>It would be so much better for the world if there was some common protocol between user environment and code transformer. That way I could buy some of JetBrains awesome plugins and have my trusty Vim or Emacs environments use them. I could just keep using IntelliJ with MS' plugins for C# (and resharper of course). And so on.<p>For stuff that really needs a special UI, we are in the age of the web browser. Provide a localhost server in your tool and make the reports etc live in a browser window, big GUI IDEs can provide a webkit that can link back to their own editors, but text editor users could still get the useful output.<p>This "everyone does their own thing" without even pretending interoperability is getting old. We've been doing this coding thing for a little while now - we should be better at tooling that plays nice.
tl;dr: Idea 1 is Vim (or any other programming editor). Idea 2 makes no sense, projects have too many symbols for them to be meaningfully encoded in rememberable icons, plus I don't really see how it would condense information. Idea 3 is LabVIEW. Idea 4 is Visual Studio's code map.<p>These ideas are all basically the first thing anyone comes up with when dreaming up a new IDE.<p>The big problem of IDEs is that they're a lot of work to make and polish very well. Most developer environments are either in a terminal, to get rid of the hard UI stuff, are an editor with good scriptability, to get rid of the hard IDE stuff, or are backed by huge slow moving corporations.<p>The one really big innovation that is going to blow life into innovative IDE development is scriptable GUI, aka Javascript+HTML. LightTable isn't the first and isn't going to be the last of awesome new IDE environments for which implementing ideas like this is going to be a piece of cake.<p>So hold on to your hats, we're definitely going there.
I think for right now the main idea in the area of IDE features is to have an "open compiler" so that there is programmatic access to the abstract syntax tree of your programming languages (aka, "compiler as a service").<p>This has been a neat-o feature which slowly became nice-to-have, but it is fast becoming a requirement. For example, the JetBrains products (Idea, Resharper, etc.), and also what Google is doing with clang to help them manage their large C/C++ codebase.<p>We already compile/interpret our languages. So we need to open up that "machine understanding" to programmatic access, which IDE's and other tools can then use to do all kinds of nice things.
With regards to the idea that just the current function should be on screen: At one point I saw a reference to a study (though of course I cannot now dig up the link!) that suggested an inverse correlation between the amount of code visible on screen and the number of bugs written by programmers, with the conclusion that programmers should buy big screens, use slightly smaller fonts, and avoid using too much whitespace. It is exactly when you are thinking <i>only</i> about the few lines of code you're writing, and not about the context in which those lines are going to run, that you're most likely to introduce a bug.<p>In an ideal project, of course, your code be so beautiful--so loosely coupled, so free of side effects--that you could in fact focus on a function in perfect isolation. But few of us are lucky enough to live in such a world.
I started implementing a few of these (and lots of others) ideas, and the issue isn't coming up with what to do, it's doing it intelligently. I have a small side project where I'm playing with AST rendering and the details are usually where you get tripped up.
For #1, I think the Mylyn plugin for Eclipse does something vaguely similar:<p>"Task context management in Mylyn is based on the idea that your interaction with a system can be transformed into a degree-of-interest model, where each element in the system is weighted according to its relevance to the task at hand. This degree-of-interest weighting forms the context of all the elements relevant to the task. The task context can then be used to focus the UI by highlighting the most important elements, filtering the unimportant ones, and allowing you to perform operations on elements of interest "<p>I use IntelliJ (or pycharm) myself but some people swear by Mylyn. Not having used Eclipse myself, the screenshot does't really tell much: <a href="http://www.eclipse.org/mylyn/images/mylyn-3.1-screenshot.png" rel="nofollow">http://www.eclipse.org/mylyn/images/mylyn-3.1-screenshot.png</a>
Here's an idea: the world doesn't need more ideas, just more people implementing, so throwing out ideas as if they're original and have innate value is unhelpful.
For the nth time, I encourage people to look at flow-based DSP programming tools like Reaktor and Flowstone (or its earlier incarnation, Synthmaker) where many of these ideas have already been successfully implemented. For the life of me, I can't understand why IDEs don't come with flowchart generation/editing built in by default.
Neat stuff. I'm fascinated by the potential in this field, and working on implementing some ideas too. You see some of my efforts at <a href="https://github.com/shurcooL/Conception#demonstration" rel="nofollow">https://github.com/shurcooL/Conception#demonstration</a>, if you haven't already.
My IDEa: HTML parsing & formatting within code comments:
<a href="https://groups.google.com/forum/#!topic/ace-internals/pTcFXPyhkLA" rel="nofollow">https://groups.google.com/forum/#!topic/ace-internals/pTcFXP...</a>
I think it would be interesting to see some design mockups of these concepts, which would make it more clear to the people behind prominent IDE's what they would look like ideally.
Oh! You just noticed that IDEs suck? Where have you been living, under a rock?<p>Computer programmers are one of the most dismal professionals on that planet. How many so called programmers/coders can even write a simple parser or a compiler? Less than one percent I suspect. I should know because I am one of them.
After dabbling away with Aho and Ullman somewhere in the 80s or 90s I haven't approached the subject since.<p>Ever since Smalltalk came out it has been downhill all the way, and it is only now a lot of the current IDEs have caught up with it and in the last few years have begun to extend the concept.<p>I believe that:<p>1. Learning to understand and write parsers and interpreters should be one of the first things taught in computer science even before the whole gamut of data structures and algorithms have been studied.<p>2. Being able to develop IDEs should part of every computer science course. They may even be developed to help illustrate the data structures and algorithms mentioned above.
Unlike most professions computer scientists are the ones most capable of building the tools for creating, analyzing and illustrating their work, so why are they the ones that as far as we can tell use the shittiest tools available to most professions? Honestly I blame Sun and IBM for this. The moment Java came out everything went down hill. Then the web came, then 'scripting' , then everybody decided that they could and should 'build' everything using Notepad, VIM or Textmate.<p>3. The tools are there, Smalltalk guys have been using and developing their own tools for ages, only the targetted graphical environments have been split up and the OS owners, Microsoft in particular keeps blowing hot and cold as to which one system developers should target. IDE and graphical tools development is so interactive that the idea of using traditional compiled languages to develop them is simply absurd unless you use very fast compilers and computers. It is time they went 3D as well may be using some Blender, Unity3D or some other gaming toolkit to bring them up to date. 2D text and graphics are boring.<p>4. The bottom line is IDEs should be something developers ought to create or collaborate to create themselves. The big corporations should stay out of that, ie the decisions shouldn't be commercial decisions. It seems that a sad immaturity of computer programming as a profession has led to development tools being dictated by clueless profit seeking corporate bosses. They should be the decisions of developers guilds which should not be linked with corporate interests of any kind. You know what you want, just do it yourselves.<p>5. What else? Yeah, get your parsing skills together, and don't develop it in Javascript unless you plan to develop your own version of Typescript or Dart later on when subtle bugs begin to creep into your cherished IDE.<p>PS. Sorry for the trolling at the top. I just couldn't help myself.