More on Intentional Programming
Okay, now things start to get clearer for me. I’ve read two articles by Charles Simonyi (both using the Wayback Machine): The Future is Intentional and Intentional Programming Overview. (See also my first post about this.)
In Java, you have the virtual machine, which is something Java picked up from Smalltalk. The virtual machine executes “virtual machine language”, or Java bytecodes, that are produced by the compiler. In Smalltalk, the virtual machine is more closely integrated with he development environment (the IDE). The IDE is written in Smalltalk, and is run by the virtual machine, and you can invoke things in the IDE from within your program. For example, if you “send the message” browse to an object, a class browser will open with the class of the object selected, allowing you to see what messages the object responds to, and what its superclasses are.
Anyway, the point was neither to describe Smalltalk nor Java, but to say that there is (as I understand it) something close to the Smalltalk IDE in Intentional Programming (or IP, for short). Your programs, as well as the development environment, runs on a virtual machine (or “IP kernel” as Simonyi calls it in Overview). The difference is that the bytecodes are “intentions” (or abstractions).
IP has no syntax like other programming languages have. The syntax depends on which intentions your environment is loaded with. As Simonyi writes in Overview, the source code in normal programming languages “represent only one aspect of programming, namely the implementation detail” – that is, it’s but one possible rendition of the program. Some IDE’s, like Together, show UML diagrams for the program. If it does this from parsing the source text or analyzing the bytecodes I don’t know – probably the former – but in essence it’s just another possible rendition of the program.
IP instead lets each intention define how it is to be rendered when viewed by the programmer. This could be graphically (such as a UML element), as text, or some other way. Simonyi writes in Overview that programming languages are about (a) syntax and (b) abstraction mechanisms – that is, that they define a form for expressing abstractions. “Procedure calls are extremely basic abstraction mechanisms which all programming languages possess. Coercions can not be expressed using procedures [...] so they are expressed by a different mechanism” – that is, coercions (or “type casts”, which is an abstraction) are written using a special syntax.
Simonyi writes that if one language has a feature that another language lacks, “as in “The language Eiffel has a procedure precondition feature”. By this usage people mean: it is understood that [preconditions] can not be (or can not be conveniently) expressed by the usual set of abstraction mechanisms, so a syntax for [preconditions] has been defined.” So a programming language X that can’t be extended or modified by its user, is a “fixed set of [abstraction] mechanisms collectively called X.”
If you defined intentions for all abstractions in Java, and defined their syntax according to the Java language specification, and loaded them into your IP kernel, you could, from what I understand, write Java programs. But these would all be very low-level abstractions, such as “class, object, method, scalar integer, +,” etc. In object-oriented programming, you come up with classes representing concepts in the problem domain, such as “Employee,” “Department” and “PayCheck” – which are all abstractions.
In order to be able to understand and deal with complex systems, it’s important to “hide” complexity in abstractions. Let’s say that your system involves doing really complicated indexing and searching a large set of documents, you would still be able to talk about “the Indexer” and “the SearchEngine”; “Indexer” and “SearchEngine” being abstractions for extremely complex things. Intentions for “Indexer” and “SearchEngine” might be defined to render themselves as intuitive icons, but only rendering themselves isn’t enough – they must do something, too.
Intentions in IP define “xmethods” for rendition and for transforming themselves to more “primitive” intentions. Compiling in IP is called “reduction,” because the xmethods for the intentions in the IP tree are invoked until all that remains is a tree with the most primitive intentions – that is, something approximating Java bytecodes. This means that you can create intentions by aggregating other intentions, and when reducing that intention, it would emit the aggregated intentions to the IP tree. These intentions in turn are built from other intentions, and after a series of reductions, you end up with only basic primitive intentions, which is the form you would ship your product in, I guess.
I’m not entirely sure how the IP environment distinguishes between the definition and implementation of an intention, but one intention can have many implementations – along the same lines as an abstract class or pure interface in object-oriented programming can be subclassed, or “implemented”, by many classes, in many different ways. The benefit of the IP environment would be that it enforces the separation of definition and implementation, as well as enforcing good abstractions.
Simonyi also claims that IP is not associated with the overhead of very-high-level languages, and he describes an abstraction of a collection, for which a very special case involves storing boolean values which require very fast evaluation. So, besides having one or many general-purpose implementations of the collection abstraction, you would have a specialized one which packs the booleans into a 32 bit integer, representing true as zero, so checking if the entire set of booleans is true would be done by checking that the packed integer is zero.
When you “reduce” (remember that it’s the IP equivalent of compiling) your IP tree, having selected the ultra-fast, packing-booleans-in-integers implementation of the collection intention, this would be reduced to primitive intentions doing the ultra-fast packing stuff – the difference being that your code still uses the same intention as it would with the general purpose collection. I’m not sure I have fully understood the difference, but perhaps it comes to me within a few days.
Anyway, I like the ideas in IP and I will probably continue reading about it. There are probably a bunch of misunderstandings above, but I think I have understood the core of the subject, at least. I guess I will return to this in future posts.