To order Alpha Four or Alpha Five, click above to go directly to Alpha, or call 800.451.1018 or 781.229.4500
|
|
|
|
|
|
Tuesday, October 1, 2002
|
|
VOLUME 1
ISSUE 8
|
|
|
|
|  |
|
|
An Interview with Selwyn Rabins
by Jim Chapman
Preface
Selwyn Rabins has also consented to a follow-up question and answer interview, where the questions come from you. If you have questions for Selwyn, please send them to me at jc@cknet.net. Please put "Selwyn Questions" in the subject box. I will compile them and forward these on to Selwyn.
I would like to preface this interview by explaining the context. I am an Xbasic junkie. I have to have either Xbasic or coffee to keep me up at nights. Either will do fine. I asked Selwyn to give us this interview on the subjects of Xbasic, Xdialog, and some of the other new technologies being offered to us in Alpha Five version 5 and beyond. Even though the subject matter is 'techie' in nature the true thrust of Alpha Software's philosophy comes through loud and clear. I want to quote two statements that Selwyn makes in this interview;
"The ironic aspect of Alpha Five going forward is that the more powerful we make Xbasic, the less reason there is for many users to learn it! That's because the increasing power of Xbasic makes it easier for us to develop genies that do the work for you.." and "The Alpha Five model is to make the complex simple.".
Don't let technology get in the way of creating powerful solutions to everyday problems. Solve them with Alpha Five!
Q: Selwyn, you have just released the latest version of Alpha Five, version 5. You are not new to rolling out new software programs but my guess is that this time is a little special.
In the 20 years or so that I have been interested in Database software, we have done a lot of different product releases. We started with DBMII, then Alpha/three, then Alpha Four, and then Alpha Five. However, you are right, V5 is quite special for me. It is the first time that I have been so involved in the coding of the product. I have really enjoyed being able to add some of the new features to V5 myself. But of course, in a product as large as Alpha Five, it always has to be a team effort, and we have a great team working on Alpha Five.
Q: From my perspective, version 5 is a tremendous product and it appears that it has been well received. You have been releasing updates almost on a weekly basis, fixing some minor bugs and adding even more new features. From your perspective, how has this rollout gone?
I think the rollout has gone well. It's been hectic because when a user tries to run an existing application that has worked fine in V4.5 and they find some incompatibility in V5, we understand that they are, quite naturally, a little disappointed. So, we have tried to respond as quickly as possible to these issues, and we have been releasing frequent patches. I think it is fair to say, however, that the vast majority of applications have converted to V5 without a hitch, and we have been very pleased with that.
Q: Take us back a little in time to Alpha Five version 1. Alpha Four was an extremely well thought of program in the DOS world, but with the Windows handwriting on the wall you choose to break with the look and feel of Alpha Four in creating Alpha Five. Can you tell us about that decision and the resulting version 1 of Alpha Five?
Alpha Four was designed for the DOS world, which is a very 'modal' world. You work on one thing at a time. You can't let your thoughts get interrupted, leave the task that you are working on, do something else, and then return to the task that you just left. The Windows world is very different. The whole paradigm of Windows software demands multi-tasking. We felt that we had to design a product for Windows that would feel like a Windows product. We felt that if we created "Alpha Four for Windows" we would have ended up with a product that felt alien in the Windows world.
We also felt that a programming language was essential to the long-term success of a product. Alpha Four did not have a programming language. It has keyboard macros, which were very easy to use because you could just record your keystrokes. But keyboard macros are hard to read when you want to edit a script. And they are very fragile. Make a change to the user interface of a product, and the macros all break. So we felt that it was essential that Alpha Five be based on a solid programming language.
Q: In Alpha Five version 1 we had our first view of Xbasic. What were you trying to do with Xbasic in version 1?
Well, Xbasic in Version 1 was not a bad first attempt at a language. It was pretty good for manipulating data (i.e. reading records, updating values in records etc.), but it was not that good at manipulating the objects in the Alpha Five user interface. Nevertheless, there are a lot of very impressive applications that were developed in V1.
Q: Windows 3.x was basically an interim solution and it was not long until the 32 bit Windows 95 was released, and Alpha Software released Alpha Five version 2, the beginning of a line that leads directly to version 5. Although similar to version 1, there was a paradigm shift with the release of version 2. Did you have in mind the product that version 2 would eventually grow into?
The shift to Windows 95 was a difficult transition for us. We had just gone through a huge transition from DOS to Windows, and then another large effort was required to convert Alpha Five from 16 bit to 32 bit code. This was a costly transition for us because we had to devote so much programming effort to a conversion that did not result in any real new end user features.
Q: Version 2 was initially released without Xbasic exposed to the end user. What was your thinking here?
Frankly, we were just being pragmatic. We needed to release a 32 bit version, and did not have Xbasic complete yet.
Q: When version 3 was released we began to see the real power of Xbasic with many new features and a syntactical shift from version 1. Can you tell us about this maturation of Xbasic with version 3?
I was not really happy with the syntax used by Xbasic in V1. It was not object based, and it was much too easy to make syntax errors. I did not think that V1's syntax was easy to understand. Also, it really did not fit the modern style of languages. In V3 we introduced a syntax that was based on objects, methods and properties. This syntax has been the basis of Xbasic since then, and it has served us increasingly well.
Q: That brings us up to Alpha Five version 4. With this release we saw a maturation and refinement of Alpha Five in general and of Xbasic in particular, and with the release of version 4.5 Alpha Software has a very attractive, inexpensive, 'little brother' to Alpha Five version 5. Do you plan to continue to offer Alpha Five version 4.5 now that you have released version 5?
Yes, we expect to continue to offer V4.5. It will run on a less powerful machine than V5, and it has a lower price point.
Q: That brings us to your currently released Alpha Five version 5. This product, at first glance, is deceptively similar to version 4.5. In fact I'd hazard to guess that virtually all version 4.x knowledge and skills will apply in Alpha Five version 5. But there has been a tremendous, almost unprecedented, addition of features, capabilities and maturity.
That's right. There is a really smooth learning curve going from V4 to V5. We have not really changed any concepts in the product. The paradigm is the same. That being said, some things are quite different, such as the menu and toolbar editors, the script editor, Action Scripting, etc. However, I don't expect that any users who come to V5 from V4 will have any real learning curve adopting to these new features.
Q: I've got to ask, with what you had in mind for version 5, did you ever contemplate wiping the slate clean, so to speak, and starting new again with a paradigm shift between version 4 and version 5?
No, we never considered this at all. We want to make sure that as we move Alpha Five forward, the considerable investment that users have made in building their applications is preserved.
Q: One hates to continue to pile on the superlatives, but with Alpha Five version 5 we see a mind boggling number of new features and capabilities. The most exciting for me is the extension of Xbasic including the addition of Xdialog. Alpha Five is written in C++ is it not?
The Alpha Five DLLs and EXE files are written in C, but a large part of the user interface (i.e. the parts of Alpha Five that users interact with) are actually written in Xbasic and Xdialog. Xdialog is an extension of Xbasic. Xdialog allows one to create dialog boxes extremely quickly compared with coding them in C.
Xdialog is interesting. It was really added for our internal use in developing V5. There are a huge number of dialog boxes that users interact with when using Alpha Five. For example, Action Scripting alone has hundreds of dialog boxes. Other features, such as Query Genie, spell checking, Field Properties, View Settings, etc. all present the users with a series of dialog boxes. We came to the conclusion that if we wanted to create all of these dialog boxes as we had in the past (i.e. coding them in C), that we would not have the resources to get the job done. So we needed to invent a better, quicker way to code the user interface elements in V5. Xdialog came out of that. Initially we were not sure that we would even expose Xdialog to end users. However, while I believe that only a few users will need to use Xdialog, and while the Xdialog syntax can be tricky, it is a fantastically powerful tool. Mastering it is really not hard, and it will give developers the ability to create highly customized user interfaces to their applications.
Q: So originally, Xdialog was intended as a tool for you to develop Alpha Five with. When did you decide to offer Xdialog to the end users of Alpha Five?
I have been so impressed with what can be done using Xdialog that it seemed that it would be crazy not to at least tell end users about it. The fact is that I think that most users will be able to do everything they need without ever cracking the "Introduction to Xdialog Book". But for those adventurous souls, Xdialog is fun and well worth learning. I should mention here that there is an Action Scripting Genie for creating Xdialog boxes, so knowledge of Xdialog is not required to create sophisticated dialog screens.
Q: In the past versions of Alpha Five, you had chosen to use MFC (Microsoft Foundation Classes) a product designed to speed up development time in Microsoft's C++. This also created some problems for you did it not?
We had some problems in V4 and prior version with menus and toolbars, and we could not solve the problems because the problem existed in a MFC library. This was frustrating to us. We still rely on MFC to a small extent in V5, but the areas where we had the most trouble, menus and toolbars, have been completely rewritten so that we don't use MFC.
Q: Xbasic and Xdialog are scripting or interpreted languages as compared to C++, which is a compiled language. Generally speaking interpreted languages are slower to execute than compiled code. Is this a concern as you continue to develop new features of Alpha Five with Xbasic?
Not really. We use the appropriate language for the task. A dialog box spends most of its time waiting for end user input. So Xdialog is more than fast enough.
However, the code to display a form, or to index, a table is written in C.
Many of the new functions in the Xbasic language are written in Xbasic. However, if we find that a function executes too slowly, then we just convert it to C.
Q: Selwyn, this has all been preamble to what I REALLY want to ask you. With all the wonderful new features of version 5, I'm wondering if we can't see the forest for the trees. With the incredible extensions to Xbasic that we see in version 5, Xbasic has become a full featured, powerful, easy to use language. A 'product' in and of itself. Can you pull back the curtains a little for us and help us understand what this means for the future of Alpha Five and the world of Alpha Five users and developers?
Xbasic has matured fantastically in V5. It now has extremely strong string handling features and array features. Xbasic will play an increasingly important role in our product development going forward. Currently a lot of the things that are done "internally" in Alpha Five are written in C, and don't go through an Xbasic layer. Eventually everything that Alpha Five does will go though an Xbasic layer.
Let me try to make this a little clearer by an example. Currently, when the user is entering a new record, and gives focus to a field for which a default value field rule been defined, Alpha Five inserts the default value in the field using very low level functions that are written in C. You can't say to Alpha Five, "show me the Xbasic that gets executed when I give focus to the field and a default value is inserted". But eventually, you will be able to "peek behind the scenes" for virtually every Alpha Five action, and see what Xbasic Alpha Five is executing.
I think that characterizing Xbasic as "product in and of itself" is an interesting way of thinking about Xbasic. We have not chosen to position Xbasic like this at this point, but it certainly is a possibility for the future.
Q: The new Addin technology of version 5 has not received much mention to date, yet this is one of the most exciting new features that we are offered. Can you tell us a little about Addin technology and how you envision it being used?
At this point we have not really exposed the Addin technology as an end user feature. Of course, it is tremendously important to us internally because as I mentioned earlier, a significant part of V5 has been developed using Xbasic and Xdialog in the form of "addins". The fact that these features are supplied as "addins", as opposed to having been developed in C is totally transparent to the user.
If you look at the size of the Alpha Five .EXE and .DLL files for V5, you will see that they have not grown by very much compared to V4.5. However, V5 now has a new file called SYSTEM.AEX. This file contains compiled Xbasic code for the addins.
At some future point we will allow users to create their own addins.
Editors Note
Just before going to 'press' Alpha Software has released the latest Alpha Five version 5 patch that enables and exposes Addin technology to the end user!
Q: Selwyn, would it be accurate to describe the new Addin technology as Alpha Software's proprietary dll's?
In effect, yes.
Q: I don't want to get bogged down in the details of Xbasic, but the new array methods and the brand new Collection objects are welcomed additions. Would I be remiss if I called the new Collection objects super arrays?
The array methods in V5 are extremely powerful. Many array operations that took lines and lines of code in V4.5 have been reduced to a single method. Collections are a special kind of array that are accessed by a key, rather than a numeric index. When Collections were first added to the language, one of their main appeals was that they could grow dynamically. However, we subsequently added this capability to arrays, and so now I find myself doing everything I need using arrays.
Q: We could go on and on talking about such fundamentally important additions such as the new variant type variables, new namespaces capabilities, etc., but I really need to ask you about the 'family' of Alpha Five products. I'm specifically referring to the web server version of Alpha Five and what I'm calling the ADO enabled client version of Alpha Five. Can you tell us about your plans for the web server version of Alpha Five?
The Alpha Five Web Application Server (A5W) will be our next release. An early version of A5W will be going into beta very shortly (possibly by the time you read this, it will already be in beta). This early beta has all of the server technology in place. I.e. Alpha Five can act as an HTTP server and serve up web pages that are written in Xbasic. To use this beta release you will need some rudimentary Xbasic skills.
What we are still working on are the Genies that will allow non-programmers to create database enabled web pages without having to know Xbasic.
We are working on the ADO enabled client version of Alpha Five in parallel. I would hope that we can have a Beta of this version ready within the next 6 to 9 months.
Q: I'm betting that Xbasic is playing a large role in the web server version of Alpha Five. Would that be correct?
That's true. Let me first make something clear about A5W.
One key thing to note about the A5W is that it is both an Application Server, and a Web Server. What does this mean? Well, take a product like Cold Fusion. This is just an Application Server. By itself, Cold Fusion is useless. You need to combine it with a Web Server (such as Apache, or IIS) before it can actually serve up web pages to a client.
IIS or Apache, on the other hand are Web Servers. By themselves, they are useless (in terms of database driven applications). You need to add an Application Servers (such as ASP, or Cold Fusion)
Alpha Five, on the other hand, serves as both a Web Server and an Application Server. Why is this important? In a word, simplicity. The Alpha Five model is to make the complex simple. Configuring separate components from different companies is not easy. Certainly not as easy as right clicking on the Alpha Five control panel and selecting "Start Web Server"!
Now, to answer your question about the role of Xbasic in A5W. It is true that Xbasic plays a huge role in A5W. First of all, when the user creates HTML pages to be displayed by A5W, the page can include Xbasic commands. This is very important. A lot of users have developed strong Xbasic skills in creating their Windows applications. Now they can leverage those Xbasic skills as they move to create Web Applications.
But besides being the language in which users create their Web pages, Xbasic is also the language in which most of A5W is written. Of course some key components are written in C.
The most notable change needed at the C level for A5W is the introduction of a multi-threaded Xbasic. This is a fantastic addition to Xbasic that is going to have benefits throughout Alpha Five. The benefit of multi-threaded Xbasic is that tasks can be run in the background. For example, say that you have a huge, 1,000,000 record table, and you have an Xbasic script that processes each record in this table. Currently, while this script is running, you are locked out from doing anything else. Now, this script can run as a background thread, while you continue to work on other things in the foreground.
The other key new feature that was added to A5W at the C level was the introduction of a "socket" object. This enables A5W to act as an HTTP server and an FTP client.
Q: I for one, have been agitating for command line Xbasic. I'd like to think that the Xbasic programmer could leverage their skills in the writing of CGI (common gateway interface, the programming glue between a web server and data) scripts.
I think that this is a very interesting idea. If we did this then one would be able to write CGI programs using Xbasic to generate web pages in much the same way that one use Perl, or other Web scripting languages. I don't think that it would be difficult to create a command line Xbasic, but it is not on our immediate priority list. That's because the approach we are taking for our Web Enabled version of Alpha Five is to build the HTTP server directly INTO Alpha Five. This keeps things incredibly simple for the end user. There is no need to configure separate Web servers and CGI programs.
Q: That brings us to the ADO client version of Alpha Five. This has got to be one of the more exciting products I can imagine. In my mind it completes the circle. For the small to medium business applications, we have Alpha Five version 5. If we want to serve our data to the web, or just offer real time dynamic web content of any type, we will soon have the web application server version of Alpha Five. And now for the large businesses, with their disparate collections of data, residing in possibly dbf tables, maybe one of the many flavors of SQL data sources, possibly some Access databases, we will have the ADO enabled version of Alpha Five. Allowing use to use the rich and fast development environment of Alpha Five to create clients to any ADO compliant data source. This will open up the entire spectrum of business to the Alpha Five user and developer. Give us some hints, what will the ADO enabled version of Alpha Five look like?
Our goal is to make using the ADO enabled version of Alpha Five as transparent as possible to the user. While Alpha Five will expose all of the ADO methods and properties to the Xbasic user, we don't expect our users to spend much time learning ADO syntax. That's because all of the familiar Xbasic commands like table.open(), .enter_begin() will work the same regardless of whether you are going against a native .dbf table, or a remote table.
The typical Alpha Five user will simply define "views" of the remote data (which Alpha Five will use ADO to connect to), and then they will use these "views" as if they were regular Alpha Five tables.
Q: Where is the role of Xbasic in the ADO enabled version of Alpha Five? Have you, will you, use Xbasic for your low level work of programming the interface between Alpha Five and the ADO data source?
The ADO interface in Alpha Five is programmed in C++. However, all of the ADO objects and methods are exposed to Xbasic. This allows the Xbasic programmer to open an ADO connection and work with it. If you opened a standard book on using ADO in Visual Basic, for example, and looked at the sample code there for working with ADO data sources, you would find that you can use very similar Xbasic syntax.
However, as I said earlier, we don't think that the typical Alpha Five user will want to write Xbasic code that uses the low level ADO object. That's because ADO is pretty complex. Why bother to learn it when the familiar table methods in Alpha Five will all work against remote data?
Q: Can we expect to use the same Alpha Five and Xbasic skills, that are currently used to manipulate Alpha Five's native dbf data sources, to work with non-native ADO compliant data sources?
Yes, for the most part. Obviously some Xbasic methods are very specific to .dbf files, so these methods would not work against an ADO data source.
Q: So this will give tremendous leverage to the Alpha Five user and developer. The ability to use their knowledge while serving data to the desktop, or the web, or the large distributed computing environments of big business. Is this how you envision it?
Yes. We would like to think that as the needs of our customers grow from simple desktop database, to networked desktop applications, to remote Web access to applications, to large applications that go against corporate backend data, Alpha Five will be there for them.
Q: Selwyn, it is becoming increasingly obvious to me that there is more to Xbasic than meets the eye. You have exposed high level functionality to the user of Alpha Five, but there has got to be more below the surface. What are you plans in this area? Will you continue to expose more of Xbasic to the users of your product?
Yes, we will. Xbasic is getting richer all of the time because we are exposing practically every new feature we add to Alpha Five as an Xbasic object that can then be manipulated with its associated methods and properties.
There is one thing I really want to make sure does not get misunderstood. I have spoken a lot here about the importance of Xbasic to the future of Alpha Five. A lot of Alpha Five users don't use Xbasic, and never will. They nevertheless have built powerful applications that meet their needs. I certainly don't want these users to get concerned by this focus on Xbasic. The ironic aspect of Alpha Five going forward is that the more powerful we make Xbasic, the less reason there is for many users to learn it! That's because the increasing power of Xbasic makes it easier for us to develop genies that do the work for you.
I think that Action Scripting is a good example of this. In V5 the entire Action Scripting editor was rewritten in Xbasic. There are now hundreds of actions that you can choose from and many of these actions generate a significant amount of "behind the scenes Xbasic".
Q: The software world is a volatile place. We've seen the consolidation of many software companies and the demise of more than a few stalwart names. Microsoft continues to dominate the desktop to an unprecedented level. We've seen Java, in the not too distant past, touted as the Holy Grail of the software development world. Microsoft brings us C# and .net. Linux continues to hold forth promise for the desktop; IBM gives us "dynamic e-business". Then of course, XML is supposed to bring us all together. And in the midst of this struggle of the giants, Alpha Software Corporation brings Alpha Five version 5 to life. Many of us have tied our wagons tightly to Alpha Software. Selwyn, polish up your crystal ball and tell us where you thing we are going.
Beats me!
The fact of the matter is that these are all buzzwords. They really mean nothing to a customer who is trying to run a business. We are focused at Alpha on creating the tools necessary so that it is possible for our customers to create the applications that they need to automate and run different aspects of their business. We are very customer focused. We are not technology focused. If C#, or Java or C++ were the right tools for our customers, then we wouldn't be in business. But these tools are not right for our customers. That's not to say that C# and .NET are not really great products. They are. But they are aimed as MIS professionals. Those are not our customers.
[PRINTER FRIENDLY VERSION]
|
|
| |