While thinking about software-engineering in general I came across the question why we don't see any improvements in the way we write/document code.

Think about it: There has not been a revolutionary improvement since we've moved from punch cards to text editing. The last improvement I've seen is syntax highlighting and context sensitive help (e.g. Intellisense or ctags). Not something I would call revolutionary.

That makes me wonder: Why is it so?

I'll start with something I miss badly:

  • Lots of my code deals with geometry. For documentation describing geometric relationships always ends up in a big heap of hard to read mathematical stuff (due to the lack of proper equation type-setting in ASCII). However, if I could embed a little drawing or scribble into the code everything would be much easier, neater and better to be understood.

What can you think up that would make your coding/text editing/documention tasks easier?

+1  A: 

A brain-to-computer translator. Typing is the real bottleneck. It really just needs to derive the algorithms I think up and convert that to machine code.

I would say a lot of the newer languages are pretty great at quickly creating algorithms. The improvements aren't so much revolutionary now as they are evolutionary.

+1, why do we still use keyboards ? The input devices in general are so old...
The keyboard is ~so~ not the bottleneck. The bottleneck is truly thinking out solutions and a brain-to-machine code translator isn't going to alleviate that.
agreed, just imagine you were programming using a speech to text engine, you could talk as fast as you want to describe your formalize your program, you'll see very quickly that you will still talk rather slowly, because it's the thinking that takes times, too.Of course, just detailing requirements -as opposed to detailing program code- in order to come up with a program would be a different matter.
"best thinking done in shower"+"brain interface" -> "electric-shock" and "comments regarding the awesome lemon soap"
Aiden Bell
The whole point is why do we need to translate our thoughts to text? A lot of the "thinking" we do is "translation", converting our thoughts to fit whatever language the machine accepts. I say, the machine should just accept thoughts.
We clearly need DWIM, but that's a PL issue, not an environment issue...
Brian Postow
If typing is your bottleneck, I'd like to see some of that code...
I have worked with someone for whom the keyboard was the bottleneck. She'd type along at about 120 WPM or so, spraying code like a fire-hose. Unfortunately, a lot of what she wrote didn't work right on the first try, so she also did a lot of re-writing.
Mark Bessey
+2  A: 

I would reference a drawing as a reference in the code documentation. I see no reason why you can't have footnotes in code.

+2  A: 

Have you used Doxygen or similar for documenting your code? You can add links to images, and other file types (often stored in same directory as source code) that will get sucked into the generated documentation. I realize that this is one step removed from seeing the detail directly in you favorite editor but it definitely improves how we document our code.

Stephen Doyle
+3  A: 

I think this is where Doxygen and other documentation systems help. If we can embed small, discrete comments that link to other information such as:

/* help: fooimg.png */

And then have an external documentation system do that, then great.

Even better would be allowing our text-editor to treat those things as hyperlinks to external documentation.

Aiden Bell
sounds good-not sure if there's support for embedded images in doxygen yet, but if there isn't, you might want to post a feature request:
Ill see if it is there already. If not, might implement it, would be useful.
Aiden Bell
+3  A: 

DrScheme let's you do these things. Here's the things you can insert from the PLT website:

3.1.6 Insert

  • Insert Comment Box : Inserts a box that is ignored by DrScheme; use it to write comments for people who read your program.
  • Insert Image... : Opens a find-file dialog for selecting an image file in GIF, BMP, XBM, XPM, PNG, or JPG format. The image is treated as a value.
  • Insert Fraction... : Opens a dialog for a mixed-notation fraction, and inserts the given fraction into the current editor.
  • Insert Large Letters... : Opens a dialog for a line of text, and inserts a large version of the text (using semicolons and spaces).
  • Insert λ : Inserts the symbol λ (as a Unicode character) into the program. The λ symbol is normally bound the same as lambda.
  • Insert Java Comment Box : Inserts a box that is ignored by DrScheme. Unlike the Insert Comment Box menu item, this is designed for the ProfessorJ language levels. See ProfessorJ.
  • Insert Java Interactions Box : Inserts a box that will allows Java expressions and statements within Scheme programs. The result of the box is a Scheme value corresponding to the result(s) of the Java expressions. At this time, Scheme values cannot enter the box. The box will accept one Java statement or expression per line.
  • Insert XML Box : Inserts an XML; see XML Boxes and Scheme Boxes for more information.
  • Insert Scheme Box : Inserts a box to contain Scheme code, typically used inside an XML box; see XML Boxes and Scheme Boxes.
  • Insert Scheme Splice Box : Inserts a box to contain Scheme code, typically used inside an XML box; see also XML Boxes and Scheme Boxes.
  • Insert Pict Box : Creates a box for generating a Slideshow picture. Inside the pict box, insert and arrange Scheme boxes that produce picture values.

You also insert your unit tests with the code that you're testing. Pretty neat stuff.

+1 nice ideas :)
Aiden Bell
+8  A: 

I disagree. We do have changes, small, but changes.

How common is the "for each" construct? Compare it to 20 years ago. How about the Domain Specific Languages movement? The idea that we should code in layers. How about Behavior Driven Development? Coding by complying to a specification... which writes a nice document as output when all runs fine. How about the standarization of regular expressions? PCRE.

Documentation is a two way dialog. Both as code being more understandable and people learning this special language. You wouldn't say that German needs documentation if you know German. I know natural languages are very far away from computer languages, but there's a movement to make code more expressive. It's not about the new tools, it's about how we are coding.

People were coding in layers before I was quite off punch cards. There's been some good stuff added over the years, but nothing spectacular. As for coding to specification, either the spec is a programming language of its own, or turning it into executable code is a creative act. More expressive programming languages are of limited use, or we'd still be hacking Hypertalk. If you're going to learn to program well, learning an artificial and highly precise language is one of the least of your problems.
David Thornley
+13  A: 

There has not been a revolutionary improvement since we've moved from punch cards to text editing

Never used a line editor, have you?

But seriously, text (especially in the representations chosen for modern languages) is

  1. easily processed
  2. fairly easy to specify
  3. information dense
  4. precise

Anything that comes along to replace it has to be a net win across all four of those properties. Not easy.

I have used a line-editor, and I still do when I write code on my old IBM XT (which I do from time to time because it's so much fun). :-)
Nils Pipenbrinck
@Nils: Now I feel like a real pillock. Thanks. I have only written a few thousand lines of code in line editors, and haven't touched one in years, but I suspect that for those who lived through it the line-to-screen editor transition was big.
I think precision is more of a programming language feature. That being said, think of what will happen at compile time. Lots of different text representations will be represented by the same sequence of machine code.
Drafting software like Google Sketchup produces information that is easily processed precise, easy to specify and info-dense; the breakthrough was making a system that did #2 (and #1 to a certain extent). I'd love to be able to 'shell out' to Sketchup for certain programming tasks.
Alex Feinman
+1: Amen to that brother. Video editing was by far the single biggest jump in productivity in my career. Folks who never had to work without one cannot understand how incredible the difference was. "Graphical/GUI" development tools and environments are abysmal and have been for 40 years, and for just the reasons you list, probably always will be. But they look good and market great, so we get them crammed down our craw all the time. ... :-(
I've used punch cards, line editors, line editors on synchronous terminals, visual editors, and IDEs. I find that when I use an IDE I keep wanting to have vim and makefiles when I do something complicated.
David Thornley
@David Thornley: I'm an emacs and make guy, but there a few IDE features I wish emacs could do better. Mostly related to knowing what the compiler thinks the parsing should be, or what the symbol table looks like, or being able to ask the build system what other files to search for the origin of the troubling symbol in front of me. The existing hacks are good, but they are not great.
@dmckee: Yeah, nothing's perfect. Some IDE features are very nice, and they're far easier to learn than vim/emacs, make, etc., but I still prefer doing serious work with Unix-style tools.
David Thornley
+1  A: 

The ability to make a section of code read-only is something I've wanted

Split it into a separate file and freeze or lock it in your version control software?
what do you mean by that, do you mean disabling write access to certain parts of a source file? If that's true, what's wrong about factoring out that code into a separate file, so that access may be separately configured?
Um... just comment it: // DO NOT EDIT THIS!!!
+4  A: 

Source Code In Database. In a nutshell, source code is parsed and put into a database. You'd then need an integrated IDE to view and edit the code, but at this point, syntax is decoupled from format. YOUR IDE could show you a program in a way that's completely different from someone else's, tuned to the task you're working on. I'd list some specific examples, but that article covers pretty much everything.

I don't see any reason a fundamentally text representation could not be given a flexible presentation style by a smart enough editor. All the more reason for the editor and compiler to share a parser, though... Still, this would be nice.
I think it would come down to there being potentially more than one string of text to represent an underlying syntactic structure. The article mentions something like "show me this code AS IF it were written with nested IF/ELSE instead of SWITCH/CASE". An 'acceptably smart text editor' would be doing the parsing and storing it locally. Storing it in a database minimizes the work.
A neat idea, and a very bad one. Modern IDEs can already give you the same features without losing the flexibility and accessibility of using arbitrary text-processing tools.
Michael Borgwardt
I don't see why you wouldn't be able to store it as text locally, process it, and upload it. You wouldn't be losing any functionality, you'd just be gaining the ability to do a lot more locally. Most importantly, you'd be gaining all the benefits of being able to search/manipulate the database. Imagine being able to mine a giant code base in a way that was aware of the underlying syntax. Seems like a win/win.
I like this idea. In fact I've been thinking of a system like this which integrates test-writing specification and code into a database. Test, specification and implementation is just different "views" of the codebase and a lot of boilerplate code could be autogenerated from specification documents and test cases could be autogenerated, etc... Well, you get the idea.
@MB - Careful, your argument could also be used against version control!! 'Why should I need a subversion client when I can just keep my files in datestamped directories??' ;)
+1  A: 

Programming languages are a specialized form of mathematical notation, since you can express a programming language mathematically. Notation changes slowly, and so we don't get fast progress in our languages. Mostly, we advance when we come up with a new thing to fit into the notation, like using i to refer to the square root of negative one.

There are documentation schemes that allow you to embed things other than text. There was at least one programming scheme, Donald Knuth's Web, that allowed you to have a presentation and an execution version of a program (unfortunately, the base source code, the stuff you'd actually hack, was rather messy).

You could easily have a text editor that could treat comments as HTML, provided of course it could recognize comments as it saw them.

David Thornley
+3  A: 

I think integrated IDEs with semantic highlighting and *semantically-constrained suggestions (a la IDEA or Eclipse) are a huge advancement.

But that happened 8-10 years ago.

Template-based programming feels useful never seems to catch on. Recently I was impressed with a demo of the Meta-programming system, which leverages the interactive nature of the IDE to simplify the task of writing templates and what are (essentially) type-aware macros.

Meta-programming might help you define geometry-based macros that would substitute for a number of lines of code. I could imagine something that let you embed a more-readable 'math language' inside Java, and then parses its contents into something machine-readable.

Alex Feinman
+2  A: 

It sounds like you might be interested in Jonathan Edward's research. See, for example:

Josh Kelley
+2  A: 

The last improvement I've seen is syntax highlighting and context sensitive help

Then you haven't looked much. Modern IDEs can do far, FAR more than that, namely show you the semantic structure of code (e.g. inheritance hierarchies) and even manipulate it (automatic refactoring) or enrich it with external data (such as who last changed a particular line of code).

Michael Borgwardt
+15  A: 

I'm suprised that no one seems to have mentioned Donald Knuth's seminal Literate Programming - write your code as if it were a book or a scientific paper.

+1  A: 

I've been thinking a lot about how to make coding faster and more efficient for the past years, always trying to keep it realistic and doing minimalistic implementations. Those are not revolutionary ideas, but since the original poster talked about the punching card to code typing transition, I thought of talking about other ways of communicating to the computer what we want to program.

My ideas are visual or vocal programming. The motivation behind is that there are only a number of ways a loop can be efficiently programmed, and an aware IDE could make some smart code substitution decisions depending on inputs other than typed lines of code.

Visual programming vs Coding: encapsulate (literally) code into "boxes" which have inputs and outputs, and connect them together across a horizontal timeline. This is a high-level concept that would be intrinsically interesting for multithreading development since you can have multiple lines or threads happening at the same time. Every process can be divided into a "box", no matter how you see it. Sending an e-mail in its most basic form is a box which takes an email as input and outputs a success/fail signal. Since the boxes and the lines are distributed across a timeline, the notion of time and event chronology isn't lost and feedback lines are possible.

Vocal programming vs Coding: The effectiveness of this technique would revolve around the effectiveness of the vocal syntax decided to create code and move the cursor. For example, you can say to the microphone "for variable zero to 10" and the system will automatically generate the following code placing the cursor inside:

for (x=0;x<10;x++){
  // Cursor would be there after after the call

In terms of usability, you would need to be in a relatively silent room to minimize other sounds that might harm the voice recognition so this technology could be used in specialized environments mostly.

This is the result of my extensive programming experience using a wide range of hardware and programming languages. Let me know what you guys think, I'd love having a constructive discussion about that.

Wadih M.
Downvoter, provide more information.
Wadih M.
hmm. ftr I didn't downvote you.I like the first idea, but I think the 2nd idea would not work for me. I avoid text-to-speech stuff like the plague -- for me text-to-speech is like the tablet - it sounds like a cool idea but when you actually try and use it, it kind of introduces more tedium than just typing it..its like those call centers that make you talk to the computer... i'd rather punch the numbers in my phone.
I don't like any of those ideas at-all. Apart from the fact that a vocal system would be annoying for those around me, it would introduce errors into an already complex process. As for boxes-with inputs and outs ... sounds like the kind of program-a-diagram I hope never to use.
Aiden Bell
Fair enough, that's your opinion. I clearly said that the voice programming must be done in specialized environment. It takes 2-3 seconds to pronounce words to generate a loop that fits in 27 characters. (for (int i=0; i<10;i++) { }) so right there you can see potential for effective voice aided programming. Again, that would require a lot of optimization and research.
Wadih M.
I had an affair with visual programming when I was young... though fascinating, one thing I took away was that visual programming is just another DSL, nothing more. Regarding speech, I'd much rather skip it on the way to brain interface... think of the large room with programmer cubicles, where everybody is shouting, like they're... on the Wall Street or something. ;)
I can type much more accurately than my voice can be recognized. I think that makes up for the fact that I can talk faster than type, not to mention that having input come from the keyboard mean's it's not going to get confused with somebody in the next cube discussing a sex-change operation.
David Thornley
Also, while I find the visual programming idea interesting, I'd have to try out some implementations to find out for sure. The idea of modules on something like a Gantt chart has possibilities, but the possibility of spaghetti code scares me.
David Thornley
Your visual programming idea has already been done, at least partly, in Matlab with Simulink. It's powerful for a certain subset of problems but I'd never want to try to make a CRUD app with it.
Bryan Anderson
Thanks for your input guys.
Wadih M.

The basic flaw in the whole process is the concept of putting source code into a text file in order to be able to compile it.

It is put into a text file, because the that is the sort of input that the compiler demands. This is a 50 year old idea that ought to be rethought.

The compiler/linker ought to be integrated with an IDE, to free the programmer from worrying about what code goes in what module, and what do I have to do to make this code visible over there. Globals? Externs? #include files, Library Paths... toss them out the window.

One ought to be able to open an IDE, and see a list of projects. You open one of them up. If you are a designer, you see design documentation. If you are a developer, you see the code. If you are a user, you see the wiki.

The design documentation is hyperlinked to the code, and the code back to the doc, and back to the users guide, so you can get to any level you need. So you are in some function, and you wonder "Why on earth did they do it that way?" You follow the link to the design specification to see why. You follow from there to the requirements document. You follow that to the name of the person who suggested it as a requirement.

All the file management go. It is left to the internals of the IDE.

Now you're deep into information management, and not really coding per-se. This sort of thing is amazingly lacking in the real world. Outlook + it's Journalling functionality tried it, and it sort of works, but it's Microsoft-only. What we REALLY need is a new computing paradigm, document-centric...
Chris Kaminski
As a programmer who doesn't use a typical IDE (Gedit/VIM and Bash) I would hate compilers to be tightly coupled with the IDE.
Aiden Bell
I'm not sure that document is the right thing either. Containers for chunks of code perhaps. At most a container for functions.
You seem to be proposing a more fancy way of looking at source code in a text file, with something like HTML in the comments. I don't understand what you're proposing, really. Not to mention I distrust all IDEs and ease-of-use setups: they all have their limitations, and it's good if there's an awkward ugly interface that does everything possible.
David Thornley
Where the source is actually stored, would probably be a database of some sort. A text file is not the right answer.
What's wrong with a text file? Nobody's answered that one for me. (I could make a case that our code is in a database, maintained by a specialized DB application called Subversion, for that matter.)
David Thornley

Dare I say it might actually be a new development language (perhaps even a new paradigm) to take us through such revolution;

+5  A: 

One thing I've done recently in some of the more math-heavy sections of my application is to include the LaTeX markup for the particular equation as a comment/docstring. Right now, I just copy-paste into an online equation editor, but it would be very helpful to see the formula itself (with things like Greek letters and sub/superscripts) rather than a bunch of ASCII code.

Tim Whitcomb
+28  A: 

I'm surprised that nobody has yet mentioned No Silver Bullet. In 1986 (!), Frederick Brooks predicted that:

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity. [...] We cannot expect ever to see two-fold gains every two years."

And in 23 years, he's been proven right. We've come up with a number of things such as syntax highlighting and Intellisense which have improved productivity significantly, but certainly not by an order of magnitude. As time marches on, we'll continue to make several incremental improvements, but the fact is there is no silver bullet: there's not going to be some magical revelation in the way we write code that will improve productivity by an order of magnitude.

Adam Rosenfield
Nice comment, Adam. Thanks for posting this.
Nils Pipenbrinck
May I quote you in case I do find that silver bullet? ;-)
Go right ahead. If you can find what nobody has found in 43 years, I'll tip my hat to you.
Adam Rosenfield
Last time I checked, NSB was written in 1986, not 1966 :-)
David Johnstone
If people actually learnt the languages they use and learnt how to write code, instead of noodling along with Intellisense/etc, there would be a huge productivity increase.
Peter Boughton
D'oh, you're right, I misread the 8 as a 6! Fixed now. s/43/23/ in my previous comment.
Adam Rosenfield
I think we need to look at the difference between essential complexity (the problem is hard) and accidental complexity (the tools are awkward) in Brooks' terms. I'm not sure how much accidental complexity there is to eliminate, although I'd suspect there's a lot more in really large projects.
David Thornley
@none In fact if you can increase my productivity two fold, I'll get my boss to buy you a beer (or two)
Nathan Koop
Check out the Subtext IDE video and tell me if you still like if,elseif,else --
Jeremy, I'd love every IDE to be able to visualize my code with this exact form of a table ... when I click the "visualize logic" menu item! But I don't understand him: the examples he gave were elementary, and I had the right code in his first example the moment he stated the changes he had to make. He's right, notation matters, but I don't think it's huge progress.
The Wicked Flea
@David: There is still a ton of accidental complexity, probably more than ever now. Look at the C/C++ we write. Most of it is orthogonal to solving the problems, and instead focusses on very low-level issues, like putting pointers into memory locations. Even in very high level languages like Python and Haskell, there is a ton of accidental complexity.
Paul Biggar
+1  A: 

A few weeks back the "Intentional Software" created quite a buzz about their new language. I've yet to watch the presentation, but here is a quote from a review by Martin Fowler:

They started worryingly, with the usual unrevealing Powerpoints, but then they switched to showing the workbench and the curtain finally opened. To gauge the reaction, take a look at Twitter.

  • @pandemonial Quite impressed! This is sweet! Multiple domains, multiple langs, no question is going unanswered
  • @csells OK, watching a live electrical circuit rendered and working in a C# file is pretty damn cool.
  • @jolson Two words to say about the Electronics demo for Intentional Software: HOLY CRAPOLA. That's it, my brain has finally exploded.
  • @gblock This is not about snazzy demos, this is about completely changing the world we know it.
  • @twleung ok, the intellisense for the actuarial formulas is just awesome
  • @lobrien This is like seeing a 100-mpg carburetor : OMG someone is going to buy this and put it in a vault!
Davy Landman
+2  A: 

Diffing and searching pictures is hard. Diff and search are very important to programmers. Using pictures instead of text is only a marginal improvement in many situations, it has some drawbacks, and it requires general acceptance before it's really worth doing (since you don't make things more understandable if your reader doesn't grok what you've done).

Plus, programmers have a million little tricks that make their lives easier, based on text representations of code, that they'd lose if you gave them code to read that was expressed in anything other than text. Sure, they might replace or re-implement those tricks over time, but in the short term they're gone.

You don't see lawyers switching from English to little back-of-a-napkin diagrams in contracts, either (the Creative Commons licenses try, but cannot make the picture be the formal representation of the contract). Probably for similar reasons.

If someone comes up with a programming language and IDE that, on balance, beats text-based ones; and successfully markets it; then you'll see the start of a revolutionary shift from text to a new format. If nobody comes up with any such thing, then we're not missing out. If someone comes up with something that is more productive but it doesn't gain traction because of independent advantages of other technologies, then that loss is the price we pay for free-market capitalism. Perhaps the ideas will be recycled eventually...

That said, integration between code and documentation could clearly be improved, and there are many efforts underway to do so, using various techniques with varying success. Again, the problem is that any particular cunning plan can in practice only really be implemented in one or a few languages and development environments at a time, and so has difficulty proving that it really is better. Embedding documentation in code is possibly the only universal advance since the invention of the API...

I think there's still a lot that can be done with text, though. For example, debugger technology makes a big difference to programmer productivity in certain common circumstances (namely: when a test fails or something else unexpected happens, but it's not obvious what the faulty assumption is in the code you're looking at). There may be lower-hanging fruit in terms of making programming better, than the actual business of expressing the program.

Steve Jessop

I think you might want to take a look at Leo. This is one guys attempt at answering what you're asking about. I still can't wrap my VIM head around it personally, but others take to it quickly. It's not just a programming IDE, but more of an information organizer. It's written in Python, but I don't see why you can't code in other languages with it. The power of Leo is not so much the language, but the ability to express your thoughts and organize them whether it be in code, diagrams, images, or diagrams. Look over the tutorial and examples to get a feel for it. You might like it.


Automated semantic source code transformations, where a program can be reliably examined and manipulated by using an abstract interface/frontend to it that is aware of the underlying semantics.

So that source code can be queried and dealt with pretty much like a SQL database.

Allowing you to do static analysis of source code and refactor even complex source code by doing something along the lines of:

RENAME MACRO "max" TO "maximum" IN FILE "macros.hxx";
RENAME NAMESPACE "prj" TO "project";
RENAME FUNCTION "log" TO "show_log";
RENAME METHOD "FOO::inc" TO "FOO::increment"; 
CHANGE SIGNATURE IN METHOD "myClass::handle" WHERE SIGNATURE("char") TO SIGNATURE("unsigned char")
MOVE FUNCTION "foo" in FILE "" TO "";
+4  A: 

I'm surprised nobody mentioned it - javadoc is basically HTML, so there's nothing preventing you from embedding images (or anything else) in code. Simple, effective and ubiquitous, it's one of the things Java did right.

+3  A: 

I'd say version control was a pretty huge leap in how we work. The ability to keep a full record of every change anyone has made to the codebase, and to revert changes where necessary, has made a big difference.

Daniel Roseman
I agree, but cvs (which is probably the most significant one) has been around since 1990!
Yeah, and a place I contracted at in late 2005 didn't believe in version control. If I'm going to get into trouble for overwriting the production version of something, because there's no backup, well, I was glad I could just walk away at the end of the contract.
David Thornley
+1  A: 

Two quotes come instantly to mind:

"If it ain't broke, don't fix it." "Use the best tool for the job."

Of course, although the core code is still written as text, alll the tools and libraries have changed massively since the days of punched cards.

Jason Williams
+1  A: 

This has been touched on by others, and it wouldn't revolutionise programming, but anyway...

I think it would be nice if code editors moved slightly beyond plain text editors. Even with syntax highlighting and code completion (which I think are incredibly good things), the editors of today (at least, the ones I use) still display exactly the same ASCII text (or whatever encoding is used) that is in the source files. I would be interested to see how well it would work if editors displayed, for example (some examples are more adventurous than others):

  • Comments in a text box with a light-blue background and no // or /* ... */ visible
  • Javadoc comments could have semi-rich text editing support (for those who do HTML Javadoc comments) (seriously, I would appreciate it if code editors rendered Javadoc comments as HTML because they're not the easiest to skim over when their HTML as plain text)
  • Functions in text boxes that could be collapsed to show only the signature (the collapsing can be done by current editors) and can be dragged around as boxes
  • Lines between function boxes to indicate how functions are connected
  • Zooming out so that rather than seeing a single source file (class in many languages) you can see multiple files and the way connect to each other (this would essentially be building UML-like diagramming directly into the code editor)

I think this (in my mind at least) would work without requiring additional markup in the source files so users of plain text editors wouldn't be disadvantaged by having all this extra markup cluttering the files.

David Johnstone
+1, these are some pretty good ideas, regarding #4 this is in part available as part of they call it "Control Structure Diagram (CSD)" and it could probably be enhanced to also show callgraphs. It would actually be nice to collect the most popular suggestions and turn them into feature requests for IDE projects like eclipse or kdevelop.
Inspired by your suggestions, I have started a new question specifically related to novel features in IDEs:

Part of the problem might stem from the fact that when you don't code we don't call it programming: Assembling modular components using a GUI for instance.

Ollie Saunders
+2  A: 

I certainly respect Fred Brooks' argument No Silver Bullet, but I think the way we write code is nowhere near optimal, so there is lots more room for improvement. I tried to explain this in my book.

We're all familiar with "code golf", where you compete relentlessly to minimize something. That is a good way to approach the minimum possible value of that something.

What's great about this is that you are allowed, even encouraged, to break from traditions, prior conceptions, accepted wisdom, in the quest for winning. In short, you learn new things.

If the measure to be minimized is wall-clock execution time, you can do aggressive optimization.

If the measure is source code size (lines or characters) you get "code golf".

The measure I like best is "edit count". That is, given a code base, suppose a new requirement comes along. That requirement is implemented, completely, by editing the code base. Then a "diff" is done from old to new code base. The number of differences found is the edit count. Averaged over the set of likely new functional requirements, that is the measure to minimize.

If this is done aggressively, being free to contradict all conventional wisdom, the code base approaches a state I would call a domain-specific language (DSL). In this language, concepts expressed in code are in nearly 1-1 correspondence with problem-oriented concepts. In this state, it is not easy for the source code to be self-inconsistent (i.e. have bugs) because the fewer edits that have to be made to the source code, the fewer chances there are to make a mistake. It's also the case that such code tends to be short. But unlike "code golf" it tends to be very clear, because it maps the problem concepts so clearly.

So, tools and techniques that help in minimizing edit count can, in my opinion, be considered "silver bullets". DSL is one such. Code generation is another. My favorite optimization technique is another. For coding dynamically changing UIs there is differential execution. There are bound to be more, waiting to be discovered. Of course, everything depends on the training and experience of the "marksman" (the coder).

I think there are lots of new ideas to be discovered. The trick is to tell the difference between the ones that move us forward, versus the ones that hold us back.

Mike Dunlavey
Carl Manaster
I have no idea what you're talking about here, sorry. Is that supposed to be an automated way of generating unit tests?
David Thornley
I hope my update has clarified it; no, it's not an automated way of generating unit tests; it's a continuous-testing kind of thing, with highly localized feedback, deeply integrated into the IDE.
Carl Manaster
+1  A: 

You might be interested in these alternative programming "languages".

[Ladder][1], designed to mimic the way relay-logic-schemes work. Horrible IMO, but easy to understand for the old guys who did logic with sticks and stones. [][2]

[SFC, Sequential function chart][3], designed to simplify parallell programming. Code is written into boxes and these boxes can be placed paralell to each other and will thus execute simultaneously. By connecting the end of several boxes you can syncronize events. Very common for automation applications.

[Mathematica][5]!!!, Might not be the best programming language but the syntax highlighting(if you can call it that) is awesome! For example you can input a matrix by seeing the matrix nicly aligned instead of a huge double[][]. Graphs can be inserted in the code and the formatting of mathematical expressions looks like it does when you write on a paper. No more paranthesis-madness or long Math.PI expressions that really only need one character. And best of all, the files are just plain text even if it is rendered nicely in the editor!

Debuggers is also an area where lots of improvement has been done. Debuggers with replay are starting to come and also visual debuggers where data can be modified in real time. Edit and continiue is also a feature i wouldn't want to live withot.

WTF "new users can only post a maximum of one hyperlink", you will have to google the stuff i originally added to this post >:(


If something were to come out, nobody would use it anyway. I could save a lot of typing by using a GUI query build, but like everyone else, I want the control because I know queries can get more complicated than the typical GUI tool can handle.

Anyone dropping data controls on your forms/web pages? For the high-end user, you are correct, but there are millions of non-programmers whose ability to create software has increased exponentially over the last 20 years.

It all ends up as 1's and 0's so what do you expect.

Jeff O

Subtext. Edwards' ideas and papers are highly motivating. You have to see for yourself what's this all about:

Explanatory video

Vinko Vrsalovic
+1  A: 

I've used emacs, I like text macros. But, what I really want is parse macros. I'd like my editor to expose the machinery behind refactoring in such a way that I can write my transformations on the parse tree of the language itself.

For example, Python added += at one point when my code was littered with x = x + 1 lines. If I could have written a search and replace command that worked on the parse tree, I could have quickly cleaned up large amounts of my source code.

So, I want standard search and replace, but I want it at the level where the structure of my code has meaning, at the abstract syntax tree.

If you've ever used ReSharper, each of its refactorings and recommendations are written in the manner I describe, they find a pattern in the parse tree and suggest a replacement, or for a refactoring, apply a known replacement. I want access to that machinery for my own tasks!


Well, look at Medicine and Civil Engineering. These are interesting because people get hurt if not done well. These field have standards and licencing-procedures EVERYONE follows. You cannot wake up one day and begin to work in these field without going through painful rituals (school, licence, apprenticeship and other tasks.) Malpractice is not treated lightly. They do not talk about: "why don't we have good written-down practices"; they have them and everyone follows them at risk of banishment.

Now, lets talk about Software. You question has been the basis of books. Yet, where are the best-practice? Robert Martin coughed up one and Joel Spolsky ridiculed him to the point of insult and assualt. At least Martin tried to bring up some standards. Any Tom, Dick, Harry, Sally and Sue can start practicing Software development. If you do rubish, just leave your company (or get fired) and do rubish somewhere else. No one will rebuke you. Licence? IEEE tried it and who cares? Texas, USA tried it and who cares? Talk about certification and your work will be trashed (like one of Steve McConnel book- Software Professionalism.)

This was a tirade; but I went through it to tell you the state of things. Software just need time to mature and failures to get the government involved and big ad powerfuls heads to roll because it mature like Civil Engineering. I doubt if that will be anytime soon; but it should be in the far future.