Prism Project

(Apparently abandoned)

The following description is from the "Prism Manifesto." [1]

Prism's mission is to improve programmer productivity by improving the state-of-the-art in programming tools. At this time, interoperable codes (specifically, interoperable domain-specific languages) seems to be the best way to do so. Prism also has a few other related goals, each of which shall be achieved by a particular "phase" of the project. In brief, those phases are as follows:

Phase 1: Create a way for metaprograms (compilers, parsers, "lint"ers, etc.) to interoperate. This opens up the compilation pipeline, enabling competition for specific aspects of the compilation process and simplifying the creation of metaprograms, leading to higher-quality metaprograms and a more diverse toolset. It also lays the groundwork for phase two.

Phase 2: Create a way for codes to interoperate. This eliminates the biggest accidental difficulty remaining in the programming process, as described above. [See [1] for further discussion. The premise is that program design is an AccidentalDifficulty not an EssentialDifficulty.]

Phase 3: Extend the Prism approach to visual and interactive codes. The most popular and useful codes today seems to be spreadsheet codes. I presume their visual, interactive syntax have a lot to do with their success.

In LanguageUsability, JeffGrigg said

"It's been my experience that the most powerful tools, the ones that give you the greatest leverage -- and hence highest productivity, have a more limited scope. That is, they're less 'general purpose.' So, you trade development efficiency/productivity for limited scope of solutions you can deliver."
and JimLittle said
"This is the premise of the Prism project." [More specifically, Prism sees domain-specific tools as being the best way to increase programmer productivity. It addresses the scope issue by enabling domain-specific languages to interoperate.]

JeffGrigg's conclusion from reading several of the documents of the Sphere/Prism site...

But COM and CORBA increase the accidental difficulty of programming rather than decreasing it. They're complex solutions that are hard to get working right. They're also run-time solutions rather than compile-time solutions. Prism is purely a compile-time solution whose goal is to reduce programming difficulty as much as possible. Think of it as a next-generation linker that allows multiple domain-specific languages to be compiled into a single executable.

Standardized codes are part of the plan, but the project hasn't gotten that far along yet [as of 22 March 2000]. Right now, codes and parsers are being created for existing languages. If nothing else, these parsers will be useful for other people creating metaprograms, but the plan is to identify common elements and factor them out to generate standardized codes.

See also: InterLanguageUnification -- an OpenSource ObjectRequestBroker from XeroxParc.

Also check out Intentional Programming. This is a project being run by CharlesSimonyi at Microsoft Research. "IP" provides a development tool for representing programs as a tree of statements called 'intentions'. Each intention totally defines its action in a language neutral way. Intentions are like super C++ templates.

The intention tree can be "compiled" to a target programming language and platform. The idea is increase code reuse by several orders of magnitude. Once a stack data type has been defined once, for example, it never needs to be defined again. Stacks of any size and contents can be derived from the basic Stack.

I've heard recently that Intentional Programming has moved out of Microsoft Research and is now part of a Products division. We may see something soon.

See The original site at Microsoft Research is not available anymore.

Also search the web for GenVoca. It's a tool by Don Batory in Texas. GenVoca is tool for defining code constructs in a higher level than program code. The idea is to compose objects out of a series of 'layers'. Each layer handles a specific aspect of the object. Layers can be mixed and matched in a very flexible way. One example was a tree data type whose memory allocation layer could be one of: a fixed array (for speed), a series of large RAM blocks (for large in-memory trees), and a full distributed memory system (for terrabyte sized trees).

Host is unknown on 22/08/2001.


EditText of this page (last edited May 14, 2005) or FindPage with title or text search