4 ms·
I think that Martin Fowler hits the nail on the head with Illustrative Programming: "When you look at a spreadsheet, the formulae of the spreadsheet are not imm
by mkyc 17y ago
I think that Martin Fowler hits the nail on the head with Illustrative Programming: "When you look at a spreadsheet, the formulae of the spreadsheet are not immediately apparent, instead what you see is the calculated numbers - an illustration of what the program does. [...] Using examples as a first class element of a programming environment crops up in other places - UI designers also have this. Providing a concrete illustration of the program output helps people understand what the program definition does, so they can more easily reason about behavior."[1]
Illustrative Programming will fit particularly well with, and benefit from, programs that collect, crunch, and display data - this being area that I agree will see a lot of growth and attention.[2] "The ability to take data—to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it—that’s going to be a hugely important skill in the next decades,"[3]
Tools that are more suitable for large and complex data sets than Excel, and easier to use than R will become available. These will be used, as many current programming languages are, by people that are not trained in software development. Visualization will become much more important, so programming tool usability will improve. We'll see the influence of statisticians in our programming tools. Chasing down posts by others with similar problems and bugs will become easier. I'm not sure how much headway Illustrative Programming will make into the more hackerish areas of programming, though I hope it's a fair bit. For the best predictions on what languages will be like, just look critically at the languages that are at the start of their lifespans now (http://mythryl.org/ http://mythryl.org/ ? Arc?) and also at current research.
I think, though, that the most interesting changes will come from the sort of programs we'll be writing, the sort of people we'll be working with, and the sort of tools we'll have available, rather than from some feature x or y of some future major language.
[1] http://martinfowler.com/bliki/IllustrativeProgramming.html http://martinfowler.com/bliki/IllustrativeProgramming.html
[2] http://flowingdata.com/2009/06/04/rise-of-the-data-scientist/ http://flowingdata.com/2009/06/04/rise-of-the-data-scientist...
[3] http://flowingdata.com/2009/02/25/googles-chief-economist-hal-varian-on-statistics-and-data/ http://flowingdata.com/2009/02/25/googles-chief-economist-ha...
- fauigerzigerk 17y agoI don't think there is any indication whatsoever that programming the equivalent of a Turing machine will become any more "illustrative" than it has ever been. 20 years back we had buzzwords like "query by example" and we (almost) had VisualBasic. What has changed since then? Certainly not much in terms of programming productivity. What has changed is that we program the web now instead of a PC or a Mainframe. The architecture has changed. Esthetics have changed. Collaboration has changed. And we can crunch a lot more numbers now. Programming hasn't changed much. And I think it won't change in the next 20 years unless some hard AI problems can be solved.
- mkyc 17y agoYou might be agreeing with me, and perhaps are missing my point: more people, especially statisticians, will be engaged in the programming and programming-like tasks that are required to work with ever-increasing data. Not structured-SQL data, but raw and ugly natural-language and legacy-format data. Many programming tasks in the future will be about data, and excel-like "Illustrative" programs are very well adapted, even if not Turing-complete (Interesting discussions on the turing completeness/incompleteness of even something like Excel: http://www.c2.com/cgi/wiki?ProductivityRant http://www.c2.com/cgi/wiki?ProductivityRant http://news.ycombinator.net/item?id=429477 http://news.ycombinator.net/item?id=429477 ). Illustrative programming is just dynamic programming plus immediate feedback of program results - perhaps the ability to click on a GUI element, and change its associated code in realtime, perhaps just the ability to change how a data-point is calculated. The tools will be different. Turing-completeness will always look like Turing-completeness, but this is hardly interesting or relevant. I think that your claim about productivity is entirely false (see something like http://www.cs.umass.edu/~yannis/law.html http://www.cs.umass.edu/~yannis/law.html ), but that's beside the point of my post.
- fauigerzigerk 17y agoI do agree with you that data analysis is of growing importance (it's what I do after all). But I object to inventing a new fancy term for what you describe as "dynamic programming plus immediate feedback". We had that for ages. "Illustrative programming" is just a classical case of a consultant inventing fancy marketable language. In Excel the illustrative parts are not the ones that involve programming in the sense of Turing completness. I think we need to use Turing completeness as a benchmark, or any interaction with computers can be called programming. And I stand by my claim that programming something like KWIC has not become much more productive in the past 20 years. You could do it in Perl or in Lisp just as easily in 1989 as you could do it today. Even in C it's not that much less productive to flip and sort a few words than, say, in Java. But productivity is admittedly a complex concept. Of course we have a much greater effect writing software today, but I think that has very little to do with the core techniques of programming. We may be more productive on average, simply because more people make use of techniques that fewer people were using in 1989.