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?

- ravi

Personal Programming

This is an idea that has intrigued me for some time. It came to me when I was thinking about doing something to automate my website. It is a pure-html site, and I wanted to do some kind of automation of updation of links of each page when a particular page was altered. A very obvious means would be to use a "content management software". But I was too lazy to search for one that fit my bill. Because my requirement was simple, change a links in each page automatically. Something along the lines of a simple perl hack, rather than anything else.

I am not averse to computing, but at the same time I am lazy. Perl is made for me, but then there are some deficiencies for my purpose. Perl promotes laziness, but after it is up and running. I want something that promotes laziness _always_.

And it should be non intrusive. It should be intelligent. And it should keep everything with it and not make me think. And it should be portable. I will try to come up with a wishlist in the next blog. Do you know anything that provides such a platform?

Anyways, forward the requirements,

- ravi

Context Sandbox

This came to me when I saw some students carrying their CPUs to the presentation for a course. There is this course we have. Dealing with databases. And for that course the students have to do a project - a program. The platform could be anything, as long as it used databases for functioning - ASP, VB, VC++ whatever. And at the end of the term, the students taking that course have to make a presentation.

For the presentation, the students had to carry their CPUs to the professor. Why? Well basically, the architecture for the project required the students to connect to a remote database. And this was generally a painful process, considering that we are not doing Computer Science here, and most of the times, a final connection is establised through a lot of trial and error. By the time a connection is established and a connection string is finalized, a number of changes would have been done to the system that the student is working on, and the student would not be in a position to replicate the same on another machine.

Thus, this database project used to fail regularly, if the student just carried around the program as code, or as the executable (remember the DAOs and ADOs required were part of the OS) or in any other format. This almost forced the program to run only on the machine it has been written to run in. Thus we saw people carrying CPUs to and fro the prof's room for the presentation. The idea was that the all that needed to be added was power, and the program would run.

What do we have as part of a computer system. An application and data. Right? Wrong. There is also a context. The context is the executing environment of the application. Now in modern computing, this context is defined by the OS to an extent. And the context is realised by .dlls, APIs etc. The idea being that those entities not inherent to a particular application should be outsourced and be maintained by another party, or the OS. But look carefully, there are a lot of cases when third party tools are installed only for a particular program.

Lets look at some examples from the Windows world. Plugins into programs are one such set. Say Photoshop plugins, or Internet Explorer plugins, or Acrobat Reader plugins. For most of the scenarios, the application (Acrobat) and the data (.pdf file) alone would constitute the complete context. But for say some other scenarios, the plugin would also be a part of the context. Without it, having both the application and the data would be effectively useless.

Lets look at another example. Codecs. Say you have an AVI file. An AVI file normally can encode its video and audio streams in different formats and the application requires codecs to understand the two streams. Now what good is a great movie (data) on your machine (media player) without the Codec.

The above examples illustrate the need for an execution context in addition to the application and the data. Now lets look at what a context sandbox is.

A context sandbox is that minimum amount of information which will allow an action to be performed on a secondary machine, when the action is currently being performed as such on a primary machine.

There are some qualifications to be stated here:

1. It is assumed that the primary and secondary machines are fundamentally capable of performing the action. In other words no definable context sandbox can exist for your washine machine to play your favourite movie.
2. Information will be assumed to mean only that relating to software. Software will also be loosely defined as a sum of data and instructions. This means that information such as "Go get a life, buy another mp3 player" is not a context sandbox for a primary machine which is an mp3 player.
3. Quality of performance is not an issue we will be dealing with here. Fundamental capability does not promise quality of performance.
4. A machine is defined as the sum of all units that allow performance of a particular task. This includes hardware, software and any other environmental issues including power, temparature etc.
5. Performance "as such" implies without change to the machine. Of course the machine being as described above.

So that is the idea. We will look more into ramifications of it in future posts.

Watched Memento today. Really kewl movie. This is the second time. Nothing new was learnt, but spent some time on the nuances of the amount of overlap the screenplay writer allowed between the scenes. Really well thought out.

~!nrk