Thursday, February 10, 2005

Building Systems in BASIC

Let say you want to write a program in BASIC that manages sales information for a small store. You need to write code for the following things:

- Data entry+User Interface
- Database management
- Reporting
- Graphing

Okay, fine. You create a program called salesmanager.bas and create sections of code for each subsystem. As you build your library of code, you run your program to try it out. When you're done trying out your program, you shut it down and go back to writing more code. Then you try your program again, etc.

This is the traditional way to create programs, and it works great for small programs. When a program gets large, it takes longer and longer to start up the program and try it out.

What if your BASIC could *also* do it in the following way?

- Create a program called salesdatabase.bas and write the simplest possible database manager (one that doesn't really do anything). Start it up and give it a runtime name SALESDB. Leave it running.

- Now create another program called salesui.bas that implements the simplest GUI. Start that up and leave it running.

- Write a function to salesdatabase.bas for adding a new sale and save it. It becomes available to the salesdatabase.bas program that is already running!

- Now add a menu and subroutine to open a simple dialog box for the salesui.bas program. This dialog box code contains a call to the add sale subroutine on the SALESDB program. Without restarting the GUI, the menu is available. You can test it immediately!

Keep adding more code to these programs and 'grow' them a little at a time. Add the reporting and graphing modules to your system in the same incremental way. You can build a large system in this way by 'growing' it in little bite sized ways.


Rogue said...

i understand that is similar to an oop system, a seperate progs. it would be nice if the "token" inturpreter could be used to do such a thing. such as writing and tokenizeing all those programs with the UI as the main EXE?
i know i bother you with these weird things, but its my nature, thanks for putting up with me.

Carl Gundel said...

Hey Rogue,

You could compare the separate running programs to objects, if you like. :-)

The prototype we are working on that allows the sorts of things (and more) that I described in my post does not have a token interpreter, and does not need one.