(or why is no good software available ?)

this is just an discussion about the future of programming including visions and reality based expectations

----
[Andreas Otto], 16 may 2004
----

'''how will a programmer in 2050 work?'''

I expect that a classical programmer will disappear because doing programming by humans is far to expensive

'''who will write the software needed?'''

it will be a combination of a programming robot and a human who will act as a testing/quality engineer

'''how will programming in fact look like?'''

every software-project starts with a need. the interface between the tester and the programming robot will be designed to accept ''needs''. ''needs'' are just restriction in form of test-cases.

every software-project is defined as a round-trip between writing test-cases and testing the application.

   1. every software starts with a basic set of test-cases
   2. the programming robot creates a '''runnable''' application which evaluates '''all''' test-cases without error
   3. the human test the application and checks if additional ''needs'' (test-cases) are useful
   4. back to step 2.

example 'tcl':

tcl is a programming languages with a set of ~12000 test-cases.

1. programming view

the tcl-interpreter is ''valid'' if ''all'' test-cases evaluates without error

2. testing view

every tool which evaluates ''all'' test-cases without error is called a ''valid'' tcl-interpreter

 => question: what is the difference ?
 => answer:   you only need the test-cases to define the tcl interpreter 
              and 'not' the interpreter itself

----
[RS] Interesting... But I can sketch a trivial 'programming robot' that creates a compliant application for any given test suite (except if it contains contradicting tests):
 set f [open test.cases]
 foreach {case expected} [split [read $f] \n] {
    set outcome($case) $expected
 }
 close $f
 proc eval args {return $::outcome($args)}

:)

[WHD] Exactly.  No test suite can test all possible inputs (except for trivial programs).  The Tcl test suite tests examples of each class of inputs which the Tcl interpreter is designed to handle, including edge cases and corner conditions.  Since we know that the Tcl interpreter was designed to handle each entire class, we assume (and we discover in practice) that if it can handle representative test cases from each class that it will also handle the non-tested cases.  Your programming robot would have to be able to infer the semantics implied by each set of test cases, or it might end up with something like [RS]'s code that handles the specific cases but not the general problem.  And then there are programming problems like attractively laying out a GUI application where human judgement is required and test cases are notoriously hard to specify.  In order to write such a programming robot, I think you'd have to solve the strong AI problem.

Of course, [RS]'s answer is wittier than mine.

[US] I remember I heard of this very vision in the early 1970's. Didn't you, too?