Why these Different Generations of Programming Languages?

The basic idea is that with each generation of programming language the level of abstraction and the power of each statement in the programming language increases.

• First Generation = Machine Code
• Second Generation = Assembly Language
• Third Generation = “Block Structured” languages such as Pascal
• Fourth Generation = Domain Specific
• Fifth Generation = Constraint specification, knowledge-based translation, dynamic algorithm creation and execution.

The advantage of a 4GPL over a 3GPL is that, for a specific domain, it is easier and quicker to “build a solution” (i.e., write a program that works and solves a problem you want solved) using the 4GPL than using the 3GPL. It is also easier to maintain a 4GPL solution than a 3GPL solution for applications suitable for the 4GPL’s domain.

To write a 4GPL program, you must know the following:

• How to express the problem you want to solve in the 4GPL
• An algorithm for solving the problem
• How to express the algorithm in the 4GPL

5GPLs are also domain specific. As in the comparison between a 4GPL and a 3GPL, it is easier and quicker to “build a solution” to a problem using the 5GPL than the 4GLP. Similarly, it is easier to maintain a 5GPL solution than a 4GPL solution.

There is, however, a significant difference between 5GPLs and 4GPLs. With a 5GPL, you only need to know how to express the problem you want to solve in terms of intuitive domain constraints. The 5GPL determines an algorithm for solving the problem and then implements and executes the algorithm automatically. With EO, no one is ever exposed to, or involved in, the expression or execution of the solution algorithm.

In the case of 4GPL versus 3GPL, it is always correct to say that a program written in the 4GPL can be implemented in a 3GPL – it will simply be more difficult, error prone, and time consuming. In the case of 5GPL versus 4GPL (or 3GPL), it is *NOT* correct to say that every program written in the 5GPL can be implemented in the 4GPL (or 3GPL).

In the case of the 5GPL, the programmer/user does not necessarily know *HOW* to solve the problem being expressed. They only know the problem they want solved. If that same programmer is given a 4GPL (or 3GPL) and told to use it instead, it is not necessarily the case that they can determine an algorithm for solving the problem and then express that algorithm in the 4GPL (or 3GPL).

Putting it Together – Case Example

For the purposes of this example, I’ll refer to the Enterprise Optimizer (EO), SAS, and Fortran programming languages.

Fortran – is an enormously popular 3GPL. Fortran (“Formula Translating System”) is especially well-suited for numeric analysis.

SAS – a 4GPL, is a popular, widely used, mathematical (especially with respect to statistical analysis) programming language. SAS is based on/derived from a “formal science,” mathematics/statistics, and it allows a user to leverage knowledge of mathematics to define a problem and specify a solution algorithm for the problem. Please note that SAS does not constrain the process of specifying the solution algorithm in any way. Therefore, there is no reason to believe that a solution algorithm specified by a programmer is suitable for the task of solving the problem. Very likely, it is not. It is very possible that the human specified algorithm is flawed for any of a broad spectrum of reasons. Consequently, 4GPLs (and many 3GPLS) are integrated with systems for testing, debugging, verifying and validating solutions. When building a solution with a 4GPL, the majority of the effort is spent debugging and correcting the solution algorithm. Although validating, debugging, and correcting a 4GPL is expensive and resource intensive, it is far more efficient than building a solution using a 3GPL.

Enterprise Optimizer – a 5GPL, is based on/derived from an “empirical science” called Integrated Business Planning (IBP), as defined in my book Newtonian Economics. IBP can be thought of as economic science “corrected” to give it more robust predictive and explanatory capability. It allows a user to leverage their domain knowledge (the domain of EO is “enterprise analysis” or “economic analysis” or more generally, “IBP Analysis”) to define business planning problems in terms of intuitive domain constraints, such that EO can determine a suitable algorithm for solving the problem, implement the algorithm, and then execute the algorithm to solve the problem.

In contrast to solutions built using 4GPLs or 3GPLs, EO determined algorithm are based on thousands of person years of knowledge gathered from many of the best human subject matter experts in the world. In addition, the EO algorithms can be automatically validated and verified so that you know they are correct. 4GPLs have no way of doing this because they have no ability to understand the problem you are trying to solve. SAS, for example, assumes the programmer knows what they are doing – a very, very bad assumption!

With EO solutions, virtually no effort is spent by humans verifying or validating solution algorithms. This is why building solutions in EO takes far less time than building solutions using 4GPLs or 3GPLs; however, effort is required to validate and correct the problem statement. This is also the case with building solutions using 4GPLs and 3GPLs. It should be noted that validating and correcting problem statements in EO is a much simpler task than with a 4GPL or 3GPL for a variety of reasons. The most obvious is that with EO, you know the solution algorithm is correct; therefore, when you find an error, it is the problem statement that must be corrected. With a 4GPL or a 3GPL, if you find an error, you must first determine if the error is in the solution algorithm or the problem statement, and only then can you correct the error.

If you want to convert a SAS program to a Fortran program, you can read the SAS code and convert it to Fortran, copying the solution algorithm. You do not need to determine the solution algorithm or a way to express it programmatically. That has been done for you. All you need to do is create Fortran subroutines for ALL the SAS statistical procedures. (SAS programs are typically very long and there are many SAS statistical procedures, so no one really wants to do this.)

In contrast, if you wanted to convert an EO program to a SAS program or a Fortran program, the process for doing so is not clear. First, you would have to determine the problem being solved and then figure out a way to express that problem in SAS or Fortran. This will be a challenge because as one moves up through the generations of programming languages, the problems being solved increase in scope by orders of magnitude. This is why the different generations of programming language exist. For example, no one would ever want to try to write an entire ERP solution in machine code.

In order to translate the EO program to a SAS or Fortran program, it will be necessary to first figure out a way to represent the problem in SAS or Fortran. This is going to be very difficult.

Here is one reason why:

There are many sophisticated advances inherent in the progression of generations of programming languages. Just one is “system resource management.” Fortran has greater inherent ability to automatically manage system resources, such as memory, than assembly language. If you are familiar with an assembly language and with Fortran, just think about the differences in each with respect to tasks like allocating memory to arrays or checking if an index is out of bounds.

Similarly, in the context of the problems it is intended to solve, EO has far greater abilities to handle system resources than a 4GPL or a 3GPL.

Because of this, EO can solve problems that are far bigger than any problem a 4GPL or 3GPL can solve. This is why EO can be used to solve problems that have 30,000,000 variables and other platforms based on 4GPL or 3GPL technology consider problems with only 100,000 variables to be “enormous.” In other words, because of the inherent restrictions in 4GPLs and 3GPLs, you would never consider using them to solve problems that EO solves. Therefore, attempting to take the EO solution, corresponding to such a problem, and re-implement the solution in SAS or Fortran is going to be extremely problematic because solution management tools will not be able to effectively support the effort. Consequently, it is going to be a big challenge to figure out how to represent the problem expressed in EO using SAS or Fortran.

Another problem associated with converting an EO problem representation is that you will need to understand the semantics of EO problem statements. They are based on extensive knowledge of domain constraints, and it will not be obvious how to convert them to alternative representations. For example, it is possible to define some “EO Constraint Sets” in terms of mathematical structures known as “Special Ordered Sets.” Two types of Special Ordered Sets have been defined. Not surprisingly, they are called “Type 1” and “Type 2.” These formal definitions only cover a subset of “EO Constraint Sets.” So, if you want to convert the EO problem representation, you are going to have an interesting challenge! What are you going to do with the EO Constraint Sets that cannot be formally defined with Special Ordered Sets of Type 1 or Type 2? To address this problem, you are going to have to extend arcane branches of mathematics or you will have to define entirely new branches! (If you stick with EO, you will not have to learn anything you don’t already know! In EO, you simply express the problem using intuitive domain constraints. All the mathematical and solution algorithm details remain hidden.)

But for the moment, let’s assume you have figured out how to do all this. You have expanded the memory management capability of Fortran such that it can spin off a solve into a new address space like EO, and you have figured out the hashing functions used in EO that allow EO to represent huge problems in linear time, etc. Additionally, you have created a series of new mathematical disciplines and extended many previously existing ones. Even with all these problem representation issues resolved, there are still obstacles that must be overcome to translate EO to SAS or Fortran.

More specifically, because EO automatically creates and executes the solution algorithm, it is not clear what you are going to use as a basis for specifying the algorithm you want to express in SAS or Fortran. In the case of translating a SAS model to Fortran, the definitions of the statistical procedures used in SAS are readily available from a variety of sources. You do not have to figure them out yourself. You only need to write corresponding Fortran routines. (Please understand that attempting to do this would almost certainly constitute a BAD idea.)

With EO, even if you figure out how to replicate the problem statement representation, you have to determine how to replicate the process EO uses to interpret the problem statement and then map that to EO’s output. From that mapping, you would need to infer a solution algorithm. Only then would you be able to begin implementing the solution is SAS or Fortran.

To keep this all in perspective, please note that the process of mapping the problem statement to the output and then inferring a solution algorithm may involve mapping 40,000,000+ input variables to 30,000,000+ output variables.

The solution algorithm used by EO to solve the problem is dynamically constructed by many knowledge-based processes. Some of the solution components are proprietary to RLI and are thought to be “mathematically intractable” or even “mathematically impossible.” Even if you have the mathematical training and talent to figure out how to replicate all these components, it will take you a very long time to do so.

Now consider the following: If you somehow succeed in mapping millions of input variables to millions of output variables such that you can infer a solution algorithm *AND* you somehow succeed in implementing a SAS or Fortran program that mimics the EO solution, you have another hurdle to overcome. The solution you have implemented is only relevant to the specific problem statement specification. If the problem specification is changed in any way – if even a single number is modified – you have to begin again. Every time EO solves a problem, the solution algorithm is dynamically rebuilt!

If you really want to convert an EO solution to a SAS or Fortran implementation you are going to have to solve all the problem representation issues, and you are going to have to figure out the dynamically constructed solution algorithm and then replicate it. You will have to do this many, many times since EO builds the solution algorithm dynamically. Even in the best of circumstances, this is going to take you a long time.

Now here is the really bad news: By the time you are finished, you are going to learn that RLI has patented its proprietary solution components. Therefore, in summary, while it *IS* correct to say that every solution developed in a 4GPL can be translated to, and re-implemented in, a 3GPL (even though to do so would be a horrendous waste of time and resources), it *IS NOT* correct to say the same with respect to translating a solution developed in a 5GPL to a 4GPL or a 3GPL implementation. Even if it is possible to overcome all the staggering difficulties inherent in such an endeavor – which is extremely unlikely – in the end, the legal hurdles will get you.