Q: Cian, if I take my oldest Alpha Software manual off the shelf and turn to the credits page, I will find your name. You have been with Alpha Software for quite some time now. Can you tell us how long?

My first project with Alpha was AlphaWorks which was released in 1988, So I have been involved with Alpha for close to 15 years.

Q: How did you and Alpha Software come together?

I grew up around Ithaca, New York. I eventually ended up working for an Ithaca based software company called Electric Software, which exclusively licensed electric desk to Alpha Software (and which later became known as AlphaWorks).

Q: Can you tell us how you first got involved in software development?

My first experience with programming was in high school with an Apple II. First I learned the basic interpreter, then I proceeded to learn how to program in assembly language. My main interest then was writing games. Programming remained just a hobby until I started work with an Electrical contractor maintaining their network of 3B1 workstations. I then learned to program in-house database applications in C with an ISAM manager called C-Tree. So, my first job involved developing databases.

Q: Selwyn Rabins, co-owner of Alpha Software Inc., introduced you at the last Alpha Five Developers Conference as being 'absolutely incredible with the C language' or words to that effect. My impression is that you are the main 'behind the scenes guy', coding in C/C++ to make Alpha Four and Alpha Five jump through hoops. Would that assessment be correct?

Yes, I maintain most of the C/C++ code.

Q: Can you tell us a little about the environment you work in while developing Alpha Five, ie: I understand that you are networked via a WAN to the other Alpha developers and Alpha Software's Headquarters.

I do builds on machines at Alpha from my home office. I have several net meetings a day, including, on occasion, remotely debugging Alpha Five on machines at Alpha Software Inc. headquarters, if I cannot reproduce the problem here. It really is like being there. I don't know what I would do without the internet.

Q: What kind of computers and operating systems do you have up and running to test, debug, and evaluate Alpha Five as you work?

I have pretty much everything: Windows NT 4.0, Windows 2000 , Windows XP , Windows 98, Windows Millennium. I have everything from Pentium II through Pentium 4, Celerons, and even an AMD based machine.

Q: Do you have a favorite Windows version?

Currently XP is my favorite and here is why. I have always liked NT based windows and hated Win9X, but windows9X continued to live on. Windows 2000 was supposed to be the NT branch that represented the end of the line for Win9X, but then Millenium comes out. Now I think that XP actually stands a chance of NT overtaking Win9X, especially since most of the new PC's I see are XP based.

Q: I understand that Alpha Five is coded in C and C++, with many of the new enhancements being added via Xbasic and its extension, Xdialog. You are the developer of Xbasic, are you not?

Alpha Five is coded mostly in C, although lots of the new code is written in C++. The original author of XBasic was Doug Ross who developed Xbasic in version 1.0 of Alpha Five. I have been developing and extending Xbasic since version 2.0 of Alpha Five. I completely rewrote the expression parser and have added lots of new language constructs and capabilities.

This gets into another area I would like to talk about - languages, and in particular appropriateness of a computer language to the task. While C/C++ work well for lots of tasks, and for some tasks are the best way to go, there are many times when a task is better solved in an interpreted language like Xbasic. This realization, that we could use our own language to implement much of Alpha Five, has led to great productivity gains.

Q: When you speak of productivity gains, I know that much of the new UI (User Interface) features of version 5 are being developed with Xdialog, as well as many of the Alpha Five WAS features, but are there other areas where Xbasic is playing a major role in extending Alpha Five?

More than anything else, the gains have been in the UI (User Interface), but the UI is a really big part of ALPHA FIVE. In fact, I believe that people buy ALPHA FIVE because of its UI. We are planning to rewrite the field rules in Xbasic, which should allow for easy extension of the field rules (read field rules that are more specific to solving specific Alpha Five developer problems), but this is a focus of version 6.0. Eventually it is our goal to make persistent storage of forms, browses, and reports, Xbasic scripts. But that again is a focus of version 6.0.

Q: In a recent interview with Selwyn Rabins, we spoke quite a bit about Xbasic and Xdialog, and I have been busy trying to get up to speed with Xdialog. Xdialog has an incredibly concise syntax, composed of some 'special' symbols, ie: such as #,^,{},[], etc. It is almost unbelievable what can be done with a few lines of Xdialog code. Is the Xdialog syntax patterned after another language, and can you tell us why you approached the syntax this way?

The Xdialog syntax actually fell out of how we wrote user interface changes. Since I am remote, and email has been the most convenient form of communication, when Selwyn requested a new dialog box or a change to an existing one, I would first send him an ASCII representation of what the dialog would look like. To denote buttons, I used <> characters, and I enclosed field controls in [] characters. The mono spaced character 'pictures' of dialogs would look enough like the dialog box that a couple emails back and forth could hash out how a dialog would look before I sat down to code it in C. It is these 'pictures' that became the basis for the Xdialog syntax, which originally only supported buttons and fields. Combo boxes, list boxes, tree controls, conditional areas, and tabs, all came later, and broke with the faux 'WYSIWYG' nature of the initial syntax in the interest of supporting more complex controls.

One aspect of Xdialog that I really like is the fact that you can do a lot without writing a line of event handling code - population is automatic - and control enabled expressions can be done without events. I have always preferred offering users a passive programming approach (like a spreadsheet) to an approach that requires users to think about trapping events.

Q: Cian, can you explain what you mean by 'passive programming approach'?

By passive, I mean that the application developer can describe what the relation between data is without having to concern themselves with how it is maintained. Here is an example. An application developer wants to have a field whose value is the sum of two other fields. They define a calculated field for this whose expression is the sum of the two other fields. The application developer doesn't care about all the events that can lead to the field's value changing, i.e. one of the fields being edited, or a new record being navigated to, just that the value in the calculated field is always accurate with respect to the fields it depends on.

Q: Xbasic is a scripting language, so I would assume that much of your work involves the Xbasic interpreter. What kind of process goes on when Xbasic is interpreted, ie: is it interpreted into C code, then executed?

Xbasic expressions are converted internally to something called a RP-stack. RP stands for 'reverse polish' notation. RP is the model for languages, such as Forth, and Postscript, and is used by spreadsheets to store their formulas. The RP stack is simply a list of function pointers, so, while not being 'compiled' as a C program would be, it is very efficient.

Q: Is RP different in concept from Visual Basic and its 'P' code or Java's 'byte' code?

The RP is very similar to byte code. In fact most P-Code and byte code uses RP to order operations.

Q: Alpha Five version 5 now has support for ActiveX objects. Can you tell us a little about ActiveX and how it relates to Alpha Five?

First, I would like to comment on our ActiveX support in Alpha Five. Version 5.0 represents our first foray into ActiveX support and has a number of rough edges. First, constant and enumeration support is completely missing, requiring the programmer to use constants. The workaround is to hard-code the values, which is always a bad idea since it leads to difficulty in reading, maintain and possibly coding. Second, I find our Auto-complete support to be lacking as well. In version 5.0 it only worked from the interactive window. Fortunately, we are addressing all these shortcomings in version 5.1. We believe that solid ActiveX support is critical to Alpha Five. We are using ActiveX Xbasic code in our own addins to link to third party libraries and controls.

Q: There is a vast amount of 3rd party ActiveX controls available. How much of these should work 'out of the box' with Alpha Five version 5?

While I would like to say 99.9%, it is probably closer to 50% when you start using all the features. Even though all ActiveX controls can be inserted, we have found problems with using certain features of ActiveX. Version 5.1 has a number of fixes (in particular, support for user defined types). Adding ActiveX support has been an iterative process.

Q: Alpha Five version 5 supports the new Addin technology. This will allow the savvy end user or developer to add in custom functionality to Alpha Five. Can you explain how this is different from just creating a Xbasic script to add the functionality, and how do you see the Addin capabilities being used by the Alpha community?

It is my hope that our users will build on top of our Addin technology. The advantage of Addins is that it can be available for every database the user opens that is integrated into the UI. The first application that comes to mind is Bill Parker's new documenter for Alpha Five. But I see the potential for all sorts of a new tools to make building specific applications and scripts easier. Here are some examples of what addins could provide:

1. An Alpha Five user creates a script that converts an arbitrary table to an XML data file. By converting the script to an addin they can add the option to the table context menu. This allows the user to convert any table to an XML file simply by selecting a Menu Item.
2. An Alpha Five user writes an addin that generates an Xdialog script that simulates the functionality of cardstacks without any programming. The addin exists on the code page context menu.

• This calls Xbasic addin event, events.browse.OnScrollRow(), with a pointer to the browse and the new scrollbar position as arguments.

• BeforeBrowseScrolled

• AfterBrowseScrolled

1. It is human readable, so if there is a problem in the stored form, there is a chance of being able to fix it with a text editor.
2. It is easier to send your forms via Email.
3. If a form is simply an Xbasic program, you can tune the program to dynamically generate a form.
4. Since a form is text, it would be easy to perform search/replace operations on a form (i.e. change all wording on all forms). Maybe we could get reconfigure features like Alpha Four had.
5. Because layouts would be just another kind of scripts, It makes it easier to support layouts stored in .ALB files, which in turn means that layouts can be stored in .AEX files.