I've finally gotten around to reading Jonathan Edwards' paper titled Subtext:Uncovering the Simplicity of Programming he presented at OOPSLA 2005, and I gotta say... it was an experience! I just don't know where to start, so I'll just start at the beginning.
Programming is HARD??!!?? I mean, COME ON!! Yeah, even I thought programming was hard, when I had just started off! Getting my fundamentals straight was the hardest thing, but that was my biggest hurdle. Programming isn't hard; visualizing relationships between loose-coupled abstract concepts, now that's hard. Saying programming is hard is like saying it's hard to put one foot in front of the other because you can't run the Olympic 600M! But the reasoning takes the cherry; Programming is hard because source code is removed from a programs behavior, because we're not compilers. Damn right we're not compilers, we're BETTER; that's why WE built compilers. Compiler were built to spare us from the 'inhuman' patience required to monotonously apply a 250 page language specification to any program from 2,500,000 to 25 lines of code, not because we couldn't do it. As for source code not presenting the behavioral view of the system, well, uhh, NEWSFLASH... I don't believe it was ever intended for that purpose! Source code presents a structural view of the system. We use collaboration diagrams and statecharts for that, but admittedly not all people and platforms provide for that, so I'll admit that there's no common ground here. Nevertheless, you can't blame that on source code.
Personally, I believe it's the lack of 'technology soft skills' like visualization and programming in the large that screw up most development, not that it's hard to represent ideas in a given syntax. Maybe we need to revisit CS courses to include these.
As for Usability, usability is about making a users experience with a system easier. Norman's Gulfs were developed as part of a user interaction study. Applying UEX concepts to source code and other programming media seems a little extreme.
The argument is text centric is a little ridiculous. Paper or for that matter any persistence medium is just that, a medium to store. Rich UI tools are just that, tools to program. WYSIYWG programming environments are at best visual/graphical representations or views of programs. How does WYSIWYG help if visualization is the inherent problem?
Coming to Subtext (finally!), Subtext is definitely not a language. Subtext is, as Edwards himself mentions somewhere in the paper, a programming ENVIRONMENT. It allows you to manipulate the structural components of the program directly. Kinda like playing with the AST.
Here's my gripe list on Subtext.
- Languages interface programmers to compiler/interpreter. Subtext opens up the gamut of program flow components to the programmers, something people have been trying to abstract/encapsulate from programmers in every paradigm shift. In my opinion working with actual program components is a huge step backwards, maybe we should just go back to Assembly or Machine language.
- The nomenclature used to describe program structure is ambiguous. Program nodes are divided into Structures and References, where structures could be Composites or Empty aka Atoms. Only Atoms can be leaves of the program tree, and References... so are References Atoms? But References could be linked to Composites, and expanded, with Reference Envelopes... you get where this is heading?
- No types. How do you work a mature, dynamic, 'reactive' language without... Oh wait...
- Subtext is STATIC!
- Labels are text comments. So I could just copy the Difference function into a structure and re-label it Add. I mean, we don't have just enough means of amplifying ambiguity already (!). Why is it so hard to admit that names are an identity mechanism? When I say Jonathan Edwards, we can IDENTIFY that the subject is a fellow at MIT who developed Subtext.
- Copy calling: This one is really weird. Structural changes are propagated both ways through copies, except divergences in variants are not propagated upwards. But a variant may not even have divergences. And divergences may exist outside variants as inputs. Man! I thought Polymorphism was hard, but this takes the cake, cherry and all!
- Subtext has no scopes! I can capture state from anywhere in the program flow, even in the middle of a function execution (multiple returns!). Encapsulation is simply absent. This looks like another one of those object based programming nightmares. JavaScript for the enterprise anyone?
- Subtext does away with variables by exposing (making reference-capable) entire program flow! Every line is as good as a global.
- Somehow, the data structure of a tree or even a graph falls short when projecting various aspects/views of a system. UI embellishments (compass, reference envelope, adaptive conditional table, etc) only complicate matters.
- Preliminary observation shows that programming in Subtext involves hard coding each and every flow of the program. So much for flexibility!
- Subtext suffers from IDE lock in. You can only work in a very specialized environment. I've seen other IDE specific platforms like PowerBuilder and Centura Team Developer (SQL Windows) hit the wall when programmers tend to get too deeply rooted in IDE specifics or when a requirement transcends the intent of the IDE.
- Then there's the question of programming in the large. It's not just scalability, but the idea of programming multiple disconnected, black box components in multiple source codes. Being in invalid states for short periods is, to me, a viable tradeoff for flexibility.
- Interestingly, the entire paper seems to sidestep the simple idea of persisting programs. How do you intend to store Subtext program trees? Text maybe!
Ever since I started reading about Subtext, I was intrigued by the idea of Reactive Computation. Seeing your program execute as you write caught my attention. But then I realized that I was so fascinated only because I had spent so much time explaining to people how programs work. That's when it hit me! Subtext is actually a great LEARNING tool. Rookies can use Subtext (minus the Theory of Copying) to learn complex program flows by direct state visualization. This could actually go along way in developing the soft skills I mentioned in the beginning.
My opinions apart, I don't want to discourage anyone's inquisition, so, I wish Jonathan Edwards the best of luck in his endeavors.
PS: My initial opinions were put up on JE's blog here.