Version 23 of programming in 2050

Updated 2004-05-17 10:29:38 by LES

(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?


SS I think the only possible way for humans to don't program any more (but why? it's a lot of fun sometimes) is AI, i.e. to model something very similar to our brain and let it to write programs for us. Being this a very far goal (if it will ever be reached), I guess that in 2050 we will continue to program ("We"..., I'll be 73, not sure I'll be still able and alive, I hope so). What may change a lot is the way we'll write programs, locking at the past, 50 years ago, the programming task was after all very similar to what it is today, the two main differences are: 1) The user interface is better today, good editors, graphic, and so on. 2) The average programming language today is at higher level and speed is somewhat less an issue, because for some kind of applications to trade the speed of the application for the level of abstraction (that's the speed of the programmer, after all), works well.

I may guess that in 2050 programming will be like today but just the differences between 50 years ago and today will be stressed: better user interaction, statement-level profilers, smart and easy to use debuggers with comfortable interfaces, and languages at higher level than today more suited to take care of the complexity of big systems. But actually to predict the future is hard (not that to invent it is simpler...), and maybe programming will take a very different direction. What seems very likely is that in 2050 we will continue to write programs, and I've a strong feeling that it will be not very different than today (think about math for example).

DKF: On the one hand, you've got the general fact that programming involves working out what your intentions really are, and that isn't something that is ever going to be easy. Even if there was a rmmadwim command, it would probably find that most people haven't got anything usably in mind at the time.

On the other hand, if we look at the past 50 years of computing we see that the practical expressivity of languages has come on in leaps and bounds. This makes me reluctant to say anything very much about what programming will be like in 2050. I look forward to finding out though, as the challenges and problems encountered along the way are bound to be very interesting. :^)

LES I've read rumours about Longhorn that if confirmed may cause very deep changes to the way programs are made. It's said that MS's new desktop model is bound to make almost anyone able to "program". Something like a very powerful VisualTcl or GUI builder. Users dragging here, dropping there and eventually coming up with their own tools. Or something.

RS remembers a C++ class, where we discussed that one would only need to subclass

 class Problem {
    Problem();
    ~Problem();
    solve();
 }

DKF: Most people can't program. This is a fundamental truth. It's simply because most people do not know what they really want the computer to do. Their ideas are very much at the level of "I want it to wash whiter, clean the cat litter out, and remember the wife's anniversary and favourite presents for me." These general ideas need to be broken down into specific steps, and it is the subdividing of a large problem into smaller parts that many people find impossibly challenging; they're simply not able or trained to really operate that way. And yet it is precisely that skill that is needed for programming.

Without a magic wand, most people will continue to find progamming hard to impossible. Alas, such people will also continue to be at a severe disadvantage in the modern world; a technological underclass if you will. :^(