The comments on Plan B have changed my mind (a rare occurrence in the blogosphere).
The problem Subtext faces is that programming languages are boxed in by convention. When you say “Programming Language”, people assume you mean strings of symbols to be compiled into a program. There is a massive background of theory, practice, and technology wrapped up in that conventional meaning. Subtext is outside that box. Some things about Subtext would play well as a modeling language. But when you say “Modeling Language”, people assume you mean “informal whiteboard diagrams”, which is just a different ill-suited box. Some people in the modeling community believe that separating software design from implementation is profitable (for several of the meanings of profitable). I disagree.
Subtext is and will always be about building things that actually work. That makes it a programming language. Adding modeling concepts to Subtext may be a good idea, particularly data-modeling concepts. But I should stay true to the vision of making a better programming language, which is Plan A.
Forgive me for straying from the path of righteousness.
initially using an alternative word to ‘programming language’ might earn you marketing/attention points. I don’t know, something like ‘executable models’..
One problem is that many people came before with claims about “non-textual programming” (or other ideas) and how it would miraculously solve all programming problems. Mostly they had nothing really interesting to show, and so you have it. It is natural that practicioners are skeptical, as they mostly are even with incremental improvements from academia. Academics are skeptical too, and in part it’s natural: lots of crackpots out there claiming to proof that einstein was all wrong or that they have a 1-page proof of Fermat’s last theorem.
I had an initially bad reaction to Subtext, having recently read a lot of similar claims, almost all without substance. I still am somewhat skeptical about it being able to scale, but I’d like to see it develop. New ideas must be tried, and that the current industry always falls back to the same ways of doing things is quite annoying to me. I was even planning to read your OOPSLA paper, which I’ll do when I get less swamped with work.
So, Plan A is the way. I’ll be following.
Plan A sounds indeed better.
Maybe do a study. I’m sure you must have a bunch of applications written in Subtext by now. Compare those to what another language would give you. Then convince the reader that in Subtext it’s harder to make mistakes, easier to do the right thing, you write less code, it’s easier to test, easier to maintain etc.
AFAICT the visual paradigm langauges so far failed (among other reasons) because they would not scale past a few trivial functions. One gets tired of drawing boxes for each if statement pretty quickly and it makes you slower rather than faster. I remember a recent OOPSLA (2003 I think) demo that had exactly that problem.
To have a hope of convincing people you need arguments. You need examples, real ones and lots of them.
/adam
Also remember how hard it is to get a new idea out there. Just look at AOP and AspectJ. It took a whole institution (Xerox PARC) to put millions toward it, along with someone like Gregor Kiczales helping it move at each step. And also look at Intentional Programming, which had the backing of a Microsoft millionaire (and still does, though it hasn’t gotten far).
On the other side, non-academic programming languages (like Python, Perl) tended to “scratch an itch” that the open source community had.
It’s not my place to say where your work belongs, but given the reaction from academics in private, it’s something to be excited about!
I don’t think that the problem with software development is really about how to represent the computer programs, be it textual code, diagrams or what ever. There are so many approaches to this problem, none of which has ever improved anything significantly. Every time you try to make a programming language better you focus on a specific problem that you have observed or experienced with another language. How do make sure that solving one issue does not incur a new one? Programming a computer is actually about translating a mental model of a real-world problem into abstract algorithms that can be run on a machine which works with step-by-step instructions. The programs that we want to run on a computer are so diverse as are the real-world problems they correspond to. That’s why we will never be able to write the “ultimate” software in the “ultimate” language on an “ultimate” computer.
Abstract thinking is hard and examples help—that’s true, but it’s basically the combination of both that makes us understand thoroughly. People don’t only think in examples: they observe they abstract, they associate—that’s what intelligent thinking is all about. There are emotional people, there are rational people. A computer is very limited compared to that. Don’t try to limit a human to only one aspect of his way of thinking. If you really want to make a better language make one that supports examples as well as abstraction, one that is imperative and declarative, one that’s textual and visual at the same time. Sounds difficult? Yes it is, so why not take the many different programming languages that we already have and search a way to combine them smoothly.
Computer scientists are arrogant and blind: they think that they are can do every step of a software development process themselves! They think they are the best problem analyzers, modelers, programmers, project managers, writers, teachers, usability engineers etc. There is no other science or industry where there is only one profession involved: You need dozens of dozens of different professions when building a bridge or a car, or organizing a soccer world cup—all of which have only a very limited contribution to the whole. Two computer scientist cannot make good software products alone! Did von Braun build the rockets all by himself? Could he have?
Instead of thinking about how to improve the programming languages (only a small piece of the software development) we should start thinking about the process and the people involved. How can we cut the process into small pieces, what different professions do we need? How can we make people with different educations and abilities work together?
[Alexander – I tend to agree with you: we need to span the full spectrum of thinking from concrete to abstract, and the full spectrum of roles from user to implementor. I discussed some of these issues in a previous post.
— Jonathan]