Ex Base

ExBase is a Wiki-friendly re-wording for "XBase", which is a general term for languages and tools derived from the Ashton Tate dBASE product, popular in the 1980s and early 1990s. Clones include FoxPro, Quicksilver, dbXL, and a compiled dialect called Clipper (which spawned XbasePlusPlus, FlagShip, and Harbour). XBase originated as a table-oriented non-SQL language and tool vaguely influenced by relational theory and (mainly) cursor-oriented table navigation techniques from the 1960s. It was one of the first products that easily allowed small businesses access to database concepts such as ad-hoc queries, indexing, and data-driven CrudScreen RAD when microcomputers were just coming of age. Jim "Button" Knopf's "PC-File" exhibited similar capabilities, albeit with less programmability.

ExBase is kind of the Neil Diamond of programming tools: one tends to either have fond memories of it or nightmares about it, with little in between.

It allegedly has its roots in a legacy database product called RETRIEVE. The Pasadena Jet Propulsion Laboratory, famous for planetary probes, didn't want to pay licensing fees for RETRIEVE and so set out to create something similar. In a round-about way, it eventually wound up a commercial product for CPM microcomputers, and grew quite popular in the DOS world. Much of the history of the product was discovered during court testimony related to lawsuits by Ashton Tate to prevent clones of the product/tool. It turned out that Ashton Tate's view of history was not entirely accurate, and the history of ExBase was deeper than their original story. The judge eventually tossed the case, but the damage caused by the risk of legal claims on the language hurt the ExBase industry.

Its demise in popularity has been attributed to one or more of the following:

Other products such as Visual Basic, Microsoft Access, Paradox, and PowerBuilder eventually replaced its niche. Some feel the XBase vendors should have expanded on its table-oriented nature and used ControlTables for event handling and GUI properties rather than try to copy OOP techniques popular in other GUI tools. An opportunity to go down a unique path was allegedly lost, and instead they tried to be a me-too product in an arena that was too different from the root table-oriented philosophy of the tool. You can turn a leopard into a tiger, but not into a gazelle. (FoxPro and VisualFoxPro actually use ControlTables for many GUI aspects, but it is generally an UndocumentedFeature.)

The language gives one the feel of being "inside" database tables. It is heavily context-based because of its interactive origins. The plus side of being context-based is that less code is usually needed to indicate what is being operated on, and it made it easy to learn and debug using the interactive mode. The downside is that if not used carefully in longer modules, it can cause great confusion and scoping surprises.

An interesting feature is that iteration over a table was built into the language. A general form of the syntax is: 

  do_x             // operate on current record
  do_x all         // operate on all records
  do_x for <expression>  // operate on records matching a "filter" expression
(Actually "&&" is used for comments instead of slashes, but that might confuse the reader here. Also, not all dialects allowed such on user-defined routines, but only built-in ones.)

It's essentially a MapFunction with predicate filtering (similar to an SQL "WHERE" clause).

So ExBase supports a form of HigherOrderFunction. Top, I'm surprised you're so opposed to them. Or are you opposed to this facility for the same reasons?

If you needed the same filter on multiple operations, then FoxPro and some other dialects introduced the "scan" construct: 

  scan for <expression>
    do_something
    do_something_2
  endscan
One could also apply a filter for multiple statements: 

  use <table>    // open a table
  set filter to <expression>
  do_something
  do_something_2
  scan
    do_something_3
  endscan
  etc...
  set filter to     // turn off filter (empty expression)
Some might consider this approach inferior to "scope blocks" or closures of some kind because blocking would guarantee that the filter does not accidently "stay on" if we forgot to close it, but the XBase approach allows more interaction. You could use the same commands in interactive mode that you could in the programming code. Thus, with some copy-and-paste one could create a module out of their interactive session with only minor tweaks. One could also use a coded module to set up the environment, but then switch to interactive mode from that point on. That would be harder to do with scoped blocks because one must know the end-point ahead of time.

Another advantage of this is that you can do preliminary set up, such as set a table filter to be viewing a subset of a table, and then "dump" the control back into interactive mode (dot prompt) with such settings left "on". This allows mixing of scripts and interactive behavior. Formal closures may not like that because closing would need to be defined or verified up front. Sometimes you want the machine to start the sandwich, but manually finish it (or mix and match sub-scripts manually). It facilitates semi-automation.

Early dialects required a fair amount of work managing indexes, but later dialects moved toward more automatic approaches where indexes were automatically opened and updated when a given table was opened or updated. Unfortunately, the newer approaches were not standardized. Generally the dBASE III+ dialect was probably the final version influencing a universal dialect. They diverged after that (although there was still some cross-borrowing). Thus, if one wanted to target multiple dialects, they usually stuck to III+ conventions.

Although many aspects of the language and tools are clunky, it has some interesting features that are hard to find in SQL-based tools. Many still consider it an excellent ad-hoc data transformation tool because it is usually easier to inspect intermediate steps and do incremental experiments with than with SQL tools. SQL has a more "batch" philosophy behind it.

Format Template Strings

One thing about ExBase that greatly simplifies writing the validation in CrudScreen applications is its format template strings. You didn't have to write a whole lot of validation code because the format string would guarantee the user entered only what the format would allow. For example, a phone number format template would look something like: 

   "(999)999-9999 \xAAAAA"
Here "9" is for digits and "A" is any alpha-numeric char. The "\x" escapes the "x" for phone extension since "X" was also a formatting character. (The specifics may not be entirely accurate here, I don't remember the details.)

The templates appear to be roughly borrowed from Cobol's character templates. The Xbase cursor would not produce a character that was not allowed in a given position. Thus, if you typed a letter where a digit was expected, the cursor simply would not move (and beep or have custom handlers in some dialects). The "marker" characters, such as the parentheses in the phone number helped the user know where to type. The cursor automatically skipped over the marker characters.

It is one of those intuitive, useful, and life-simplifying features that you really miss when you have to do it the hard way. I hope AjAx adopts them. Swing has added "JFormatted'TextField" that allegedly does something similar. Superficially it looks kind of limited.

Don't you mean CSS/HTML instead of AjAx? AjAx is an approach to developing Web applications that reduces page loads by (re)loading specific page elements rather than the whole page. What you want would have to be a feature of CSS/HTML, though it could be created in Javascript.

Pros 

         && Loop and Update Example
         USE tableX
         SCAN FOR &myFilterCriteria
            IF x > y AND replacable
               REPLACE x WITH y
            ENDIF
            IF a + b < c
               REPLACE message WITH "Low"
            ENDIF
         ENDSCAN
Cons

What ExBase Taught Me:

--top

If anybody knows of a decent open-source interpretive ExBase, I'd be glad to get my hands on it. I really really miss ExBase for ad-hoc processing and "self" scripting.

Even Harbour (see http://harbour.github.io/), an ExBase compiler that came as close as anything to sustaining ExBase in OpenSource form, seems to have gone dead. Maybe you could build it?

Links

Appreciation site: http://www.geocities.com/tablizer/xbasefan.htm

Interview with creator: http://reddevnews.com/qandas/article.aspx?editorialsid=113

Wayne C. Ratliff on dBASE's origins: http://www.accessmylibrary.com/coms2/summary_0286-9229460_ITM (An interesting read for anybody wanting to start a company.)

See Also: CollectionOrientedProgramming, PowerfulAdHocDataProcessingTools, ModernizingExBase, ExBaseRant, XbaseLibrary

CategoryOldSoftware, CategorySoftwareTool, CategoryDatabase, CategoryScripting, CategoryClosure (reasons not to)

EditText of this page (last edited November 25, 2014) or FindPage with title or text search