By way of general background, scripting languages are programming languages that control software systems, applications and programs. Scripts are often treated as distinct from “programs,” which execute independently from other applications. In addition, scripts can be distinct from the “core code” of an application, which is typically written in a different language. Scripts can be written by developers or other programs. Where accessible to the end user, scripts enable the behavior of an application to be adapted to the user's needs. Scripts can also be interpreted from source code or “semi-compiled” to bytecode, or another machine friendly format, which is interpreted. Scripting languages can also be embedded in an application with which they are associated.
In this regard, when a large amount of data is stored in a database, such as when a set of server computers collect large numbers of records, or transactions, of data over long periods of time, other computers and their applications may desire access to that data or a targeted subset of that data. In such case, the other computers can use programs developed from scripting languages to query for desired data, read or write to the data, update the data, or apply any other processing to the data, via one or more operators, such as query operators, via a variety of conventional query languages. The amount of data can be voluminous in such circumstances, and the applications that have evolved for consuming the data become quite data intensive. Writing these data intensive applications in a compact, human friendly, textual format has thus far been a challenge.
Historically, relational databases have evolved for this purpose to organize large numbers of records and fields, and have been used for such large scale data collection, and various database query languages such as the structured query language (SQL) and other domain specific languages have developed, which instruct database management software to retrieve data from a relational database, or a set of distributed databases, on behalf of a querying client or application. Yet, by and large, due to the specific purposes for which such languages were developed and the context in which they were meant to operate, among various domain specific limitations, such languages, in a nutshell, have failed to provide sufficient generality and have elevated the importance of syntactically complex constructs and decreased the importance of intuitive expression.
Conventional attempts to develop data intensive applications have included T-SQL and UML.
Transact-SQL (T-SQL) enhances SQL with features such as control-of-flow language keywords for flow control including BEGIN and END, BREAK, CONTINUE, GOTO, IF and ELSE, RETURN, WAITFOR, and WHILE. For instance, IF and ELSE allow conditional execution. BEGIN and END mark a block of statements. WAITFOR waits for a given amount of time, or until a particular time of day and can be used for delays or to block execution until the set time. RETURN is used to immediately return from a stored procedure or function. BREAK ends the enclosing WHILE loop, while CONTINUE causes the next iteration of the loop to execute.
T-SQL includes local variables, so named because they are local to the script executing them; T-SQL does not support user-defined global variables. DECLARE declares a variable, giving it a name and a single set type. The SET statement can be used to provide a value, and the variable may be used in a statement by referencing its name. However, generally speaking, T-SQL is esoteric requiring expert development skill and knowledge of the nuances of T-SQL statements. T-SQL is also not considered compact because many programming statements are typically required even to perform relatively simple tasks.
The unified modeling language (UML) is a standardized general-purpose modeling language in the field of software engineering. UML includes a set of graphical notation techniques to create abstract models of specific systems, referred to as UML model. UML can be used for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.
UML is extensible, and while UML is not a method by itself, it was designed to be compatible with various object-oriented software development methods of its time. A UML model can be distinguished from the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a “semantic backplane” which is documentation, such as written use cases, that drive the model elements and diagrams.
UML diagrams represent three different views of a system model: (1) a functional requirements view that emphasizes the functional requirements of the system from the user's point of view, (2) a static structural view that emphasizes the static structure of the system using objects, attributes, operations and relationships, and includes class diagrams and composite structure diagrams, and (3) a dynamic behavior view that emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects, and includes sequence diagrams, activity diagrams and state machine diagrams.
However descriptive, UML is often criticized for being large and complex, containing many diagrams and constructs that are redundant or infrequently used. Like T-SQL, UML also provides a hurdle in learning and adoption due to the lack of engineers having the requisite skill and understanding. Moreover, the ad hoc mixing of abstract notation, e.g., 2-D ovals, boxes, etc. make UML appear jarring and thus the result is non-uniform and aesthetically displeasing.
By way of further background, an order of precedence for a programming language is a sequential hierarchy of nominal importance of items in the source code. In computer programming, when a number or expression is both preceded and followed by a binary operation, an order of operations rule is required for which operation should be applied first. For instance, multiplication historically has taken precedence over addition, on whichever side of a number it appears. Thus, 3+4×5=5×4+3=23 and parentheses ( ) are typically used to contradict the order of operations rule, e.g., (3+4)×5=35.
Many programming languages use precedence levels that conform to the order commonly used in mathematics, though some, such as APL (A Programming Language), have no operator precedence rules. In APL, evaluation is strictly right to left.
The logical bitwise operators in C, and programming languages that have borrowed precedence rules from C, have a precedence level that some consider to be limited in some ways and difficult to learn. The relative precedence levels of operators found in many C-style languages is shown in FIG. 1. The table of FIG. 1 shows that certain categories take precedence over other categories in the following order from highest priority to lowest: Grouping, scope, array/member access 100, (most) unary operations, size of and type casts 102, Multiplication, division, modulo 104, Addition and subtraction 106, Bitwise shift left and right 108, Comparisons (e.g., less than, greater than . . . ) 110, Comparisons: equal or not equal 112, Equality 114, Bitwise AND 116, Bitwise exclusive OR 118, Bitwise inclusive (normal) OR 120, Logical AND 122, Logical OR 124, Ternary operator 126 and Assignment operators 128. Corresponding operator syntax to the categories appears in the operator column of the table of FIG. 1.
The above-described background information and deficiencies of current programming languages and corresponding systems are merely intended to provide an overview of some of the background information and problems of conventional programming languages, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.
USPTO Backgrounds
USPTO Backgrounds