OpenPoplog Manifesto

(This is a work in progress. Please watch this space...)

Development and use of Poplog has tailed off in recent years. It is a key objective of OpenPoplog that we reverse this decline to preserve the value of the contributions of the large number of people over the last 35-40 years.

There are many areas where Poplog has deficiencies that could be addressed. Fashions in the industry have also moved on and developments like the Internet, the World Wide Web, mobile telephony and a proliferation of powerful but cheap computing devices have provided an infrastructure for pervasive client-server computing that has left Poplog behind.

Windowing and Graphics

The current windowing and graphics supported by Poplog assume an X11 implementation is available. This limits Poplog to Unix or Linux based systems with a relatively powerful complement of hardware.

It would be better to have clearly-defined interfaces for window management and basic two- and three-dimensional graphics, allowing platform-developers to supply an optimised, native solution that can be driven by Poplog on any platform. This would also make the system easier to port to other platforms, e.g. PDAs, tablet PCs, mobile phones, etc.

VED and Editor Interfaces

VED provokes strong reactions from various Poplog enthusiasts, ranging from the "I use it for everything" to "the work of the Devil incarnate". This is probably inevitable, given the religious fervour devoted by many in defence of their favourite operating system, programming language and editor.

Instead of providing support for religous bigotry, we would be better ensuring the existence of a clearly defined editing interface, such that any programmable editor can be easily integrated with Poplog.

To make this work, we need to recognise that an editor has a number of roles, and we need to cater for each of these.

The role of an editor as the tool for manipulating code as part of an integrated development environment, needs facilities for selecting (or marking) ranges of text and compiling them, with one or more output buffers for the result and a set of configuration settings for compilation tool selection. This role also needs facilities for searching and replacing text, styling sub-sets of text according to pattern-matching or parsing rules and identifying namespace additions enshrined within the code.

The role of a browser for finding the appropriate section of documentation, and focussing into the correct level of education or reference, is better served with a tool that can display a standard generalised markup, or derived language.

Please report errors and/or omissions to the editor.