Holy grail, eh? Well, if you really want to swing for the fences...<p>* Programming a computer in plain English.<p>* Teaching a machine to compose (real) music, or draw (real) art.<p>* Simulating a brain -- or, even better, emulating one.<p>* A programming language that makes it possible to write code that's worthy of being read as literature.
Minimizing the cost of producing secure, reliable, efficient systems that fulfill business objectives and are inexpensive to modify (where modifications preserve reliability and performance.) Included in the cost must be the risk of finding engineers to provide maintenance and changes.
Building software like we build bridges.<p>There are a lot of things wrong with this analogy, but I think it still encapsulates a nice ideal. We'd like to get it right the first time, and make it last with minimal maintenance.<p>(This is for software engineering, not computer science)
Enterprise software perspective - IT managed directly by business users. In that, the system can accept natural language descriptions of business logic, resolve ambiguity, and can self-modify, maintain, and heal itself. In other words, a virtual software architect.
The Holy Grail of software engineering — the one true approach to building software systems that can be applied, universally, to any and all software projects.<p><a href="http://www.cse.unsw.edu.au/~se4921/PDF/CACM/p15-glass.pdf" rel="nofollow">http://www.cse.unsw.edu.au/~se4921/PDF/CACM/p15-glass.pdf</a>
There's really three problems I can think of, in decreasing order of difficulty:<p>1) writing an AI,<p>2) proving P=/=NP, and<p>3) founding a 200-billion dollar company.
You know that scene in Independence Day when Jeff Goldbloom flies into the mothership and uploads a program to shut it down? That.<p>No, I don't mean an alien empire running on Mac OS 7.6.5, I mean extreme interoperability so software can rewrite itself to work on a different platform (self-porting, in other words).<p>Having said that, their firewalls were lacking!
A lot of the suggestions so far have really been for CS, not software engineering.<p>For software engineering, how about a practical way to do proofs of correctness for large real-world systems written in mainstream languages?
Solve the P vs. NP problem.
<a href="http://en.wikipedia.org/wiki/P_versus_NP_problem" rel="nofollow">http://en.wikipedia.org/wiki/P_versus_NP_problem</a>
The Singularity.<p><a href="http://mindstalk.net/vinge/vinge-sing.html" rel="nofollow">http://mindstalk.net/vinge/vinge-sing.html</a><p>I think Vinge explains it better than Kurzweil.
Here's a real holy grail of software engineering that might actually be attainable without getting Strong AI.<p>Significant code reuse without using a lot of hacks. I think Lisp and Ruby made great strides towards this, but I don't think we're quite there yet.