Multiple representations

[zby]

Here is a link to an interview that I don't quite understand, but find very intriguing. Especially the notion of multiple representation of a program that work like projections in CAD systems used for designing physical objects. One can view a program written in Perl and some templating language as such a thing with two completing projections. But to change the projections at will?

Update: Discussion at JOS, Discussion at Finding Lisp

[tilly]

Charles Simonyi is the Hungarian behind Hungarian notation.

My cynical impression is that he is a very smart person who has a lot of big-sounding ideas, but I've never liked the execution much. But I'll freely admit that I may be biased both by the Microsoft connection, and from my intense dislike of Hungarian Notation.

Still I can't help but feel that he tends to solve the wrong problem from my perspective in a way that makes the right problem harder. For instance Hungarian Notation solves the problem of losing track of the data type of a variable by making the variable name a compact comment on its own data type. At the cost of causing huge code maintainance problems when you need to change a data type. Besides in some languages that problem is already solved perfectly well by type-checking in the compiler. In others the number of "types" is effectively infinite (it is the number of classes) and so his naming scheme does not extend.

Looking at the interview, I detect a similar concern. It isn't put as clearly there as it is in this older interview. His programming style seems to be to figure out his data structures first, and then to write his code as a series of transformations that preserve invariants in his data structures. This is indeed a powerful approach. Furthermore it is obvious why someone working this way sees data structures as being primary.

This concern showed up before in Hungarian notation - if you want the data structure to remain invariant then you really care about never losing track of what the full thing is supposed to be. And his intentional programming seems to be a reiteration of this concern. If you think that data structures are primary, and you want to encourage high-level programming, then you want to move control of the data structures up the chain. Which is what he's trying to do - make it easy to have the clients specify the data structure that they want, and the engineers write code that will work on that data structure. Afterwards the clients can add to the data structure and the engineers' code will continue to work.

Or so goes his vision.

This vision of how to program doesn't seem like a fit for me or the problems that I've worked on. It feels to me like he's solving the wrong problem for how people really work. But he's clearly solving the right problem for him, and there is probably an appropriate space for his solution. I just don't know what it is.

[hhdave]

Hmm. I agree that it does seem an interesting idea, though I don't think there's really much (or anything) new in it. It's definitely a useful approach though. I think what he's talking about is something like this...

Suppose you're writing programs to draw graphics on the screen (or whatever). You can do this using a series of drawing primitives in some imperative language (eg perl!) and it'll work fine. At some point though you might get bored with this and decide that, anyway, you don't want the actual pictures drawn to be hard coded into your program...

So you decide to create a language to represent graphics. Perhaps you call it SVG (scalable vector graphics). In the abstract this consists of a tree structure with bits representing shapes and stuff. You can write this tree down using some concrete syntax - XML perhaps. If you're motivated you might specify the language in some schema, like a DTD, so that others can write to your specification.

Then you need to implement an interpreter or compiler for that language, so that these pictures can be drawn (rendered).

Now, although describing graphics in this new, domain specific, language might be easier, you might soon get bored of that and decide to make a graphical editor for SVG (call it Sodipodi, say). Now it's much easier.

By now it's not only programmers who can write these graphics programs - people in the art dept can too. I think this would be what Simonyi means by an intentional editor. There are many other examples of these domain specific languages (XSLT, DTDs and other Schema languages, YACC, GUI definition languages etc) and many of them have 'intentional' editors.

I'd certainly agree that this approach of defining a DSL and making some way of executing/transforming it is a powerful approach. It isn't something that happens that often though (despite the above examples). Except, of course if you program in Lisp...

Lisp makes defining DSLs trivial. In the above example we could use SVG, but notated in Lisp S-exps instead of XML (or even write a Lisp reader which reads XML as s-exps) then define macros to transform the SVG into executable code (probably!). What you don't tend to get in Lisp (AFAIK) are DSL definitions (DTDs) or intentional editors. It would be very handy if you did though, and would certainly allow non lisp programmers to edit certain things. Good editors for Lisp do make it much easier to manipulate source code as a tree structure rather than a string of characters though. Viewing multiple projections would be nice too, especially if there was an easy way of defining these projections. Schema designing programs sometimes do that (I think) - eg XML Schema. Imagine if any equations in your source code could be rendered as nice mathematical equations a'la TeX.

As to storing source code in a versioned syntax tree database, well it seems to me that a text file is as good a database as any for source trees, and versioning can easily be achieved using standard tools.

Interestingly I have read that the 'syntax' of Lisp (such as it is) was only intended to be an abstract syntax (by John McCarthy) until someone got around to writing a concrete syntax for the language. The 'intentional' solution to this would seem to be to provide several different concrete syntaxes (or 'projections') of the code (or DSLs of the code). Maybe one day I'll look into rendering Lisp code in different ways.

[zby]

It sounded like a next step in using DSL, perhaps that was just marketing speak, but they might have some new insights into using DSLs. Now I feel you are right, but it is after reading other inteligent people talk about it that my opinion is formed, so thank you.

By the way, the fact that XML can be easily coded in Lisp does not mean that all other DSLs can. That's just accident.

[hhdave]

XML isn't a DSL - it's more of a meta language. It can be used as a syntax for whatever DSL you want (you could write Perl scripts in XML if you wanted - wouldn't be nice though :). Likewise with lisp, you can write whatever DSL you want in terms of parenthesis, symbols, strings and numbers, so I believe you _could_ express any DSL in Lisp.