Subtext on Rails

My recent proposal to work on modeling capabilities fell flat, but elicited some good discussion of future directions for Subtext. Peter Marks wrote:

… I would rather see a complete re-examination of what lies underneath the World Wide Web. And then take the Subtext approach of banishing syntax, treating program as data, history, etc. … This would mean initially abandoning the UI demo and focusing more on the development of a system/infrastructure that works with and within the Internet.

Macneil Shonle wrote:

I wonder what “Subtext on Rails” would look like?

Continue reading “Subtext on Rails”

Plan B

Subtext faces enormous obstacles to becoming an accepted programming language. It is still just a sketch, missing crucial pieces. But even as I slowly fill it out, I am encountering unyielding resistance. There is a great deal of skepticism about the whole idea of non-textual programming, due to the past failures of Visual Programming Languages. Overcoming that bad reputation will require proof that the UI and VM can scale to industrial-strength, and that there are unequivocal productivity benefits. I can’t do that alone, and it seems that I won’t get much help (particularly from the academic community) until I can first overcome the skepticism. Chicken and egg. Modern programming languages have dug a deep rut over the last 50 years, and dislodging them will not be easy. It will require finesse. Continue reading “Plan B”

OOPSLA report

OOPSLA was great. I got a lot of positive comments and encouragement. It was quite heady to have established researchers, whose work I respect, introduce themselves and tell me that they liked my work. Perhaps a bit too heady: it wasn’t until the last day of the conference that I realized I should be using the opportunity to seek criticism and advice from the masters. Continue reading “OOPSLA report”

The Currency of Development

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”