Personal Programming - Requirements
A Personal Programming Platform (P3) is a programming platform, that is built to be a very portable and easy to use programming language/environment. The following are some of the requirements for a language to be called P3.
Small Footprint: This is the most important requirement for a P3 platform. The entire programming and executiong context, including the user files and output directories and any other resources should all be available as a single unit - a single directory tree. And this tree should not in any way be tied to the system on which the platform is executing. User files should be forced into the same directory structure. Installation should be little more than unzipping/installing. There should be no references in the Registry or in the System folder or wherever. The entire P3 platform should work out of a single directory structure - by design, even if that means sacrificing of some flexibility.
The idea of a small footprint is portability. I should be able to take along my entire development, execution and data contexts with me in one move when I go. A single tar or zip command should be enough to allow me to migrate to a new system. A single delete command should remove all traces of me having worked on the system. Simplicity and ease of movement is the hallmark of a small footprint P3 system.
CLI & WIMP enabled: The main execution context of the system should be something like that of MATLAB. When the program is launched, the user will end up in a command line interface (CLI). Here interactively he will try to accomplish tasks that he will want to do. He will be able to run a command or a script, invoke a IDE to develop and edit a script and also bring up a debugger in case the scripts are misbehaving. During and entire session with the programming language, the CLI will be the base for working. The Python CLI is a very good starting point, but of course some changes will be required by it too.
Additionally, there will be a tight integration with the WIMP style of working also. For example, when a script is worked on and perfected, it should be possible to move that as a "macro" to a toolbar button with an simple command. The next time, the script will be available by clicking on the toolbar.
Run Time Database: This is the most important requirement of a powerful P3 environment. During execution of any script, it will have access to a SQL style database. This need not be a true database, but it will automatically be available to any script or program when it is running, without additonal programming effort. This run time database should support SQL style queries, though it need not support the entire command set. A smaller and modified SQL command set, dSQL (dynamic SQL) needs to be supported by this database.
The database is not built for performance, or to support deep nested select statement. Rather, it provides a easy to access database system, which can be use by any executing program. All data that is not hardcoded will be part of this database. All runtime information is best accessed through this database.
Of course, this database needs to be persistent. Shutting down the program should not destroy the data.
The database not only stores information which the program needs for its execution, but it acts as a data source for many other data requirement calls too. The database will define a schema that will allow users to "query" for information like "current date" to a "random" number etc. Most function calls will be reduced to a database calls. Function wrappers for these calls will also be available.
Powerful synchronization: This is another requirement. The P3 is designed to be used by users on the fly, on the move, and not necessarily when they are working out of their base system. As a result, it should be well aware of all changes that are being done to it. When one or more P3 instances are brought together, each to be able to talk about the differences it has with the others. This will include not only the changes to the data and the scripts, but also any changes to the internal scripts etc.
Easy customization: All customizations should be easy to track, package, distribute and incorporate. However, all changes should necessarily be in accordance with the guidelines above.
does it make sense?