beyond programming languages

How's this for a research agenda:

As computer technology matures, our growing ability to create large systems is leading to basic changes in the nature of programming. Current programming language concepts will not be adequate for building and maintaining systems of the complexity called for by the tasks we attempt. Just as high level languages enabled the programmer to escape from the intricacies of a machine's order code, higher level programming systems can provide the means to understand and manipulate complex systems and components. In order to develop such systems, we need to shift our attention away from the detailed specification of algorithms, towards the description of the properties of the packages and objects with which we build.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

more extensive quote

The above abstract has been lifted from from Beyond Programming Languages – a 30-year old paper by Terry Winograd. Currently available from here [PDF, 1.3M] (DOI bookmark).

A more extensive quote to clarify what he means:

As computer technology (for both software and hardware) matures, our growing ability to create complex systems has led to three basic changes in the nature of programming:

  1. Computers are not primarily used for solving well-structured mathematical problems or data processing, but instead are components in complex systems.
  2. The building blocks out of which systems are built are not at the level of programming language constructs. They are "subsystems" or "packages," each of which is an integrated collection of data structures, programs, and protocols.
  3. The main activity of programming is not the origination of new independent programs, but in the integration, modification, and explanation of existing ones.

...it is useful to distinguish three types of specification:

  1. Program specification.

    A formal structure which can be interpreted as a set of instructions for a given machine...

  2. Result specification.

    A process-independent specification of the relationships between the inputs (or initial state), internal variables, and outputs (or resulting state) of the program...

  3. Behavior specification.

    A formal description of the time-course of activity of a machine. Any such description selects certain features of the machine state and action (e.g. input and output activities, use of memory resources, communication events among processes), without specifying in full detail the mechanisms which generate these.

Current languages provide only scattered specialized mechanisms for description of either results or process. ...if we look at what a programmer would say about a program to a colleague who wanted to work on it or use it, very little of the description appears anywhere in the "code." If (either because of idealism or coercion) the programmer has included comments, they can provide useful but local description. If further (almost always through coercion) the program has been documented, there may be more global descriptions. In large systems, documentation will include a careful specification of protocols and conventions not belonging to any one program, but vital to the system as a whole. It may also include process descriptions along with the result descriptions. But these various pieces of description are scattered, and for the most part not accessible in any systematic fashion.

A standard for information modelling is required.

In order to handle large systems over time, there needs to be a high level description of information...a language which allows the uniform representation of information. Algorithms is one type of information that has to do with computations, but there are other types.

Once that is achieved, information visualization systems can be easily developed. Visualization systems can have editing capabilities, allowing the user to rearrange the information or use them in computations to produce new information.

Computations need not be arranged in programs; they must be information, standing on their own, allowing the user to mix them at will, just like with any other type of information.

HLLs for information

Give that we don't have great, flexible, powerful, down-to-earth HLLs for information, perhaps one sign of an experienced dev is somebody who has tricks or practices up their sleeve for dealing with information. E.g. they know how to support having Excel read/write to Java or whatever other real-world use cases come up. Things like Java probably end up making that harder than it has to be? Things like Haskell or O'Caml (or VB? :-) seem to enable and attract people who can come up with nifty tricks to automate a lot of things that are done more laboriously in e.g. Java. A language which lets you do that (if you can figure out how) is 'better' than one which doesn't, i should think. Sure, somebody could externalize all the verboseness of a solution in e.g. Java into some library and that's great, but it is better if somehow the system lets you get it done w/out all that finger typing.

I don't think it's a matter of programming language.

I think it's a matter of what language computers speak...a matter of protocol, if you wish.

For example, I can't ask the computer next to me to find all photos with a certain person in it. One reason is that there is no common definition of photo. Another reason is that there is no protocol for asking.

Of course, I could setup a database in the computer next to me. But I can't store photos in databases. I can store BLOBs, but what is a BLOB? it's not a photo.

I could make a public directory with photos. But then I would have to put all the photos there...which means that the person that makes a photo must place it in the special photo directory.

I hope you can see where I am going...there is a trend, isn't it? computers, as they are, contain binary data, but they don't contain information. That's the number #1 reason why we can't go "beyond programming languages".

There are countless other examples, and although I find this conversation much more important than the PL mathematics, I doubt other LtU members wish to be involved, from what I see so far.

I am still waiting for someone to make an operating system that does not have the concept of filesystem/process, but the concept of information/function. Microsoft promised us a similar thing with WinFS, but they did not release it with Vista in the end.

And they usually go by the name of...

...logics, ontologies, and knowledge representation schemes.

KRL

Sure, knowledge representation schemes. Winograd himself described this approach as a matter for extensive research -- codespeak for "We don't have much to show for our efforts yet."

Once again it is important not to let our preconceptions get in the way. Notions such as code, listing, file, and compilation are based on the idea of a program as a set of instructions. There need not be any directly corresponding objects in a higher level system. Instead, it should be based on something much more like what we now think of as an artificial intelligence system with its "knowledge base" of assertions and procedures. There will be a set of interrelated descriptions, stored in a form that makes it possible to retrieve, manipulate, and display them. These will include prototypes for categories of objects and processes (like classroom and filling out a form) and instances, which correspond to individual objects and processes in one of the domains (such as the course CS 365 in Winter 1978, the contents of the third page of next quarter's schedule, and the process currently running in the database server). Instances can be described by more than one prototype, and prototypes are related into hierarchies with different degrees of abstraction. The details of all this are still a matter for extensive research. One set of possibilities is being explored in KRL [6, 7], but the basic idea of higher level systems could be implemented using other descriptive representations, such as semantic networks [8, 10, 14, and 15] and other frame-based systems [9, 11].

Has anything changed in the past 30 years?

Positivie ontology examples

In the bioinformatics world, there are successful ontologies such as GO. Now, you have to take "successful" with a grain of salt because - and this is I'd hazard to guess one of the reasons we still don't have Achilleas' information systems but only programming systems - human knowledge is quickly found to be only fuzzily defined. Seriously, the standard joke of biology is, "define the term 'gene'" and yet it has to be one of the most fundamental concepts for the field!

Indeed...

...much research in biology is dedicated to the goal of producing an adequate definition for the term "gene"--or to showing that we should discard the concept.

And I suspect that ultimately, we'll discard (or heavily modify) the concept of gene--the old "model" of a discrete bit of information, biologically encoded and corresponding with some observable phenotype, will be shown to be far too simplistic to be useful.

Yes, albeit incrementally

in increments of how many microReids?

When it comes to Doug Lenat's enterprising endeavors, incrementality is measured in μLenats.

Paying Customers

At least they have paying customers. :-)

Personally, I like PowerLoom for KR tasks.