One of the anonymous reviewers of my OOPSLA paper made the point, paraphrasing, that the main problem in software development is not the difficulty of programming, but the difficulty of getting a development project to function effectively. This is usually seen as the subject of methodology, with â€œextremeâ€ and â€œagileâ€ methods being the latest trends. My initial reaction to this criticism was to point to the example of spreadsheets, which make a certain class of problems simple enough to be solved by an end-user or power-user themselves, without enduring the trials and tribulations of a professionally staffed development project. Even on such multi-person projects, reducing the programming effort ought to reduce the size of the team and the number of interactions subject to error. However the fundamental point of the criticism remains true: the biggest problem in software development is teamwork. It has occurred to me that the design philosophy of Subtext can contribute to solving this problem. Continue reading “The Currency of Development”
My little screencast has now gotten over ten thousand hits. Amazing. It seems there is a large pent-up desire for a better way to program. I have gotten lots of positive feedback, much of it endorsing not so much the particulars of Subtext as that I am making an attempt to improve things. Thanks to everyone.
I have also triggered some fairly negative reactions. I take this response also as a positive sign, that my work is threatening enough to warrant a backlash. I have written an FAQ to answer some of the recurrent criticisms.
This might be a good time for a progress update on Subtext. I have decided to change direction somewhat. I was previously working on “getting factorial right” with new representations for conditionals, iteration, and higher-order functions, as described in the Future Work section of my OOPSLA submission. I now think I should shelve that and instead face the issue of I/O and mutable state. This nasty problem has been the bane of much programming language research, particularly leaving functional languages tied up in knots. It could be the critical issue that makes or breaks Subtext. My new goal is to show how to build a GUI in Subtext, and to do so while maintaining the principles of WYSIWYG and the unification of edit-time with run-time, just as with factorial. I haven’t figured out all the details yet, but if I can pull it off it would make an eye-opening demo, and also make Subtext dramatically more realistic and relevant.
Building a toy for my children suggested an analogy with programming. Many toys come knocked down, requiring assembly, with instructions of the form “insert peg A into hole A, slide tab B into slot B, …”. This is just like the way we use names in programming languages, indicating parts that need to be attached by labelling them with the same name. The function call A is to be attached to the function definition A. Programming with names is like creating a program as a big pile of pieces with labels attached, and leaving it to the compiler/interpreter to assemble the pieces into something that works. Textual programs are knocked down.
The problem is that this approach boggles the mind when used with thousands or even millions of pieces. Modern IDE’s like Eclipse strive valiantly to help us imagine how things will plug together, but this is an impossible task. Even my kids know that all the King’s horses and all the King’s men can’t put Humpty together again.
The goal of Subtext is to fabricate programs as working wholes. No assembly required.
Here is a review of some research on managing the explosion of information in an IDE. Note that all of these are based on Eclipse, which appears to have become the dominant platform for IDE research.
Mylar is an experimental Eclipse plugin that tracks what program elements you are interested in, by watching your editing/browsing behavior. It alters the standard views such as the Package Explorer, Outline, and Type Hierarchy to focus in on what you have expressed interest in. Uninteresting things are filtered out, and the interest-level of the remaining things is indicated by different shades of highlighting. You can manually establish “landmarks” on program elements, which drive certain views to automatically display related elements, such as a type hierarchy filtered down to show only the inheritance structure of the landmarks.
Relo takes a different approach: instead of filtering the system down, it lets you build up a diagrammatic view of just the parts you are interested in as your explore.
JQuery lets you build a custom broswer by writting queries over your program. The results are shown in tree form, and you can expand any leaf with another sub-query, either custom or standard.
Dynamic Aspects has released some white papers and demos of their planned development tools. Their initial product is a Java IDE where the language becomes the tool. They seem to share many of my goals, and I am looking forward to seeing what they come up with. Their headline feature is micro-refactoring. Continue reading “Dynamic Aspects”
Lambda the Ultimate posted an item on Subtext. I waded into the ensuing discussion to try to clarify things.
I didn’t notice it for a few days though, and the attention span of blog discussions seems to be only a day or two. What I need is something like the old clipping services for newspapers, that would email me whenever anyone blogs me. I thought that was what pingbacks were for, but I have never received one (nor a trackback).
Oliver Steele observes a significant division among programmers: the Language Mavens vs. the Tool Mavens. I want to reflect upon this distinction, and use it to make a point about the nature of programming. You see, for a long time I was a Language Maven, but now I am a Tool Maven. Continue reading “Crossing the IDE Divide”
Sir – your Nov 25 special report â€œManaging Complexityâ€ asked whether the manifest failures of software can be fixed by giving developers better tools. Some of the tools you discuss, so-called Lifecycle Management, will actually make things worse. Lifecycle Management is an ill-concealed attempt to impose a totalitarian regime upon software development. As such, it will inevitably fail, but only after having first caused much damage. Experience has shown time and again that successful software development results from the freedom to innovate, not the discipline of control. Continue reading “Letter to the editor of The Economist”
I discovered the creative exhilaration of programming at a formative age. Yet all along I have also felt stifled by primitive, ill-suited languages and tools. We are still in the Stone Age of programming. My quest is to better understand the creative act of programming, and to help liberate it. Reflection upon my own practice of programming has led me to three general observations: Continue reading “The future of programming”
This Manifesto is deprecated. My views have evolved, and a new version will be released “real soon now”.
Compared to every other field of design and engineering, programming is an embarrassment and a failure. The “software crisis” has dogged us from almost the beginning. We who have made programming our life will no longer tolerate this. Continue reading “Manifesto of the Programmer Liberation Front”