Isn't it possible for software development IDE's to visually present information in a much more efficient way?

Maybe, but probably not as much more efficient than you think.  I'll explain by responding to each of your ideas. Graphics/Phudocode to replace boiler-plate code You could do something like this, though you'd have to be careful not to introduce too many graphics or you'd change the code into hieroglyphics.  There would need to be an unobtrusive transition between the summarized "reading" and more verbose "edit" modes though. It's also worth noting that features like collapsing function bodies, which serve in some sense to give a more concise description of code, are not widely used. The IDE could hide redundant/uninformative bits of code (e.g. types) It could indeed!  Though again there would have to be an unobtrusive way or transitioning between "read" and "edit" modes, and I don't really think this information slows down reading much. Error handling code could be graphically moved off to the side This is a good idea.  I like this idea a lot. Comments could look like annotations I actually don't like the look of annotations much, and really don't mind the way comments look in source code.  But this idea is certainly doable, and I'm sure some people would use the feature (I think I might have even seen it somewhere). Types could be icons They could, but that wouldn't be a good thing.  More pictures does not mean better UI.  See: http://uxmyths.com/post/715009009/myth-icons-enhance-usability.  The same problem described there applies here. Allow variables to have two names, one verbose and one terse This means you have to keep track of twice as many variable names when reading, a far bigger problem than sometimes reading overly long names or slightly unclear ones.  However, some programming styles dictate that you should use a short name for your variables but always have a comment describing them in more detail at their declaration, which is kind of like what you're getting at. The IDE should handle verbose parts of a programming language My experience is that when people complain about how verbose a programming language is, they're generally talking more about writing than reading.  It really doesn't matter how short variable names are or if you didn't have to declare them beforehand or if there is some concise syntax for various looping structures when you're reading.  Your mind has to translate the concise syntax into the verbose stuff anyway. Edited to reflect Question's edits.

Thanks to Sammy and Ryhan for providing some of the HCI perspective. I'll pipe in with a bit of the software engineering side. The short answer is: yes, people are pulling out their hair, but IDE developers love ignoring research and principles. There is some progress though. One notable exception is Code Bubbles, which in under 3 years have gone from research prototype to inclusion in Visual Studio. You give a lot of ideas about IDE design that are really questions of language design or require solving tough static analysis problems.  But overall, I think you really want a structured editor. Language design It's a flaw of Java that error-handling is mixed with the core control flow. You can try to separate it out into another column, but there's only so much space on the screen, and what happens when you want to do the same thing for logging? Furthermore, just recognizing what is error-handling is hard (see below), as not all error-handling is done by exceptions, and exceptions have other uses, such as in backtracking search algorithms. Instead, the solution is to isolate such "cross-cutting concerns." This is exactly what "aspect-oriented programming" aims to do. There's a fairly popular aspect-oriented extension to Java called AspectJ. The verbose name/terse name split would also be very straightforward to do within a programming language -- except that most imperative programming languages confuse variables with mutable cells. In pure functional code, all variables are constant, so creating a shorter alias is no problem -- you just do an assignment. In languages such as OCaml do make this distinction, it's just as easy to alias a mutable variable, e.g let reallyLongName = ref 1 in let shortNm = reallyLongName in shortNm := !shortNm + 1 I believe C++ references also address this problem. Static analysis problems Recognizing boilerplate and converting it to pseudocode is a great idea, and it sounds appoximately the same thing as http://dl.acm.org/citation.cfm?id=1869459.1869521&CFID=209077638&CFTOKEN=50331142. The hard part is actually recognizing the boilerplate. Consider these three ways of iterating through an array in Java. for(int i = 0; i < a.length; i++) { ... } for(int i = getStart(i, a); inBounds(i,a); i = getNext(i,a); { ... } .... (definitions of getStart, inBounds, getNext) while(true) { if(i % 2) == 0) { i >>= 1; i *= 2; } if( i == a.length) break; boolean b = true; if(i > a.length) b = false; if(!b) break; ... i++; } Meanwhile, here's some boilerplate Haskell code I wrote last night for converting one way of representing Java programs into another, from a way which represents them "one level at a time" to a way that stores them as a monolithic tree. (I've  changed this a bit to hide some of the fancy type-system stuff.) instance Untrans Stmt where untrans (StatementBlock x) = J.StmtBlock x untrans (IfThenStatement x y) = J.IfThen x y ... These of course, can be solved. Properly handling the array examples is well within the reach of a moderately-simple abstract interpreter, and I can easily design an analysis capable of discovering their equivalence, but someone who has only taken undergrad compilers couldn't, and a fourth example would likely break the analysis. Whatever I do for the array-iteration, it won't do a thing to help with the second example. It's an API-mapping problem, and I've read nothing beyond abstracts about how to handle them. Different code requires different techniques to handle -- if you can develop one algorithm capable of recognizing all boilerplate, you'll be famous. In fact, the reason I plan to read more about registration-based language abstraction is less because I care about removing boilerplate (though I do), but because I want to know how they address this problem. (It's almost certainly not by recognizing all boilerplate.) But, more generally, this is why we care about language verbosity. We can either develop more powerful languages that let programmers express more and more interesting program structures, or we can develop more powerful static analyses, visualizations, and transformations that let tools discover, display, and manipulate the structure in unstructured code. The latter is a far harder problem. Structured editors I think you've touched on one of the core limitations of most IDEs -- programs are stored as plain-text. As a result, just finding references to a variable name requires a fair bit of infrastructure, and there's no place to put alternate variable names or comments-an-annotations in a text file. A lot of this would come easily if we actually stored and manipulated the program as a syntax tree. This is what structured editors do. They've been around for a while, but have only recently picked up steam, with the first commercial structured editor being produced by Intentional Software. By the way, the visual display isn't the only problem with placing comments on. Refactoring tools have trouble too -- when you move some code, do you also move the nearby comments? Doing this properly really calls for NLP.