What is Exodus

What is Exodus?

Exodus is a way to do traditional pick-basic programming in C++.

It was conceived and created as a way to move classic pick/multivalue basic into a classic industry standard environment with the minimum of upheaval.

Many people would like to migrate their classic pick/mv based applications into industry standard environments however they have so much code that relies on the nuances of pick/mv, or their programmers are so used to pick-basic, that it is virtually impossible to move.

Exodus is released under the MIT licence so you can use it in closed source projects without fee.

It is a Database or a Language?

EITHER OR BOTH!

You can use Exodus for:

Pick-style Programming (requires a C++ compiler)

OR

Pick-style Database Use/Management (requires a Postgres Database)

OR

Both together

You can do Exodus Pick-style Programming WITHOUT having or using a database and you can use Exodus command line utilities to do have a Pick-style Database without having a C++ compiler.

Twin Issues

Exodus provides replacements for both language and storage but each part could be very valuable to add sql storage to an existing pick language or a language to an existing pick database.

Language Replacement

Use C++'s operator overloading feature to make C++ behave almost like, if not exactly look like, pick-basic programmers expect and be usable for classic pick-basic style application programming.

Database Replacement

Use standard SQL databases (currently Postgres) transparently as a pick style storage mechanism ensuring full SORT/SELECT functionality including dictionary items (columns) that invoke routines written in the pick-basic style CC++ environment.

Twin syntaxes

Classic Pick "Global function" style syntax

print(oconv(extract(xyz,1,2,3),"MD20")));

This is standard Exodus C++ syntax. Only the representation of print as function "print()" instead of a command "print x", - and the trailing ; gives it away as C++.

Pick programmers are used to this syntax and many will want to stay with this style for whatever reason.

It is a pity that C++ syntax doesnt allow the easy-to-write and easy-to-read pick-like array extract/replace like xxx<1,2,3> or x<3>="x". A great shame but not a killer.

Classic OO "Method Chaining" syntax

xyz(1,2,3).oconv("MD20").print();

or if you prefer ...

xyz.extract(1,2,3).oconv("MD20").print();

This is standard Exodus C++ code.

Variable xyz is one of Exodus' "var" objects and xyz(1,2,3) does an "extract" ... which just produces another var object which is then processed by the oconv method and then printed.

What this actually does is: From variable xyz, extract field 1, multivalue 2, subvalue 3 then oconv it, then print it.

More C++ish style is also acceptable:

cout<<xyz(1,2,3).oconv("MD20");

So a "pick variable" object (or class) Mv has all the various pick functions as methods. This means that you can use OO-like method chaining syntax. This is often the way people think in OO languages. In OO it is considered easier to understand code if you can simply read from left to right and it gives you the operations in the order that they are performed. As much as some people may not like OO method syntax, the many more people today are more comfortable with it than global function style.

Why not just Python or PHP?

Both of these are great languages to start new projects and many people using Pick language will have looked at the possibilities of porting to them.

However there are many subtle differences between the languages and, if you have thousands of lines of old code you dont have time to sort out all the subtle bugs without a complete rewrite with a programmer familiar with the intricacies of both languages.

Generally the objective is to convert often hundreds of thousands of lines of pick basic fairly accurately into another language. Changing syntax is laborious - but doesnt require highly skilled programmers. However any subtle changes in semantics (how operators and functions work exactly) means that ports are unreliable which is far more costly.

This means that the syntax can be changed when porting as long as not too bad then we will all get used to the new syntax. It also means that the sematics must remain almost identical otherwise people will be hunting down bugs forever. Anybody who has looked at replacing pick will have come to the same conclusion. porting needs meticulous rewriting into the new language mentality due to nuances in how the basic principles of how variables behave.

Python and PHP operators and variables just dont BEHAVE like pick operators and variables in too many cases.

Unpredictable overloading

Most modern dynamically typed languages suffer from the catastrophically inappropriate carry over of the concept of operator overload from statically typed languages. This means that you cannot trust what operators like + and * will actually do. Pick-basic, although dynamically typed, does not suffer from this. Pick's + will always do an arithmetic plus and fail if non-numeric strings are presented to it. Pick's * will always do an arithmetic multiply and fail if non-numeric strings are presented to it.

You just cannot trust dynamically typed languages that do operator overloading based on dynamic type. Accidents waiting to happen and frequently do.

Example PHP problems

This is a very tiny list of all the problems that exist. By problem we mean difference in way of processing, not that one way is wrong or right.

PHP * operator

If you give it a variable that happens to contain a string then, instead of converting it to a number to multiply numerically, it will repeat the string n times! This is fine for php people who are used to it ... but cause chaos when converting and maintaining pick code in php.

"100"*10 in php is "100100100100100100100100100100"

of course it isnt written as "100"*10 in code .. it is written as mynumber*10 ... BUT what happens depends on what data type happens to be in mynumber during execution

PHP . operator (concatenation)

It is very astute of PHP to have a special concat operator even if it does seem almost impossible to read to pickies used to a : for concat. Most other languages dont have proper concat operator at all. But then from the point of view of Pick-basic it has the wrong precedence.

php's concat operator (the dot) has the same precedence as + and - whereas in Pick, concat has a lower precendence than the arithmetic operators. This subtle difference introduces endless opportunity for hard to track down bugs if you try to simply translate large amounts of code from pick-basic to php.

Lack of GOTO

This makes porting of some existing pick-style programs very difficult (requiring refactoring with consequent risk of bugs). C++ has the GOTO statement.

Concat operator

The ability to concat variables in precisely the same way as pick does is very important if you are going to move pick applications into any other language.

eg in pick if you concat two variables that happen to be numbers - using the pick ":" operator you will still get a string out. ie concat in pick means concat. it DOESNT means add if the arguments happen to be numeric. the concat operator missing in c++ because it is strongly typed and it (and you) can tell from arguments whether it will add or concat

in exodus, "variables" are a c++ class that behaves like a pick variable very very closely so you can port pick basic without being nervous of subtle bugs due to differences in mentality of the other language designers.

Why Postgres?

Open source and technically very open and easy to extend with new datatypes etc.

Postgres is widely available and well supported on all major platform. There has been very strong interest in and development of Postgres since Oracle bought up the MySQL's underlying database.

Postgres licence in BSD so can be used in anyway you like whatsoever including using bits of the source code in your own code without GPL restrictions.

There is a draft driver to use OpenQM instead of Postgres.

Why Boost?

Best of breed and is the prime place that C++ standards are worked out.

Portability

Written in standard C++. Currently builds with GNU gcc and MSVC 2005+