(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 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. 1. Every software project 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? [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): * someone who believes they have a need * someone qualified to help objectify the process connected to the need * someone qualified to help determine what in the process can be automated * someone qualified to help design the automation system * someone qualified to code the design * someone qualified to test the code to see how well it matches the design * someone qualified to test the code to see how well it matches the need * someone qualified to deploy the system * someone qualified to operate the system * someone qualified to maintain the system 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] [http://c2.com/cgi/wiki?VisualProgramming], especially [Prograph] [http://c2.com/cgi/wiki?PrographLanguage]. And take a glance at [Bwise] while you're at it ;) ---- [[Category ???]]