(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 2004-05-16
How will a programmer in 2050 work?
I expect that a classical programmer will disappear because doing programming by humans is far too 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.
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?
LV: I did a study in the fall about the state of software testing. There have been in fact packages designed to look at code and attempt to automate the test cases that should be run, by taking a look at the logic and determining what sorts of inputs are needed to encounter each logical if, etc. I'm not certain that there have been objective tests over the years to determine the level of quality of these suites, but it certainly is a field of development. My own question about the above vision of the future is the idea that only someone qualified to test a particular area will be working in conjunction with the programming robot to develop software. What right now I see as the current reality is that a good software project consists of the following roles (not necessary a different or even a single person in each role though):
I could see coding as being something that eventually becomes automated. I could see testing the code against the design as being automated. I could see deploying the system being automated. Depending on the type of system, operation of the system may be able to be automated. And the maintain the system step is really a reiteration of the above steps, so some of that process could be automated. Determining how well a system matches real world needs is probably going to take a human. Identifying a need will probably, for the most part, be a human. There may be some automation of clarifying the process but a lot of that will probably continue to be a human. Also, determining how much of the process can be automated will probably stay human oriented.
SS: I think the only possible way for humans to not 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 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, looking 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. :^(
LV: For that matter, what I often find is that most people do not know what they themselves really want to do. It takes a dialog starting with them identifying a need, then someone working with them to figure out what the real problem is. Sometimes the person knows the real need - but often, at least for me, the person thinks they know and you have to get them to back up to the process and see things from outside their own narrow perspective to see what the real problem is before you get a chance to address the problem.
DKF: Nicely put. And all too often, they've got their own solution and can't see that backing out of some of their work might let them get to their real goal sooner.
jcw: So the hard part is not the solution, but the problem itself. Oh, and not being around by 2050, probably...
LV: dkf, definitely there's the effort of trying to open the requestor's mind to the possibility that their solution won't solve the entire problem. Of course, there is always the chance that the person is right. The human part of the problem solving process is deciding where the risk is - in starting down the solution path immediately, or doing additional background. To do things right, more time concuring the diagnosis and solution are correct would be spent. However, to get things done in a timely fashion, sometimes one takes the path of chasing down the requested solution without the assurance that it is the right solution.
MAK: Re: "I expect that a classical programmer will disappear because doing programming by humans is far too expensive" - funny, I expect that a classical programmer will disappear because (1) programming jobs will be outsourced and offshored so much that one couldn't make a living wage and (2) it won't be possible to make money selling software once there are open source versions of everything. But I'm a cynic. ;)
As for what programming languages will be like, I think there won't be any (or will be few) other than legacy applications. Languages will be replaced by modelling environments. It will be less about writing in a programming language and more about drawing a model of what you want the "code" to do. Sort of, eh, multi-dimensional flow charts or UML on steroids. Little visual constructs representing objects, blocks of code and data, with lines interconnecting them, and ability to zoom in/out to different levels of abstraction. Like an interactive schematic, where you might start with a whole board, zoom into a particular chip, zoon into a particular module in the chip, etc.
FW: See Visual Programming [L1 ], especially Prograph [L2 ]. And take a glance at Bwise while you're at it ;)
TAC: Visual programming has been a programming holy grail for years. But, it shares the same problem with pure object oriented programming: every once in a while you need to do something that transcends the paradigm. UML hardly captures everything an app may need to do. Its the non-OO bits that often trip it up. Aspect Oriented Programming is one approach that cross cuts OO and rigid modular encapsulation.
I suspect that programming in 2050 will be a lot like programming right now (at least for Tclers): You say what your intent is and when the language isn't rich enough to say it, you modify/annotate the language until your point gets across. Oh, and we will finally start realizing that we are already doing automatic programming (e.g. every time a proc writes another proc).
Programming languages, by the way, won't (or maybe I should say shouldn't) approach a more human language like syntax. Human languages are very imprecise. After thousands of years of spoken language, misunderstandings still cause catastrophes. I wouldn't want a computer to interpret the unclear instruction: Make the world a better place to live or clean up the junk in my house ;-) (If you see what I mean)
Computers will compose programs for themselves. That is, AI programs may write programs but they will be of limited interest to humans since computer programs hardly know how to compose programs that are usable by humans. Even problems that seem to be ripe for automation will still be designed and (due to the fact that visual programming won't fully work) at least partially programmed by humans. Take traffic problems for instance (coding up traffic light synchronization). Any elegant mathematical/computational solution will still have to take in consideration human psychology (humans don't react like vehicles in perfect traffic simulations -- i.e. we won't all drive 35 miles an hour exactly or stop on a dime). Of course, the computer solution then will be to relieve us of the responsibilty of actually driving the vehicle... I think people will still be cutting tons of code in 2050.
However, Programming won't become something the general population will do. There are probably people who professionally program right now that shouldn't. Just as it takes a special kind of mind to read/write music, write poetry and architect sound structures, so is the same for programming.
OH, and in 2050 we will finally have that Tcl super-optimizer I've always wanted.
DKF: A real AI system may well be absolutely crap at programming. It might prefer talking about existential poetry or something... :^D
NEM: Indeed. Also - why would an AI system use programming to solve a problem? A computer running AI programming another computer to do a specific task? Seems slightly odd - humans don't "program" other humans to perform tasks... or maybe they do! ;) Anyway, given the resistance that programmers have to adopting new technology, we'll no doubt all still be using emacs or vi on unix (in a console), churning out buggy code in C/Java/whatever. Except Windows programmers, who will be using Microsoft Visual Basic.NET++ 2050 and have an annoying paper-clip style character saying irritating things. Computers will have got ridiculously fast, but the operating system and multiple layers of bloated virtual machines will make sure that programs run no faster than they do today...
DKF: Isn't one of the fundamental networking truths "there's always room for another layer of indirection"?
aspect: Coming across this conversation in May 2014, I can't help thinking of this recent presentation from Bret Victor as an interesting reflection on the topic.