Keith Devens .com

"""Finally, he makes a fairly big deal that the names in his programs aren't actually semantic entities, but merely comments that serve to annotate the "living program" or whatever. I think he's fooling himself if he thinks that's a real difference, let alone an advantage, of his system compared to other programming languages."""

I think there's an important difference. In most "conventional" languages, you use names to refer to types, variables, data structures, etc. Of course, deep down it's the data structures (and functions, etc) that are used, not the names. But you still need the names to refer to them. ... In Subtext, on the other hand, you simply copy existing data structures. Names are irrelevant: you don't need them to refer to anything; rather, you use the data structures themselves. The name becomes merely a comment, for the programmer's convenience. The fact that names don't need to be unique illustrates this.

Of course, deep down it's the data structures (and functions, etc) that are used, not the names.

My point was that names are irrelevant to the compiler/interpreter, and are utimately there for human consumption. That's the same between Subtext and any other language. You're definitely right that there's a difference in that Subtext doesn't actually use the names in its compilation/execution, but I meant that I don't think it makes much of a difference in how you actually program. You're going to have to pick names for things anyway for your program to be comprehensible. The one advantage I can see (as far as naming) is that, as he pointed out, you can often do away with temporaries.

What do you think... am I missing something?

I didn't see anything that got me excited. Using an editor like that would be a pain. But it's really not much different than something like Visual Studio with it's collapsable sections. It did get me thinking that editors that displayed code in more UML-like fashion might be kind of neat - display all the objects, click on one, then click on a function and edit it.

BTW, what do you consider to be the more expressive languages?

It sure is something different and new (at least to me), but in no way easier, more comfortable, user/human-friendlier that textual programming. And I don't think it will ever be.

Indeed. I don't know how anything can be more efficient than plain text. Plain text can of course be augmented with language-aware tools, like an IDE that can display dropdowns of built-in or defined functions, tell you if you've used a variable before you've defined it, generate object interaction graphs, have a built-in debugger that lets you mess with running code, and so on.

But it's really not much different than something like Visual Studio with it's collapsable sections.

Code folding wasn't the point. The folds were, among other things, actually showing successive levels of function application.

...display all the objects, click on one, then click on a function and edit it.

Watch the Self video.

BTW, what do you consider to be the more expressive languages?

I assume you're referring to my reference to C and multiple return values. I'd list languages like Perl, Python, Ruby, Lisp, among others as being more expressive languages.

> ...display all the objects, click on one, then click on a function and edit it.

Watch the Self video.

I did. Nothing very UMLish. I'm thinking more like Visio or something.

LtU has a thread about this.