UML 1.x Activity diagram for a guided brainstorming process

Activity diagrams are graphical representations of workflows of stepwise activities and actions^[1] with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).Activity diagrams show the overall flow of control.
Activity diagrams are constructed from a limited number of shapes, connected with arrows.^[4] The most important shape types:

rounded rectangles represent actions;
diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent activities;
a black circle represents the start (initial node) of the workflow;
an encircled black circle represents the end (final node).

Arrows run from the start towards the end and represent the order in which activities happen.
Activity diagrams may be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency.^[5] However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.
While in UML 1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x, the activity diagrams were reformalized to be based on Petri net-like semantics, increasing the scope of situations that can be modeled using activity diagrams. These changes cause many UML 1.x activity diagrams to be interpreted differently in UML 2.x.
UML activity diagrams in version 2.x can be used in various domains, e.g. in design of embedded systems. It is possible to verify such a specification using model checking technique.

Z . O/I Control flow graph

A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution. The control flow graph is due to Frances E. Allen,^[1] who notes that Reese T. Prosser used boolean connectivity matrices for flow analysis before.^[2]
The CFG is essential to many compiler optimizations and static analysis tools.

Some CFG examples:
(a) an if-then-else
(b) a while loop
(c) a natural loop with two exits, e.g. while with an if...break in the middle; non-structured but reducible
(d) an irreducible CFG: a loop with two entry points, e.g. goto into a while for loop .

In a control flow graph each node in the graph represents a basic block, i.e. a straight-line piece of code without any jumps or jump targets; jump targets start a block, and jumps end a block. Directed edges are used to represent jumps in the control flow. There are, in most presentations, two specially designated blocks: the entry block, through which control enters into the flow graph, and the exit block, through which all control flow leaves.^[3]
Because of its construction procedure, in a CFG, every edge A→B has the property that:

outdegree(A) > 1 or indegree(B) > 1 (or both).

The CFG can thus be obtained, at least conceptually, by starting from the program's (full) flow graph—i.e. the graph in which every node represents an individual instruction—and performing an edge contraction for every edge that falsifies the predicate above, i.e. contracting every edge whose source has a single exit and whose destination has a single entry. This contraction-based algorithm is of no practical importance, except as a visualization aid for understanding the CFG construction, because the CFG can be more efficiently constructed directly from the program by scanning it for basic blocks .

Consider the following fragment of code:

0: (A) t0 = read_num
1: (A) if t0 mod 2 == 0
2: (B)   print t0 + " is even."
3: (B)   goto 5
4: (C) print t0 + " is odd."
5: (D) end program

In the above, we have 4 basic blocks: A from 0 to 1, B from 2 to 3, C at 4 and D at 5. In particular, in this case, A is the "entry block", D the "exit block" and lines 4 and 5 are jump targets. A graph for this fragment has edges from A to B, A to C, B to D and C to D.

Reachability is a graph property useful in optimization.
If a subgraph is not connected from the subgraph containing the entry block, that subgraph is unreachable during any execution, and so is unreachable code; under normal conditions it can be safely removed.
If the exit block is unreachable from the entry block, an infinite loop may exist. Not all infinite loops are detectable, see Halting problem. A halting order may also exist there.
Unreachable code and infinite loops are possible even if the programmer does not explicitly code them: optimizations like constant propagation and constant folding followed by jump threading can collapse multiple basic blocks into one, cause edges to be removed from a CFG, etc., thus possibly disconnecting parts of the graph.

Domination relationship

A block M dominates a block N if every path from the entry that reaches block N has to pass through block M. The entry block dominates all blocks.
In the reverse direction, block M postdominates block N if every path from N to the exit has to pass through block M. The exit block postdominates all blocks.
It is said that a block M immediately dominates block N if M dominates N, and there is no intervening block P such that M dominates P and P dominates N. In other words, M is the last dominator on all paths from entry to N. Each block has a unique immediate dominator.
Similarly, there is a notion of immediate postdominator, analogous to immediate dominator.
The dominator tree is an ancillary data structure depicting the dominator relationships. There is an arc from Block M to Block N if M is an immediate dominator of N. This graph is a tree, since each block has a unique immediate dominator. This tree is rooted at the entry block. Can be calculated efficiently using Lengauer–Tarjan's algorithm.
A postdominator tree is analogous to the dominator tree. This tree is rooted at the exit block.

Special edges

A back edge is an edge that points to a block that has already been met during a depth-first (DFS) traversal of the graph. Back edges are typical of loops.
A critical edge is an edge which is neither the only edge leaving its source block, nor the only edge entering its destination block. These edges must be split: a new block must be created in the middle of the edge, in order to insert computations on the edge without affecting any other edges.
An abnormal edge is an edge whose destination is unknown. Exception handling constructs can produce them. These edges tend to inhibit optimization.
An impossible edge (also known as a fake edge) is an edge which has been added to the graph solely to preserve the property that the exit block post dominates all blocks. It cannot ever be traversed.

Loop management

A loop header (sometimes called the entry point of the loop) is a dominator that is the target of a loop-forming back edge. The loop header dominates all blocks in the loop body. A block may be a loop header for more than one loop. A loop may have multiple entry points, in which case it has no "loop header".
Suppose block M is a dominator with several incoming edges, some of them being back edges (so M is a loop header). It is advantageous to several optimization passes to break M up into two blocks M_pre and M_loop. The contents of M and back edges are moved to M_loop, the rest of the edges are moved to point into M_pre, and a new edge from M_pre to M_loop is inserted (so that M_pre is the immediate dominator of M_loop). In the beginning, M_pre would be empty, but passes like loop-invariant code motion could populate it. M_pre is called the loop pre-header, and M_loop would be the loop header.

Z . O/I Cyclomatic complexity

Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. It was developed by Thomas J. McCabe, Sr. in 1976.
Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.
One testing strategy, called basis path testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program

Definition

A control flow graph of a simple program. The program begins executing at the red node, then enters a loop (group of three nodes immediately below the red node). On exiting the loop, there is a conditional statement (group below the loop), and finally the program exits at the blue node. This graph has 9 edges, 8 nodes, and 1 connected component, so the cyclomatic complexity of the program is 9 - 8 + 2*1 = 3.

The cyclomatic complexity of a section of source code is the number of linearly independent paths within it. For instance, if the source code contained no control flow statements (conditionals or decision points), the complexity would be 1, since there would be only a single path through the code. If the code had one single-condition IF statement, there would be two paths through the code: one where the IF statement evaluates to TRUE and another one where it evaluates to FALSE, so the complexity would be 2. Two nested single-condition IFs, or one IF with two conditions, would produce a complexity of 3.
Mathematically, the cyclomatic complexity of a structured program^[a] is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as^[2]

M = E − N + 2P,

where

E = the number of edges of the graph.

N = the number of nodes of the graph.

P = the number of connected components.

The same function as above, represented using the alternative formulation, where each exit point is connected back to the entry point. This graph has 10 edges, 8 nodes, and 1 connected component, which also results in a cyclomatic complexity of 3 using the alternative formulation (10 - 8 + 1 = 3).

An alternative formulation is to use a graph in which each exit point is connected back to the entry point. In this case, the graph is strongly connected, and the cyclomatic complexity of the program is equal to the cyclomatic number of its graph (also known as the first Betti number), which is defined as^[2]

M = E − N + P.

This may be seen as calculating the number of linearly independent cycles that exist in the graph, i.e. those cycles that do not contain other cycles within themselves. Note that because each exit point loops back to the entry point, there is at least one such cycle for each exit point.
For a single program (or subroutine or method), P is always equal to 1. So a simpler formula for a single subroutine is

M = E − N + 2.^[3]

Cyclomatic complexity may, however, be applied to several such programs or subprograms at the same time (e.g., to all of the methods in a class), and in these cases P will be equal to the number of programs in question, as each subprogram will appear as a disconnected subset of the graph.
McCabe showed that the cyclomatic complexity of any structured program with only one entrance point and one exit point is equal to the number of decision points (i.e., "if" statements or conditional loops) contained in that program plus one. However, this is true only for decision points counted at the lowest, machine-level instructions. Decisions involving compound predicates like those found in high-level languages like IF cond1 AND cond2 THEN ... should be counted in terms of predicate variables involved, i.e. in this example one should count two decision points, because at machine level it is equivalent to IF cond1 THEN IF cond2 THEN ....^[2]^[4]
Cyclomatic complexity may be extended to a program with multiple exit points; in this case it is equal to:

π − s + 2,

where π is the number of decision points in the program, and s is the number of exit points.

Explanation in terms of algebraic topology

An even subgraph of a graph (also known as an Eulerian subgraph) is one where every vertex is incident with an even number of edges; such subgraphs are unions of cycles and isolated vertices. In the following, even subgraphs will be identified with their edge sets, which is equivalent to only considering those even subgraphs which contain all vertices of the full graph.
The set of all even subgraphs of a graph is closed under symmetric difference, and may thus be viewed as a vector space over GF(2); this vector space is called the cycle space of the graph. The cyclomatic number of the graph is defined as the dimension of this space. Since GF(2) has two elements and the cycle space is necessarily finite, the cyclomatic number is also equal to the 2-logarithm of the number of elements in the cycle space.
A basis for the cycle space is easily constructed by first fixing a spanning forest of the graph, and then considering the cycles formed by one edge not in the forest and the path in the forest connecting the endpoints of that edge; these cycles constitute a basis for the cycle space. Hence, the cyclomatic number also equals the number of edges not in a maximal spanning forest of a graph. Since the number of edges in a maximal spanning forest of a graph is equal to the number of vertices minus the number of components, the formula

E-N+P

above for the cyclomatic number follows.^[6]
For the more topologically inclined, cyclomatic complexity can alternatively be defined as a relative Betti number, the size of a relative homology group:

M:=b_{1}(G,t):=\operatorname {rank} H_{1}(G,t),

which is read as "the rank of the first homology group of the graph G, relative to the terminal nodes t". This is a technical way of saying "the number of linearly independent paths through the flow graph from an entry to an exit", where:

"linearly independent" corresponds to homology, and means one does not double-count backtracking;
"paths" corresponds to first homology: a path is a 1-dimensional object;
"relative" means the path must begin and end at an entry or exit point.

This corresponds to the intuitive notion of cyclomatic complexity, and can be calculated as above.
Alternatively, one can compute this via absolute Betti number (absolute homology – not relative) by identifying (gluing together) all the terminal nodes on a given component (or equivalently, draw paths connecting the exits to the entrance), in which case (calling the new, augmented graph

{\tilde {G}}

, which is ), one obtains:

M=b_{1}({\tilde {G}})=\operatorname {rank} H_{1}({\tilde {G}}).

It can also be computed via homotopy. If one considers the control flow graph as a 1-dimensional CW complex called

X

, then the fundamental group of

X

will be

\pi _{1}(X)=\mathbb {Z} ^{n}

. The value of

n+1

is the cyclomatic complexity. The fundamental group counts how many loops there are through the graph, up to homotopy, and hence aligns with what we would intuitively expect.
This corresponds to the characterization of cyclomatic complexity as "number of loops plus number of components".

Applications

Limiting complexity during development

One of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.^[2] This practice was adopted by the NIST Structured Testing methodology, with an observation that since McCabe's original publication, the figure of 10 had received substantial corroborating evidence, but that in some circumstances it may be appropriate to relax the restriction and permit modules with a complexity as high as 15. As the methodology acknowledged that there were occasional reasons for going beyond the agreed-upon limit, it phrased its recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-upon limit] or provide a written explanation of why the limit was exceeded."^[7]

Measuring the "structuredness" of a program

Section VI of McCabe's 1976 paper is concerned with determining what the control flow graphs (CFGs) of non-structured programs look like in terms of their subgraphs, which McCabe identifies. (For details on that part see structured program theorem.) McCabe concludes that section by proposing a numerical measure of how close to the structured programming ideal a given program is, i.e. its "structuredness" using McCabe's neologism. McCabe called the measure he devised for this purpose essential complexity.^[2]
In order to calculate this measure, the original CFG is iteratively reduced by identifying subgraphs that have a single-entry and a single-exit point, which are then replaced by a single node. This reduction corresponds to what a human would do if she extracted a subroutine from the larger piece of code. (Nowadays such a process would fall under the umbrella term of refactoring.) McCabe's reduction method was later called condensation in some textbooks, because it was seen as a generalization of the condensation to components used in graph theory.^[8] If a program is structured, then McCabe's reduction/condensation process reduces it to a single CFG node. In contrast, if the program is not structured, the iterative process will identify the irreducible part. The essential complexity measure defined by McCabe is simply the cyclomatic complexity of this irreducible graph, so it will be precisely 1 for all structured programs, but greater than one for non-structured programs.^[7]^:80

Implications for software testing

Another application of cyclomatic complexity is in determining the number of test cases that are necessary to achieve thorough test coverage of a particular module.
It is useful because of two properties of the cyclomatic complexity, M, for a specific module:

M is an upper bound for the number of test cases that are necessary to achieve a complete branch coverage.
M is a lower bound for the number of paths through the control flow graph (CFG). Assuming each test case takes one path, the number of cases needed to achieve path coverage is equal to the number of paths that can actually be taken. But some paths may be impossible, so although the number of paths through the CFG is clearly an upper bound on the number of test cases needed for path coverage, this latter number (of possible paths) is sometimes less than M.

All three of the above numbers may be equal: branch coverage

\leq

cyclomatic complexity

\leq

number of paths.
For example, consider a program that consists of two sequential if-then-else statements.

if( c1() )
   f1();
else
   f2();

if( c2() )
   f3();
else
   f4();

The control flow graph of the source code above; the red circle is the entry point of the function, and the blue circle is the exit point. The exit has been connected to the entry to make the graph strongly connected.

In this example, two test cases are sufficient to achieve a complete branch coverage, while four are necessary for complete path coverage. The cyclomatic complexity of the program is 3 (as the strongly connected graph for the program contains 9 edges, 7 nodes and 1 connected component) (9-7+1).
In general, in order to fully test a module, all execution paths through the module should be exercised. This implies a module with a high complexity number requires more testing effort than a module with a lower value since the higher complexity number indicates more pathways through the code. This also implies that a module with higher complexity is more difficult for a programmer to understand since the programmer must understand the different pathways and the results of those pathways.
Unfortunately, it is not always practical to test all possible paths through a program. Considering the example above, each time an additional if-then-else statement is added, the number of possible paths grows by 2. As the program grew in this fashion, it would quickly reach the point where testing all of the paths was impractical.
One common testing strategy, espoused for example by the NIST Structured Testing methodology, is to use the cyclomatic complexity of a module to determine the number of white-box tests that are required to obtain sufficient coverage of the module. In almost all cases, according to such a methodology, a module should have at least as many tests as its cyclomatic complexity; in most cases, this number of tests is adequate to exercise all the relevant paths of the function.^[7]
As an example of a function that requires more than simply branch coverage to test accurately, consider again the above function, but assume that to avoid a bug occurring, any code that calls either f1() or f3() must also call the other.^[b] Assuming that the results of c1() and c2() are independent, that means that the function as presented above contains a bug. Branch coverage would allow us to test the method with just two tests, and one possible set of tests would be to test the following cases:

c1() returns true and c2() returns true
c1() returns false and c2() returns false

Neither of these cases exposes the bug. If, however, we use cyclomatic complexity to indicate the number of tests we require, the number increases to 3. We must therefore test one of the following paths:

c1() returns true and c2() returns false
c1() returns false and c2() returns true

Either of these tests will expose the bug.

Cohesion

One would also expect that a module with higher complexity would tend to have lower cohesion (less than functional cohesion) than a module with lower complexity. The possible correlation between higher complexity measure with a lower level of cohesion is predicated on a module with more decision points generally implementing more than a single well defined function. A 2005 study showed stronger correlations between complexity metrics and an expert assessment of cohesion in the classes studied than the correlation between the expert's assessment and metrics designed to calculate cohesion.

Correlation to number of defects

A number of studies have investigated the correlation between McCabe's cyclomatic complexity number with the frequency of defects occurring in a function or method.^[10] Some studies^[11] find a positive correlation between cyclomatic complexity and defects: functions and methods that have the highest complexity tend to also contain the most defects. However, the correlation between cyclomatic complexity and program size (typically measured in lines of code) has been demonstrated many times. Les Hatton has claimed^[12] that complexity has the same predictive ability as lines of code. Studies that controlled for program size (i.e., comparing modules that have different complexities but similar size) are generally less conclusive, with many finding no significant correlation, while others do find correlation. Some researchers who have studied the area question the validity of the methods used by the studies finding no correlation.^[13] Although this relation is probably true, it isn't commercially useful.^[14] Since program size is not a controllable feature of commercial software, the usefulness of McCabes's number has been called to question. The essence of this observation is that larger programs tend to be more complex and to have more defects. As a result, the metric has not been accepted by commercial software development organizations.^[10] Thus, reducing the cyclomatic complexity of code is not proven to reduce the number of errors or bugs in that code.

Z . O/I Static program analysis

Static program analysis is the analysis of computer software that is performed without actually executing programs (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code, and in the other cases, some form of the object code.
The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding, program comprehension, or code review. Software inspections and software walkthroughs are also used in the latter case.

The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations, to those that include the complete source code of a program in their analysis. The uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification).
Software metrics and reverse engineering can be described as forms of static analysis. Deriving software metrics and static analysis are increasingly deployed together, especially in creation of embedded systems, by defining so-called software quality objectives.^[2]
A growing commercial use of static analysis is in the verification of properties of software used in safety-critical computer systems and locating potentially vulnerable code.^[3] For example, the following industries have identified the use of static code analysis as a means of improving the quality of increasingly sophisticated and complex software:

Medical software: The U.S. Food and Drug Administration (FDA) has identified the use of static analysis for medical devices.^[4]
Nuclear software: In the UK the Office for Nuclear Regulation (ONR) recommends the use of static analysis on reactor protection systems.^[5]
Aviation software (in combination with dynamic analysis)^[6]

A study in 2012 by VDC Research reports that 28.7% of the embedded software engineers surveyed currently use static analysis tools and 39.7% expect to use them within 2 years.^[7] A study from 2010 found that 60% of the interviewed developers in European research projects made at least use of their basic IDE built-in static analyzers. However, only about 10% employed an additional other (and perhaps more advanced) analysis tool.^[8]
In the application security industry the name Static Application Security Testing (SAST) is also used. Actually, SAST is an important part of Security Development Lifecycles (SDLs) such as the SDL defined by Microsoft and a common practice in software companies.

Tool types

The OMG (Object Management Group) published a study regarding the types of software analysis required for software quality measurement and assessment. This document on "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations" describes three levels of software analysis.

Unit Level: Analysis that takes place within a specific program or subroutine, without connecting to the context of that program.
Technology Level: Analysis that takes into account interactions between unit programs to get a more holistic and semantic view of the overall program in order to find issues and avoid obvious false positives.
System Level: Analysis that takes into account the interactions between unit programs, but without being limited to one specific technology or programming language.

A further level of software analysis can be defined.

Mission/Business Level: Analysis that takes into account the business/mission layer terms, rules and processes that are implemented within the software system for its operation as part of enterprise or program/mission layer activities. These elements are implemented without being limited to one specific technology or programming language and in many cases are distributed across multiple languages, but are statically extracted and analyzed for system understanding for mission assurance.

Formal methods

Formal methods is the term applied to the analysis of software (and computer hardware) whose results are obtained purely through the use of rigorous mathematical methods. The mathematical techniques used include denotational semantics, axiomatic semantics, operational semantics, and abstract interpretation.
By a straightforward reduction to the halting problem, it is possible to prove that (for any Turing complete language), finding all possible run-time errors in an arbitrary program (or more generally any kind of violation of a specification on the final result of a program) is undecidable: there is no mechanical method that can always answer truthfully whether an arbitrary program may or may not exhibit runtime errors. This result dates from the works of Church, Gödel and Turing in the 1930s (see: Halting problem and Rice's theorem). As with many undecidable questions, one can still attempt to give useful approximate solutions.
Some of the implementation techniques of formal static analysis include:

Abstract interpretation, to model the effect that every statement has on the state of an abstract machine (i.e., it 'executes' the software based on the mathematical properties of each statement and declaration). This abstract machine over-approximates the behaviours of the system: the abstract system is thus made simpler to analyze, at the expense of incompleteness (not every property true of the original system is true of the abstract system). If properly done, though, abstract interpretation is sound (every property true of the abstract system can be mapped to a true property of the original system).^[13] The Frama-C value analysis plugin and Polyspace heavily rely on abstract interpretation.
Data-flow analysis, a lattice-based technique for gathering information about the possible set of values;
Hoare logic, a formal system with a set of logical rules for reasoning rigorously about the correctness of computer programs. There is tool support for some programming languages (e.g., the SPARK programming language (a subset of Ada) and the Java Modeling Language—JML—using ESC/Java and ESC/Java2, Frama-C WP (weakest precondition) plugin for the C language extended with ACSL (ANSI/ISO C Specification Language) ).
Model checking, considers systems that have finite state or may be reduced to finite state by abstraction;
Symbolic execution, as used to derive mathematical expressions representing the value of mutated variables at particular points in the code.

Z . O/I Shape analysis (program analysis)

In program analysis, a shape analysis is a static code analysis technique that discovers and verifies properties of linked, dynamically allocated data structures in (usually imperative) computer programs. It is typically used at compile time to find software bugs or to verify high-level correctness properties of programs. In Java programs, it can be used to ensure that a sort method correctly sorts a list. For C programs, it might look for places where a block of memory is not properly freed.

Applications

Shape analysis has been applied to a variety of problems:

Memory safety: finding memory leaks, dereferences of dangling pointers, and discovering cases where a block of memory is freed more than once.
Finding array out-of-bounds errors
Checking type-state properties (for example, ensuring that a file is open() before it is read())
Ensuring that a method to reverse a linked list does not introduce cycles into the list^[2]
Verifying that a sort method returns a result that is in sorted order

Example

Shape analysis is a form of pointer analysis, although it is more precise than typical pointer analysis. Pointer analysis attempt to determine the set of objects to which a pointer can point (called the points-to set of the pointer). Unfortunately, these analysis are necessarily approximate (since a perfectly precise static analysis could solve the halting problem). Shape analysis can determine smaller (more precise) points-to sets.
Consider the following simple C++ program.

Item *items[10];
for (int i = 0; i < 10; ++i) {
    items[i] = new Item(...); // line [1]
}
process_items(items); // line [2]
for (int i = 0; i < 10; ++i) {
    delete items[i]; // line [3]
}

This program builds an array of objects, processes them in some arbitrary way, and then deletes them. Assuming that the process_items function is free of errors, it is clear that the program is safe: it never references freed memory, and it deletes all the objects that it has constructed.
Unfortunately, most pointer analyses have difficulty analyzing this program precisely. In order to determine points-to sets, a pointer analysis must be able to name a program's objects. In general, programs can allocate an unbounded number of objects; but in order to terminate, a pointer analysis can only use a finite set of names. A typical approximation is to give all the objects allocated on a given line of the program the same name. In the example above, all the objects constructed at line [1] would have the same name. Therefore, when the delete statement is analyzed for the first time, the analysis determines that one of the objects named [1] is being deleted. The second time the statement is analyzed (since it is in a loop) the analysis warns of a possible error: since it is unable to distinguish the objects in the array, it may be that the second delete is deleting the same object as the first delete. This warning is spurious, and the goal of shape analysis is to avoid such warnings.

Summarization and materialization

Shape analysis overcomes the problems of pointer analysis by using a more flexible naming system for objects. Rather than giving an object the same name throughout a program, objects can change names depending on the program's actions. Sometimes, several distinct objects with different names may be summarized, or merged, so that they have the same name. Then, when a summarized object is about to be used by the program, it can be materialized—that is, the summarized object is split into two objects with distinct names, one representing a single object and the other representing the remaining summarized objects. The basic heuristic of shape analysis is that objects that are being used by the program are represented using unique materialized objects, while objects not in use are summarized.
The array of objects in the example above is summarized in separate ways at lines [1], [2], and [3]. At line [1], the array has been only partly constructed. The array elements 0..i-1 contain constructed objects. The array element i is about to be constructed, and the following elements are uninitialized. A shape analysis can approximate this situation using a summary for the first set of elements, a materialized memory location for element i, and a summary for the remaining uninitialized locations, as follows:

0 .. i-1	i	i+1 .. 9
pointer to constructed object (summary)	uninitialized	uninitialized (summary)

After the loop terminates, at line [2], there is no need to keep anything materialized. The shape analysis determines at this point that all the array elements have been initialized:

0 .. 9

pointer to constructed object (summary)

At line [3], however, the array element i is in use again. Therefore, the analysis splits the array into three segments as in line [1]. This time, though, the first segment before i has been deleted, and the remaining elements are still valid (assuming the delete statement hasn't executed yet).

0 .. i-1	i	i+1 .. 9
free (summary)	pointer to constructed object	pointer to constructed object (summary)

Notice that in this case, the analysis recognizes that the pointer at index i has not been deleted yet. Therefore, it doesn't warn of a double deletion

Z . O/I Formal verification

In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.
Formal verification can be helpful in proving the correctness of systems such as: cryptographic protocols, combinational circuits, digital circuits with internal memory, and software expressed as source code.
The verification of these systems is done by providing a formal proof on an abstract mathematical model of the system, the correspondence between the mathematical model and the nature of the system being otherwise known by construction. Examples of mathematical objects often used to model systems are: finite state machines, labelled transition systems, Petri nets, vector addition systems, timed automata, hybrid automata, process algebra, formal semantics of programming languages such as operational semantics, denotational semantics, axiomatic semantics and Hoare logic

Approaches

One approach and formation is model checking, which consists of a systematically exhaustive exploration of the mathematical model (this is possible for finite models, but also for some infinite models where infinite sets of states can be effectively represented finitely by using abstraction or taking advantage of symmetry). Usually this consists of exploring all states and transitions in the model, by using smart and domain-specific abstraction techniques to consider whole groups of states in a single operation and reduce computing time. Implementation techniques include state space enumeration, symbolic state space enumeration, abstract interpretation, symbolic simulation, abstraction refinement.^{[citation needed]} The properties to be verified are often described in temporal logics, such as linear temporal logic (LTL), Property Specification Language (PSL), SystemVerilog Assertions (SVA),^[3] or computational tree logic (CTL). The great advantage of model checking is that it is often fully automatic; its primary disadvantage is that it does not in general scale to large systems; symbolic models are typically limited to a few hundred bits of state, while explicit state enumeration requires the state space being explored to be relatively small.
Another approach is deductive verification. It consists of generating from the system and its specifications (and possibly other annotations) a collection of mathematical proof obligations, the truth of which imply conformance of the system to its specification, and discharging these obligations using either interactive theorem provers (such as HOL, ACL2, Isabelle, Coq or PVS), automatic theorem provers, or satisfiability modulo theories (SMT) solvers. This approach has the disadvantage that it typically requires the user to understand in detail why the system works correctly, and to convey this information to the verification system, either in the form of a sequence of theorems to be proved or in the form of specifications of system components (e.g. functions or procedures) and perhaps subcomponents (such as loops or data structures).

Software

Formal verification of software programs involves proving that a program satisfies a formal specification of its behavior. Subareas of formal verification include deductive verification (see above), abstract interpretation, automated theorem proving, type systems, and lightweight formal methods. A promising type-based verification approach is dependently typed programming, in which the types of functions include (at least part of) those functions' specifications, and type-checking the code establishes its correctness against those specifications. Fully featured dependently typed languages support deductive verification as a special case.
Another complementary approach is program derivation, in which efficient code is produced from functional specifications by a series of correctness-preserving steps. An example of this approach is the Bird-Meertens Formalism, and this approach can be seen as another form of correctness by construction.
These techniques can be sound, meaning that the verified properties can be logically deduced from the semantics, or unsound, meaning that there is no such guarantee. A sound technique yields a result only once it has searched the entire space of possibilities. An example of an unsound technique is one that searches only a subset of the possibilities, for instance only integers up to a certain number, and give a "good-enough" result. Techniques can also be decidable, meaning that their algorithmic implementations are guaranteed to terminate with an answer, or undecidable, meaning that they may never terminate. Because they are bounded, unsound techniques are often more likely to be decidable than sound ones.

Verification and validation

Verification is one aspect of testing a product's fitness for purpose. Validation is the complementary aspect. Often one refers to the overall checking process as V & V.

Validation: "Are we trying to make the right thing?", i.e., is the product specified to the user's actual needs?
Verification: "Have we made what we were trying to make?", i.e., does the product conform to the specifications?

The verification process consists of static/structural and dynamic/behavioral aspects. E.g., for a software product one can inspect the source code (static) and run against specific test cases (dynamic). Validation usually can be done only dynamically, i.e., the product is tested by putting it through typical and atypical usages ("Does it satisfactorily meet all use cases?").

Automated program repair

Automated program repair involves repairing software bugs, with very limited or no human intervention. (See also Automatic bug fixing). Program repair is performed with respect to an oracle, encompassing the desired functionality of the program which is used for validation of the generated fix. A simple example is a test-suite—the input/output pairs specify the functionality of the program. A variety of techniques are employed, most notably using satisfiability modulo theories (SMT) solvers,^[4] and genetic programming,^[5] using evolutionary computing to generate and evaluate possible candidates for fixes. The former method is deterministic, while the latter is randomized.
Program repair combines techniques from formal verification and program synthesis. Fault-localization techniques in formal verification are used to compute program points which might be possible bug-locations, which can be targeted by the synthesis modules. Repair systems often focus on a small pre-defined class of bugs in order to reduce the search space. Industrial use is limited owing to the computational cost of existing techniques.

Industry use

The growth in complexity of designs increases the importance of formal verification techniques in the hardware industry.At present, formal verification is used by most or all leading hardware companies,^[8] but its use in the software industry is still languishing.^{[citation needed]} This could be attributed to the greater need in the hardware industry, where errors have greater commercial significance.^{[citation needed]} Because of the potential subtle interactions between components, it is increasingly difficult to exercise a realistic set of possibilities by simulation. Important aspects of hardware design are amenable to automated proof methods, making formal verification easier to introduce and more productive.
As of 2011, several operating systems have been formally verified: NICTA's Secure Embedded L4 microkernel, sold commercially as seL4 by OK Labs;^[10] OSEK/VDX based real-time operating system ORIENTAIS by East China Normal University;^{[citation needed]} Green Hills Software's Integrity operating system;^{[citation needed]} and SYSGO's PikeOS.^[11]^[12]
The CompCert C compiler is a formally verified C compiler implementing the majority of ISO C.

Z . O/I Automated proof checking

Automated proof checking is the process of using software for checking proofs for correctness. It is one of the most developed fields in automated reasoning.
Automated proof checking differs from automated theorem proving in that automated proof checking simply mechanically checks the formal workings of an existing proof, instead of trying to develop new proofs or theorems itself. Because of this, the task of automated proof verification is much simpler than that of automated theorem proving, allowing automated proof checking software to be much simpler than automated theorem proving software.
Because of this small size, some automated proof checking systems can have less than a thousand lines of core code, and are thus themselves amenable to both hand-checking and automated software verification.
The Mizar system, HOL Light, and Metamath are examples of automated proof checking systems.
Automated proof checking can be done either as a batch operation, or interactively, as part of an interactive theorem proving system.

Interactive Theorem Proving (conference)

BASIC
	Screenshot of Atari BASIC, one of the BASIC implementations used by the small and simple home computers of the early 1980s.
Paradigm	Non-structured, later procedural, later object-oriented
Designed by	John G. Kemeny; Thomas E. Kurtz;
First appeared	May 1, 1964; 53 years ago
Major implementations
	Dartmouth BASIC; Apple BASIC; Atari BASIC; Sinclair BASIC; Commodore BASIC; BBC BASIC; TI-BASIC; Casio BASIC; Microsoft BASIC; Liberty BASIC; Visual Basic; FreeBASIC; PowerBASIC; Gambas;
Influenced by
	ALGOL 60; FORTRAN II; JOSS;
Influenced
	COMAL; Visual Basic; Visual Basic .NET; Realbasic;

Interactive Theorem Proving (ITP) is an annual international academic conference on the topic of automated theorem proving, proof assistants and related topics, ranging from theoretical foundations to implementation aspects and applications in program verification, security, and formalization of mathematics.

ITP brings together the communities using many systems based on higher-order logic such as ACL2, Coq, Mizar, HOL, Isabelle, NuPRL, PVS, and Twelf. Individual workshops or meetings devoted to individual systems are usually held concurrently with the conference.
Together with CADE and TABLEAUX, ITP is usually one of the three main conferences of the International Joint Conference on Automated Reasoning (IJCAR) whenever it convenes, the Theorem Proving in Higher Order Logics (TPHOLs) conference series to the broad field of interactive theorem proving.
The first three were informal users' meetings for the HOL system and were the only ones without published papers. Since 1990 TPHOLs has published formal peer-reviewed proceedings, published by Springer's Lecture Notes in Computer Science series. It has also entertained an increasingly wide field of interest.

Z . O/I Post-silicon validation

Post-silicon validation and debug is the last step in the development of a semiconductor integrated circuit .

Pre-silicon process

During the pre-silicon process, engineers test devices in a virtual environment with sophisticated simulation, emulation, and formal verification tools. In contrast, post-silicon validation tests occur on actual devices running at-speed in commercial, real-world system boards using logic analyzer and assertion-based tools.

Reasoning

Large semiconductor companies spend millions creating new components; these are the "sunk costs" of design implementation. Consequently, it is imperative that the new chip function in full and perfect compliance to its specification, and be delivered to the market within tight consumer windows. Even a delay of a few weeks can cost tens of millions of dollars. Post-silicon validation is therefore one of the most highly leveraged steps in successful design implementation.

Validation

Chips comprising 500,000 logic elements are the silicon brains inside cell phones, MP3 players, computer printers and peripherals, digital television sets, medical imaging systems, components used in transportation safety and comfort, and even building management systems. Either because of their broad consumer proliferation, or because of their mission-critical application, the manufacturer must be absolutely certain that the device is thoroughly validated.
The best way to achieve high confidence is to leverage the pre-silicon verification work — which can comprise as much as 30% of the overall cost of the implementation — and use that knowledge in the post-silicon system. Today, much of this work is done manually, which partially explains the high costs associated with system validation. However, there are some tools that have been recently introduced to automate post-silicon system validation.

Observability

Simulation-based design environments enjoy the tremendous advantage of nearly perfect observability, meaning the designer can see any signal at nearly any time. They suffer, however, from the restricted amount of data they can generate during post-silicon system validation. Many complicated devices indicate their problems only after days or weeks of testing, and they produce a volume of data that would take centuries to reproduce on a simulator. FPGA-based emulators, a well-established part of most implementation techniques, are faster than software simulators but will not deliver the comprehensive at-system-speed tests needed for device reliability.
Moreover, the problem of post-silicon validation is getting worse, as design complexity increases because of the terrific advances in semiconductor materials processing. The duration from prototype silicon — so-called "first silicon" — to volume production is increasing, and bugs do escape to the customers. The expense associated with IP-hardening is increasing. The industry today is focused on techniques that allow designers to better amortize their investment in pre-silicon verification to post-silicon validation. The best of these solutions enable affordable, scalable, automated, on-chip wire-scale visibility.

Benefits

Post-silicon validation encompasses all that validation effort that is poured onto a system after the first few silicon prototypes become available, but before product release. While in the past most of this effort was dedicated to validating electrical aspects of the design, or diagnosing systematic manufacturing defects, today a growing portion of the effort focuses on functional system validation. This trend is for the most part due to the increasing complexity of digital systems, which limits the verification coverage provided by traditional pre-silicon methodologies. As a result, a number of functional bugs survive into manufactured silicon, and it is the job of post-silicon validation to detect and diagnose them so that they do not escape into the released system. The bugs in this category are often system-level bugs and rare corner-case situations buried deep in the design state space: since these problems encompass many design modules, they are difficult to identify with pre-silicon tools, characterized by limited scalability and performance.
Post-silicon validation, on the other hand, benefits from very high raw performance, since tests are executed directly on manufactured silicon. At the same time, it poses several challenges to traditional validation methodologies, because of the limited internal observability and difficulty of applying modifications to manufactured silicon chips. These two factors lead in turn to critical challenges in error diagnosis and correction.

Z . O/I Design flow (EDA)

Design flows are the explicit combination of electronic design automation tools to accomplish the design of an integrated circuit. Moore's law has driven the entire IC implementation RTL to GDSII design flows from one which uses primarily stand-alone synthesis, placement, and routing algorithms to an integrated construction and analysis flows for design closure. The challenges of rising interconnect delay led to a new way of thinking about and integrating design closure tools.
The RTL to GDSII flow underwent significant changes from 1980 through 2005. The continued scaling of CMOS technologies significantly changed the objectives of the various design steps. The lack of good predictors for delay has led to significant changes in recent design flows. New scaling challenges such as leakage power, variability, and reliability will continue to require significant changes to the design closure process in the future. Many factors describe what drove the design flow from a set of separate design steps to a fully integrated approach, and what further changes are coming to address the latest challenges. In his keynote at the 40th Design Automation Conference entitled The Tides of EDA, Alberto Sangiovanni-Vincentelli distinguished three periods of EDA:

The Age of Invention: During the invention era, routing, placement, static timing analysis and logic synthesis were invented.
The Age of Implementation: In the age of implementation, these steps were drastically improved by designing sophisticated data structures and advanced algorithms. This allowed the tools in each of these design steps to keep pace with the rapidly increasing design sizes. However, due to the lack of good predictive cost functions, it became impossible to execute a design flow by a set of discrete steps, no matter how efficiently each of the steps was implemented.
The Age of Integration: This led to the age of integration where most of the design steps are performed in an integrated environment, driven by a set of incremental cost analyzers.

Z . O/I Routing (electronic design automation)

In electronic design, wire routing, commonly called simply routing, is a step in the design of printed circuit boards (PCBs) and integrated circuits (ICs). It builds on a preceding step, called placement, which determines the location of each active element of an IC or component on a PCB. After placement, the routing step adds wires needed to properly connect the placed components while obeying all design rules for the IC.
The task of all routers is the same. They are given some pre-existing polygons consisting of pins (also called terminals) on cells, and optionally some pre-existing wiring called preroutes. Each of these polygons are associated with a net, usually by name or number. The primary task of the router is to create geometries such that all terminals assigned to the same net are connected, no terminals assigned to different nets are connected, and all design rules are obeyed. A router can fail by not connecting terminals that should be connected (an open), by mistakenly connecting two terminals that should not be connected (a short), or by creating a design rule violation. In addition, to correctly connect the nets, routers may also be expected to make sure the design meets timing, has no crosstalk problems, meets any metal density requirements, does not suffer from antenna effects, and so on. This long list of often conflicting objectives is what makes routing extremely difficult.
Almost every problem associated with routing is known to be intractable. The simplest routing problem, called the Steiner tree problem, of finding the shortest route for one net in one layer with no obstacles and no design rules is NP-hard if all angles are allowed and NP-complete if only horizontal and vertical wires are allowed. Variants of channel routing have also been shown to be NP-complete, as well as routing which reduces crosstalk, number of vias, and so on. Routers therefore seldom attempt to find an optimum result. Instead, almost all routing is based on heuristics which try to find a solution that is good enough.
Design rules sometimes vary considerably from layer to layer. For example, the allowed width and spacing on the lower layers may be four or more times smaller than the allowed widths and spacings on the upper layers. This introduces many additional complications not faced by routers for other applications such as printed circuit board or multi-chip module design. Particular difficulties ensue if the rules are not simple multiples of each other, and when vias must traverse between layers with different rules.

Types of routers

The earliest types of EDA routers were "manual routers"—the drafter clicked a mouse on the endpoint of each line segment of each net. Modern PCB design software typically provides "interactive routers"—the drafter selects a pad and clicks a few places to give the EDA tool an idea of where to go, and the EDA tool tries to place wires as close to that path as possible without violating design rule checking (DRC). Some more advanced interactive routers have "push and shove" (aka "shove-aside" or "automoving") features in an interactive router; the EDA tool pushes other nets out of the way, if possible, in order to place a new wire where the drafter wants it and still avoid violating DRC. Modern PCB design software also typically provides "autorouters" that route all remaining unrouted connections without human intervention.
The main types of autorouters are:

Maze router
- Lee router
- Hadlock router^[3]
Line-probe router
- Mikami-Tahuchi router^[4]
- Hightower router
Pattern router
Channel router
- Switchbox router
Gridless router
- Area router
- Topological router
  - FreeStyle Router (aka SpeedWay, a DOS-based autorouter for P-CAD)
  - TopoR (a Windows-based autorouter, also used in Eremex's Delta Design)
  - Toporouter (Anthony Blake's open-source router in PCB of the gEDA suite)
  - TopRouter (the topological pre-router in CadSoft/Autodesk's EAGLE 7.0 and higher)

How routers work

Many routers execute the following overall algorithm:

First, determine an approximate course for each net, often by routing on a coarse grid. This step is called global routing,^[9] and may optionally include layer assignment. Global routing limits the size and complexity of the following detailed routing steps, which can be done grid square by grid square.

For detailed routing, the most common technique is rip-up and reroute:

Select a sequence in which the nets are to be routed.
Route each net in sequence
If not all nets can be successfully routed, apply any of a variety of "cleanup" methods, in which selected routings are removed, the order of the remaining nets to be routed is changed, and the remaining routings are attempted again.

This process repeats until all nets are routed or the program (or user) gives up.
An alternative approach is to treat shorts, design rule violations, obstructions, etc. on a similar footing as excess wire length—that is, as finite costs to be reduced (at first) rather than as absolutes to be avoided. This multi-pass "iterative-improvement" routing method is described by the following algorithm:

For each of several iterative passes:
Prescribe or adjust the weight parameters of an "objective function" (having a weight parameter value for each unit of excess wire length, and for each type of violation). E.g., for the first pass, excess wire length may typically be given a high cost, while design violations such as shorts, adjacency, etc. are given a low cost. In later passes, the relative ordering of costs is changed so that violations are high-cost, or may be prohibited absolutely.
Select (or randomly choose) a sequence in which nets are to be routed during this pass.
"Rip up" (if previously routed) and reroute each net in turn, so as to minimize the value of the objective function for that net. (Some of the routings will in general have shorts or other design violations.)
Proceed to the next iterative pass until routing is complete and correct, is not further improved, or some other termination criterion is satisfied.

Most routers assign wiring layers to carry predominantly "x" or "y" directional wiring, though there have been routers which avoid or reduce the need for such assignment. There are advantages and disadvantages to each approach. Restricted directions make power supply design and the control of inter-layer crosstalk easier, but allowing arbitrary routes can reduce the need for vias and decrease the number of required wiring layers.

Z . O/I pROG FLASH BACK BASIC ROUTINE LANGUAGE ELECTRONIC IN FORM IC

BASIC (an acronym for Beginner's All-purpose Symbolic Instruction Code)^[1] is a family of general-purpose, high-level programming languages whose design philosophy emphasizes ease of use. In 1964, John G. Kemeny and Thomas E. Kurtz designed the original BASIC language at Dartmouth College in New Hampshire, United States. They wanted to enable students in fields other than science and mathematics to use computers. At the time, nearly all use of computers required writing custom software, which was something only scientists and mathematicians .
Versions of BASIC became widespread on microcomputers in the mid-1970s and 1980s. Microcomputers usually shipped with BASIC, often in the machine's firmware. Having an easy-to-learn language on these early personal computers allowed small business owners, professionals, hobbyists, and consultants to develop custom software on computer . In the 2010s, BASIC was popular in many computing dialects and in new languages influenced by BASIC, such as Microsoft's Visual Basic. In the 2010s, BASIC was popular in many computing dialects and in new languages influenced by BASIC, such as Microsoft's Visual Basic.

Before the mid-1960s, the only computers were huge mainframe computers. Users submitted jobs (calculations or other requests) on punched cards or similar media to specialist computer operators. The computer stored these, then used a batch processing system to run this queue of jobs one after another, allowing very high levels of utilization of these expensive machines. As the performance of computing hardware rose through the 1960s, multi-processing was developed. This allowed a mix of batch jobs to be run together, but the real revolution was the development of time-sharing. Time-sharing allowed multiple remote interactive users to share use of the computer, interacting with the computer from computer terminals with keyboards and teletype printers, and later display screens, in much the same way as desktop computers or personal computers would be used later.

Origin

The original BASIC language was released on May 1, 1964 by John G. Kemeny and Thomas E. Kurtz^[2] and implemented under their direction by a team of Dartmouth College students.^[3]^[4]^{[verification needed]} The acronym BASIC comes from the name of an unpublished paper by Thomas Kurtz.^[5] BASIC was designed to allow students to write mainframe computer programs for the Dartmouth Time-Sharing System. It was intended specifically for less technical users who did not have or want the mathematical background previously expected. Being able to use a computer to support teaching and research was quite novel at the time.
The language was based on FORTRAN II, with some influences from ALGOL 60 and with additions to make it suitable for timesharing. Initially, BASIC concentrated on supporting straightforward mathematical work, with matrix arithmetic support from its initial implementation as a batch language, and character string functionality being added by 1965. Wanting use of the language to become widespread, its designers made the compiler available free of charge. (In the 1960s, software became a chargeable commodity; until then, it was provided without charge as a service with the very expensive computers, usually available only to lease.) They also made it available to high schools in the Hanover, New Hampshire area and put considerable effort into promoting the language. In the following years, as other dialects of BASIC appeared, Kemeny and Kurtz's original BASIC dialect became known as Dartmouth BASIC

Spread on minicomputers

"Train Basic every day!" — reads a poster (bottom center) in a Russian school. (ca. 1985–1986)

Knowledge of the relatively simple BASIC became widespread for a computer language, and it was implemented by a number of manufacturers, becoming fairly popular on newer minicomputers such as the DEC PDP series, where BASIC-PLUS was an extended dialect for use on the RSTS/E time-sharing operating system. The BASIC language was available for the Data General Nova, and also central to the HP Time-Shared BASIC system in the late 1960s and early 1970s, where the language was implemented as an interpreter. A version was a core part of the Pick operating system from 1973 onward, where a compiler renders it into bytecode, able to be interpreted by a virtual machine.
During this period a number of simple computer games were written in BASIC, most notably Mike Mayfield's Star Trek. A number of these were collected by DEC employee David H. Ahl and published in a newsletter he compiled. He later collected a number of these into book form, 101 BASIC Computer Games, published in 1973.^[6] During the same period, Ahl was involved in the creation of a small computer for education use, an early personal computer. When management refused to support the concept, Ahl left DEC in 1974 to found the seminal computer magazine, Creative Computing. The book remained popular, and was re-published on several occasions.^[7]

Explosive growth: the home computer era

Commodore BASIC v2.0 on the Commodore 64

MSX BASIC version 3.0

The introduction of the first microcomputers in the mid-1970s was the start of explosive growth for BASIC. It had the advantage that it was fairly well known to the young designers and computer hobbyists who took an interest in microcomputers. Despite Dijkstra's famous judgement in 1975, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration",^[8] BASIC was one of the few languages that was both high-level enough to be usable by those without training and small enough to fit into the microcomputers of the day, making it the de facto standard programming language on early microcomputers.
One of the first BASICs to appear was Tiny BASIC, a simple BASIC variant designed by Dennis Allison at the urging of Bob Albrecht of the Homebrew Computer Club. He had seen BASIC on minicomputers and felt it would be the perfect match for new machines like the MITS Altair 8800. How to design and implement a stripped-down version of an interpreter for the BASIC language was covered in articles by Allison in the first three quarterly issues of the People's Computer Company newsletter published in 1975 and implementations with source code published in Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia: Running Light Without Overbyte. Versions were written by Li-Chen Wang and Tom Pittman.^[9] In 1975 MITS released Altair BASIC, developed by Bill Gates and Paul Allen as the company Micro-Soft,^[10] which eventually grew into corporate giant Microsoft. The first Altair version was co-written by Gates, Allen, and Monte Davidoff.
Almost universally, home computers of the 1980s had a ROM-resident BASIC interpreter, which the machines booted directly into.^{[notes 1]} When the Apple II, PET 2001, and TRS-80 were all released in 1977, all three had BASIC as their primary programming language and operating environment. Upon boot, a BASIC interpreter in immediate mode was presented, not the command-line interface used on systems running CP/M or MS-DOS. Commodore Business Machines included a version of Microsoft BASIC. The Apple II and TRS-80 each had two versions of BASIC, a smaller introductory version introduced with the initial releases of the machines and a more advanced version developed as interest in the platforms increased. As new companies entered the field, additional versions were added that subtly changed the BASIC family. The Atari 8-bit family had its own Atari BASIC that was modified in order to fit on an 8 kB ROM cartridge. The BBC published BBC BASIC, developed by Acorn Computers Ltd, incorporating many extra structured programming keywords and advanced floating-point operation features.
As the popularity of BASIC grew in this period, computer magazines published complete source code in BASIC for video games, utilities, and other programs. Given BASIC's straightforward nature, it was a simple matter to type in the code from the magazine and execute the program. Different magazines were published featuring programs for specific computers, though some BASIC programs were considered universal and could be used in machines running any variant of BASIC (sometimes with minor adaptations). Many books of type-in programs were also available, and in particular, Ahl published versions of the original 101 BASIC games converted into the Microsoft dialect and published it from Creative Computing as BASIC Computer Games. This book, and its sequels, provided hundreds of ready-to-go programs that could be easily converted to practically any BASIC-running platform.^[6]^[11]^[12] The book reached the stores in 1978, just as the home computer market was starting off, and it became the first million-selling computer book. Later packages, such as Learn to Program BASIC would also have gaming as an introductory focus. On the business-focused CP/M computers which soon became widespread in small business environments, Microsoft BASIC (MBASIC) was one of the leading applications.^[13]

IBM PC and compatibles

IBM Cassette BASIC 1.10

When IBM was designing the IBM PC they followed the paradigm of existing home computers in wanting to have a built-in BASIC. They sourced this from Microsoft – IBM Cassette BASIC – but Microsoft also produced several other versions of BASIC for MS-DOS/PC DOS including IBM Disk BASIC (BASIC D), IBM BASICA (BASIC A), GW-BASIC (a BASICA-compatible version that did not need IBM's ROM) and QBasic, all typically bundled with the machine. In addition they produced the Microsoft BASIC Compiler aimed at professional programmers. Turbo Pascal-publisher Borland published Turbo Basic 1.0 in 1985 (successor versions are still being marketed by the original author under the name PowerBASIC). Microsoft wrote the windowed AmigaBASIC that was supplied with version 1.1 of the pre-emptive multitasking GUI Amiga computers (late 1985 / early 1986), although the product unusually did not bear any Microsoft marks. These languages introduced many extensions to the original home-computer BASIC, such as improved string manipulation and graphics support, access to the file system and additional data types. More important were the facilities for structured programming, including additional control structures and proper subroutines supporting local variables. However, by the latter half of the 1980s, users were increasingly using pre-made applications written by others, rather than learning programming themselves, while professional programmers now had a wide range of more advanced languages available on small computers. C and later C++ became the languages of choice for professional "shrink wrap" application development.

Visual Basic

In 1991 Microsoft introduced Visual Basic, an evolutionary development of QuickBasic. It included constructs from that language such as block-structured control statements, parameterized subroutines, and optional static typing, as well as object-oriented constructs from other languages such as "With" and "For Each". The language retained some compatibility with its predecessors, such as the Dim keyword for declarations, "Gosub"/Return statements, and optional line numbers which could be used to locate errors. An important driver for the development of Visual Basic was as the new macro language for Microsoft Excel, a spreadsheet program. To the surprise of many at Microsoft who still initially marketed it as a language for hobbyists, the language came into widespread use for small custom business applications shortly after the release of VB version 3.0, which is widely considered the first relatively stable version. While many advanced programmers still scoffed at its use, VB met the needs of small businesses efficiently wherever ease of development was more of a concern than processing speed.
By that time, computers running Windows 3.1 had become fast enough that many business-related processes could be completed "in the blink of an eye" even using a "slow" language, as long as large amounts of data were not involved. Many small business owners found they could create their own small, yet useful applications in a few evenings to meet their own specialized needs. Eventually, during the lengthy lifetime of VB3, knowledge of Visual Basic had becomd. e a marketable job skill. Microsoft also produced VBScript in 1996 and Visual Basic .NET in 2001. The latter has essentially the same power as C# and Java but with syntax that reflects the original Basic language.

Three modern Basic variants: Mono Basic, OpenOffice.org Basic and Gambas

Post-1990 versions and dialects

Many other BASIC dialects have also sprung up since 1990, including the open source QB64 and FreeBASIC, inspired by QBasic, and the Visual Basic-styled RapidQ, Basic For Qt and Gambas. Modern commercial incarnations include PureBasic, PowerBASIC, Xojo, Monkey X and True BASIC (the direct successor to Dartmouth BASIC from a company controlled by Kurtz). Several web-based simple BASIC interpreters also now exist, including Quite BASIC and Microsoft's Small Basic (educational software). Versions of BASIC have been showing up for use on smartphones and tablets. Apple App Store contains such implementations of BASIC programming language as smart BASIC, Basic!, HotPaw Basic, BASIC-II, techBASIC and others. Android devices feature such implementations of BASIC as RFO BASIC and Mintoris Basic. Applications for some mobile computers with proprietary OS (CipherLab) can be built with programming environment based on BASIC. An application for the Nintendo 3DS and Nintendo DSi called Petit Computer allows for programming in a slightly modified version of BASIC with DS button support. A 3DS sequel was released in Japan in November 2014.

Calculators

Variants of BASIC are available on graphing and otherwise programmable calculators made by Texas Instruments, HP, Casio, and others.

Windows command line

QBasic, a version of Microsoft QuickBASIC without the linker to make EXE files, is present in the Windows NT and DOS-Windows 95 streams of operating systems and can be obtained for more recent releases like Windows 7 which do not have them. Prior to DOS 5, the Basic interpreter was GW-Basic. QuickBasic is part of a series of three languages issued by Microsoft for the home and office power user and small scale professional development; QuickC and QuickPascal are the other two. For Windows 95 and 98, which do not have QBasic installed by default, they can be copied from the installation disc, which will have a set of directories for old and optional software; other missing commands like Exe2Bin and others are in these same directories.

other

BASIC came to some video game systems, such as the Nintendo Famicom.

The various Microsoft, Lotus, and Corel office suites and related products are programmable with Visual Basic in one form or another, including LotusScript, which is very similar to VBA 6. The Host Explorer terminal emulator uses WWB as a macro language; or more recently the programme and the suite in which it is contained is programmable in an in-house Basic variant known as Hummingbird Basic. The VBScript variant is used for programming web content, Outlook 97, Internet Explorer, and the Windows Script Host. WSH also has a Visual Basic for Applications (VBA) engine installed as the third of the default engines along with VBScript, JScript, and the numerous proprietary or open source engines which can be installed like PerlScript, a couple of Rexx-based engines, Python, Ruby, Tcl, Delphi, XLNT, PHP, and others; meaning that the two versions of Basic can be used along with the other mentioned languages, as well as LotusScript, in a WSF file, through the component object model, and other WSH and VBA constructions. VBScript is one of the languages that can be accessed by the 4Dos, 4NT, and Take Command enhanced shells. SaxBasic and WWB are also very similar to the Visual Basic line of Basic implementations. The pre-Office 97 macro language for Microsoft Word is known as WordBASIC. Excel 4 and 5 use Visual Basic itself as a macro language. Chipmunk Basic, an old school interpreter similar to BASICs of the 1970s, is available for GNU/Linux, Microsoft Windows and macOS.

Nostalgia

The ubiquity of BASIC interpreters on personal computers was such that textbooks once included simple "Try It In BASIC" exercises that encouraged students to experiment with mathematical and computational concepts on classroom or home computers. Popular computer magazines of the day typically included type-in programs.
Futurist and sci-fi writer David Brin mourned the loss of ubiquitous BASIC in a 2006 Salon article^[16] as have others who first used computers during this era. In turn, the article prompted Microsoft to develop and release Small Basic.^[17] Dartmouth held a 50th anniversary celebration for BASIC on 1 May 2014,^[18] as did other organisations; at least one organisation of VBA programmers organised a 35th anniversary observance in 1999.^[19]
Dartmouth College celebrated the 50th anniversary of the BASIC language with a day of events^[20] on April 30, 2014. A short documentary film^[21] was produced for the event.

Syntax

Typical BASIC keywords

Data manipulation

LET—assigns a value (which may be the result of an expression) to a variable.
DATA—holds a list of values which are assigned sequentially using the READ command.

Program flow control

IF ... THEN ... ELSE—used to perform comparisons or make decisions.
FOR ... TO ... {STEP} ... NEXT—repeat a section of code a given number of times. A variable that acts as a counter is available within the loop.
WHILE ... WEND and REPEAT ... UNTIL—repeat a section of code while the specified condition is true. The condition may be evaluated before each iteration of the loop, or after.
DO ... LOOP {WHILE} or {UNTIL}—repeat a section of code Forever or While/Until the specified condition is true. The condition may be evaluated before each iteration of the loop, or after.
GOTO—jumps to a numbered or labelled line in the program.
GOSUB—jumps to a numbered or labelled line, executes the code it finds there until it reaches a RETURN Command, on which it jumps back to the operator following the GOSUB – either after a colon, or on the next line. This is used to implement subroutines.
ON ... GOTO/GOSUB—chooses where to jump based on the specified conditions. See Switch statement for other forms.
DEF FN—a pair of keywords introduced in the early 1960s to define functions. The original BASIC functions were modeled on FORTRAN single-line functions. BASIC functions were one expression with variable arguments, rather than subroutines, with a syntax on the model of DEF FND(x) = x*x at the beginning of a program. Function names were originally restricted to FN+one letter.

Input and output

LIST—displays all inputted code.
PRINT—displays a message on the screen or other output device.
INPUT—asks the user to enter the value of a variable. The statement may include a prompt message.
TAB or AT: sets the position where the next character will be shown on the screen or printed on paper.

List of functions

ABS—Absolute value
ATN—Arctangent value (result in radians)
COS—Cosine value (argument in radians)
EXP—Exponential value
INT—Integer value
LOG—Natural Logarithmic value
RND—Random value
SIN—Sine value (argument in radians)
SQR—Square root value
TAN—Tangent value (argument in radians)

Miscellaneous

REM—holds a programmer's comment or REMark; often used to give a title to the program and to help identify the purpose of a given section of code.
USR—transfers program control to a machine language subroutine, usually entered as an alphanumeric string or in a list of DATA statements.
TRON—turns on display of each line number as it is run ("TRace ON"). This was useful for debugging or correcting of problems in a program.
TROFF—turns off the display line numbers.
ASM—some compilers such as Freebasic,^[22] Purebasic,^[23] and Powerbasic^[24] also support inline assembly language, allowing the programmer to intermix high-level and low-level code, typically prefixed with "ASM" or "!" statements.

Data types and variables

Minimal versions of BASIC had only integer variables and one- or two-letter variable names, which minimized requirements of limited and expensive memory (RAM). More powerful versions had floating-point arithmetic, and variables could be labelled with names six or more characters long. There were some problems and restrictions in early implementations; for example, Applesoft allowed variable names to be several characters long, but only the first two were significant, thus it was possible to inadvertently write a program with variables "LOSS" and "LOAN", which would be treated as being the same; assigning a value to "LOAN" would silently overwrite the value intended as "LOSS". Keywords could not be used in variables in many early BASICs; "SCORE" would be interpreted as "SC" OR "E", where OR was a keyword. String variables are usually distinguished in many microcomputer dialects by having $ suffixed to their name, and values are often identified as strings by being delimited by "double quotation marks". Arrays in BASIC could contain integers, floating point or string variables.
Some dialects of BASIC supported matrices and matrix operations, useful for the solution of sets of simultaneous linear algebraic equations. These dialects would directly support matrix operations such as assignment, addition, multiplication (of compatible matrix types), and evaluation of a determinant. Many microcomputer BASICs did not support this data type; matrix operations were still possible, but had to be programmed explicitly on array elements.

Examples

Unstructured BASIC

The original Dartmouth Basic was unusual in having a matrix keyword, MAT.^{[notes 2]} Although dropped by most later microprocessor derivatives it is used in this example from the 1968 manual^[25] which averages the numbers that are input:

5 LET S = 0
10 MAT INPUT V 
20 LET N = NUM 
30 IF N = 0 THEN 99 
40 FOR I = 1 TO N 
45 LET S = S + V(I) 
50 NEXT I 
60 PRINT S/N 
70 GO TO 5 
99 END

New BASIC programmers on a home computer might start with a simple program, perhaps using the language's PRINT statement to display a message on the screen; a well-known and often-replicated example is Kernighan and Ritchie's Hello world program:

10 PRINT "Hello, World!"
20 END

An infinite loop could be used to fill the display with the message.
Most first-generation BASIC versions such as MSX BASIC and GW-BASIC supported simple data types, loop cycles, and arrays. The following example is written for GW-BASIC, but will work in most versions of BASIC with minimal changes:

10 INPUT "What is your name: "; U$
20 PRINT "Hello "; U$
30 INPUT "How many stars do you want: "; N
40 S$ = ""
50 FOR I = 1 TO N
60 S$ = S$ + "*"
70 NEXT I
80 PRINT S$
90 INPUT "Do you want more stars? "; A$
100 IF LEN(A$) = 0 THEN GOTO 90
110 A$ = LEFT$(A$, 1)
120 IF A$ = "Y" OR A$ = "y" THEN GOTO 30
130 PRINT "Goodbye "; U$
140 END

The resulting dialog might resemble:

What is your name: Mike
Hello Mike
How many stars do you want: 7
*******
Do you want more stars? yes
How many stars do you want: 3
***
Do you want more stars? no
Goodbye Mike

Structured BASIC

Second-generation BASICs (for example, VAX Basic, SuperBASIC, True BASIC, QuickBASIC, BBC BASIC, Pick BASIC and PowerBASIC) introduced a number of features into the language, primarily related to structured and procedure-oriented programming. Usually, line numbering is omitted from the language and replaced with labels (for GOTO) and procedures to encourage easier and more flexible design.^[26] In addition keywords and structures to support repetition, selection and procedures with local variables were introduced.
The following example is in QuickBASIC:

DECLARE SUB PrintSomeStars (StarCount!)
REM QuickBASIC example
INPUT "What is your name: ", UserName$
PRINT "Hello "; UserName$
DO
   INPUT "How many stars do you want: ", NumStars
   CALL PrintSomeStars(NumStars)
   DO
      INPUT "Do you want more stars? ", Answer$
   LOOP UNTIL Answer$ <> ""
   Answer$ = LEFT$(Answer$, 1)
LOOP WHILE UCASE$(Answer$) = "Y"
PRINT "Goodbye "; UserName$
END

SUB PrintSomeStars (StarCount)
   REM This procedure uses a local variable called Stars$
   Stars$ = STRING$(StarCount, "*")
   PRINT Stars$
END SUB

Object-oriented BASIC

Third-generation BASIC dialects such as Visual Basic, Xojo, StarOffice Basic and BlitzMax introduced features to support object-oriented and event-driven programming paradigm. Most built-in procedures and functions are now represented as methods of standard objects rather than operators. Also, the Operating System became more and more available to the BASIC language.
The following example is in Visual Basic .NET:

Public Class StarsProgram
   Public Shared Sub Main()
      Dim UserName, Answer, stars As String, NumStars As Integer
      Console.Write("What is your name: ")
      UserName = Console.ReadLine()
      Console.WriteLine("Hello {0}", UserName)
      Do
         Console.Write("How many stars do you want: ")
         NumStars = CInt(Console.ReadLine())
         stars = New String("*", NumStars)
         Console.WriteLine(stars)
         Do
            Console.Write("Do you want more stars? ")
            Answer = Console.ReadLine()
         Loop Until Answer <> ""
         Answer = Answer.Substring(0, 1)
      Loop While Answer.ToUpper() = "Y"
      Console.WriteLine("Goodbye {0}", UserName)
   End Sub
End Class

Standards

ANSI/ISO/IEC Standard for Minimal BASIC:
- ANSI X3.60-1978 "For minimal BASIC"
- ISO/IEC 6373:1984 "Data Processing — Programming Languages — Minimal BASIC"
ECMA-55 Minimal BASIC (withdrawn, similar to ANSI X3.60-1978)
ANSI/ISO/IEC Standard for Full BASIC:
- ANSI X3.113-1987 "Programming Languages Full BASIC"
- INCITS/ISO/IEC 10279-1991 (R2005) "Information Technology – Programming Languages – Full BASIC"
ANSI/ISO/IEC Addendum Defining Modules:
- ANSI X3.113 Interpretations-1992 "BASIC Technical Information Bulletin # 1 Interpretations of ANSI 03.113-1987"
- ISO/IEC 10279:1991/ Amd 1:1994 "Modules and Single Character Input Enhancement"
ECMA-116 BASIC (withdrawn, similar to ANSI X3.113-1987)

List of BASIC dialects

This is an alphabetical list of BASIC dialects—interpreted and compiled variants of the BASIC programming language. Each dialect's platform(s), i.e., the computer models and operating systems, are given in parentheses along with any other significant information.

Dialects

0–9 ( HUMAN NUMERIC PASSING PASS )

BASIC dialect	Description
1771-DB BASIC	Allen-Bradley PLC industrial controller BASIC module; Intel BASIC-52 extended with PLC-specific calls.

A

BASIC dialect	Description
ABasiC (Amiga)	Relatively limited. Initially provided with Amigas by MetaComCo.
ABC BASIC	designed for the ABC 80 and ABC 800 line of computers designed by Dataindustrier AB and manufactured by Luxor AB (including ABC 802, ABC 806 etc.).
ACE (Amiga)	A Compiler for Everyone—Freeware, AmigaBASIC compatible, has extra features, some of which exploit the Amiga's hardware and operating system.^[1]
Advan BASIC	For the Atari home computer, disk based, containing BASIC, compiler, screen design and utilities. Released to public domain July, 2006 ^[2]
Advanced BASIC	(a.k.a. BASIC Advanced, Advanced BASIC) (DOS on the PC)—By Microsoft. Available in ROM on IBM PCs. Later disk based versions for IBM PC DOS.
AlphaBasic
Altair BASIC	(a.k.a. MITS 4K BASIC, MITS 8K BASIC, Altair Disk Extended BASIC) (Altair 8800, S-100)—Microsoft's first product
Altair Disk Extended BASIC	See Altair BASIC
Amiga BASIC (Amiga)	Somewhat easier than ABasiC, see MS BASIC for Macintosh.
AmiBlitz (Amiga)	Opensource version of Blitz BASIC.^[3]
AMOS BASIC (Amiga)	For the Amiga, made for game programming. A descendant of STOS BASIC on the Atari ST. Later derivatives included AMOS Professional (a.k.a. AMOS Pro) and Easy AMOS.
ANSI	Standard for the programming language Minimal BASIC X3.60-1978, a 1978 standard for minimal features, and X3.113-1987, the full BASIC standard; rarely implemented fully.
Apple BASIC (Apple I)	See: Integer BASIC
Apple Business BASIC (Apple III)
Applesoft BASIC (Apple II series)	Based on the same Microsoft code that Commodore BASIC was based on. Standard on the Apple II Plus/Apple II Europlus and all later models of the Apple II family.
APU BASIC	version of SORD CBASIC for the M23 with arithmetic processor
Aribas	interactive interpreter for big integer arithmetic and multi-precision floating point arithmetic with a Pascal/Modula like syntax. It has several builtin functions for algorithmic number theory like gcd, Jacobi symbol, Rabin probabilistic prime test, factorization algorithms (Pollard rho, elliptic curve, continued fraction, quadratic sieve), etc.
ASIC	(DOS on the PC)
Atari 2600 Basic Programming	(Atari 2600 video game console)
Atari BASIC (Atari 8-bit family)	The standard cartridge-based interpreter for the Atari 400/800 personal computers and successors. On later machines, such as the Atari 800XL, this was built into the ROM.
Atari Microsoft BASIC (Atari 8-bit family)	ROM cartridge plus disk-based extensions.
AT&T	interpreter and compiler for the AT&T 3B1 UNIX PC.
AttoBasic	ROM-resident interpreter, executes from on-chip RAM (Atmel AVR)^[4]
Atom BASIC (Acorn Atom)
AutoIt (Microsoft Windows)	automates other programs, e.g. with simulated mouse clicks. Interpreted. GUI. Creates EXEs.

B

BASIC dialect	Description
B32 Business Basic	(Data General Eclipse MV, Unix, DOS)
BaCon	(Unix, BSD, Mac OS X)—Basic to C converter based on shell script^[5]
BAIT	short for BASIC (Almost) InTerpreter was an experimental BASIC interpreter written in Atari (8-bit) BASIC for Compute! Magazine by Bill Wilkinson.
Bas	(Unix)—Interpreter for the classic BASIC dialect^[6]
Bas7	(Unix, Linux, BSD, Microsoft Windows, Mac OS X) A BASIC interpreter, written in Seed7, which is compatible to GW-BASIC and other old BASIC dialects^[7]
Banna Basic	(Microsoft Windows)—putatively under development by Leodescal Softwares; the first officially launched version is supposed to produce stand-alone executables
BASCOM	Compilers for the 8051 and AVR chips
Basic+	programming language for OpenInsight
BASIC 2.0	(see Commodore BASIC)
BASIC 7.0	(see Commodore BASIC)
BASIC A+	(Atari 8-bit family)—An extended BASIC for the Atari 8-bit family, by Optimized Systems Software
BASIC Advanced	See IBM BASICA
BASIC Programming	(Atari CX-2620) was a simple attempt of the BASIC language for the Atari 2600 Video Computer System
BASIC XE	(Atari 8-bit family)—An enhanced version of BASIC XL, by Optimized Systems Software^[8]
BASIC XL	(Atari 8-bit family)—Improved BASIC for the Atari 8-bit family, by Optimized Systems Software^[8]
Basic4GL	Fast interpreter meant for OpenGL graphical programming (especially games)
BASIC-11	(DEC PDP-11, RSX-11)
Basic-256	(Microsoft Windows, Linux, Unix)—BASIC IDE with text and graphics output, written to introduce children to programming. Originally known as KidBASIC.^[9]
BASIC-52	(Intel 8052)
BASIC-68K	structured BASIC for the SORD M68/M68MX computers running in CP/M-68K mode
BASIC-E	(a.k.a. submarine BASIC) (CP/M)
BASIC-II	structured BASIC for 8-bit SORD computers
BASIC Plus 2	(DEC PDP-11: RSTS/E, RSX-11)
BASIC-PLUS	(DEC PDP-11: RSTS/E)
BASIC/UX	HP BASIC for HP-UX, version of Rocky Mountain BASIC
BASIC/WS	HP BASIC Workstation
BASIC/Z	(CP/M, MDOS)
BASIC09	(OS-9 and OS-9 68K on Motorola 6809 and 68K CPUs, respectively)
BASICA	(a.k.a. BASIC Advanced, Advanced BASIC) (DOS on the PC)—By Microsoft. Available in ROM on IBM PCs. Later disk based versions for IBM PC DOS.
BASICODE	(KC 85) de:BASICODE
Basic For Qt	(Mac OS X, Linux and Windows)—Platform independent BASIC. Object-oriented Visual Basic-like Basic variant. Based on Qt. (previously, KBASIC)^[10]
BasiEgaXorz	(Sega Genesis)—for the Sega Genesis^[11]
batari BASIC	version primarily used for homebrew Atari 2600 development.^[12]
BBC BASIC	Originally for the Acorn/BBC Micro, but has since been ported to RISC OS, Tiki 100, Cambridge Z88, Amstrad NC100, CP/M, ZX Spectrum, DOS, Microsoft Windows and many others.^[13] A GPL clone of BBC BASIC named Brandy^[14] written in portable C is also available (RISC OS, NetBSD, OpenBSD, FreeBSD, Linux, Mac OS X, AmigaOS, DOS). Also a port made for the Commodore 64 by Aztec Software, written by Julian Gardner.
Bazic '86	See Northstar BASIC
BBx	(Microsoft Windows, Linux, Unix)—Cross-platform program development language derived from Business Basic.
BCX	small command line tool that inputs a BCX BASIC source code file and outputs a 'C' source code file which can be compiled with many C or C++ compilers.
BEOWULF	{Beginner Extended Object with Ultra Language Functionality}^[15]]
Beta BASIC	BASIC toolkit that extended Sinclair BASIC.
BetterBASIC	BASIC implementation by Summit Software Technologies, first available in the early 1980s. It was later maintained by Michael Poremski.
BI-280	Business BASIC interpreter (CP/M, MP/M) by Control C Corporation, Beaverton, Oregon.
Blitz3D	(Microsoft Windows) Fast compiler made for 3D game programming, with DirectX 7 support.
Blitz BASIC	(Amiga, Windows)—Fast compiler meant for game programming. Windows version with DirectX support. Discontinued, replaced by BlitzPlus.
BlitzMax	(macOS, Linux, Windows)—Fast and compact object-oriented compiler meant for several tasks, most notably Game programming with OpenGL and DirectX support (DirectX support is Windows only).
BlitzPlus	(Microsoft Windows) Fast compiler made for 2D game programming and WinAPI event based interpreted programming. Supports both DirectX and OpenGL.
Blunt Axe Basic	(a.k.a. BXBASM) (Win32, Linux)^[16] Bxbasic is presented as a programming tutorial, to develop and construct a Console Mode Scripting Engine and Byte Code Compiler.
Bsisith	Hebrew dialect.
BT-Basic	Board Test Basic, used by HP (later Agilent, then Keysight) to develop and run test programs in an in-circuit test environment
BURP	Basic Using Reverse Polish, used by the very early PSI Comp 80 "scientific computer", as published in the British radio enthusiasts magazine Wireless World
Business Basic	name given collectively to BASIC variants which were specialized for business use on minicomputers in the 1970s.
bwBASIC	See Bywater BASIC
BWBASIC	"ByteWide BASIC", a stand-alone Z-80 bitwise port of Tiny BASIC - co developed by Pro-Log Corporation and ByteWide Systems, Australia. Intended for control applications.
BXBASM	See Blunt_Ane_Basic
Bywater BASIC	(a.k.a. bwBASIC)—an open source interpreter for DOS and POSIX. Bwbasic contains only a small portion of the ANSI BASIC commands. Its main advantage is that one can also use shell commands in programs, an unusual feature in any BASIC implementation. It could theoretically be used as the main shell on a DOS or POSIX system, with some advantages.^[17]

C

BASIC dialect	Description
CA-Realizer	dialect similar to VisualBasic by Computer Associates, last version 3.0, no longer under development/supported
Caché Basic	One of the two scripting languages in the Caché Database
CARDBASIC	version of BASIC operated by cards available in Dartmouth when that language was created and described in the original manual
Casio BASIC	used in Casio calculators
Cassette BASIC	An interpreter on IBM and IBM compatible PCs to which the machine will default if no operating system is detected.
CBASIC (CP/M, DOS)	BASIC-E successor.
CBASIC	standard interpreter for 8-bit SORD computers (M23, M68 in Z80 mode, etc.), a.k.a. APU BASIC when the arithmetic processor is installed
cbasPad Pro	See HotPaw Basic
CBM BASIC	See Commodore BASIC
CellularBASIC	Java ME open source on-phone mobile interpreter for Java-enabled handheld devices, mobiles, smartphones, and PDAs
Chinese BASIC	Several Chinese-translated BASIC languages developed in the early 1980s.
Chipmunk Basic	(Apple Macintosh, CLI ports for Win32, Linux)—copyrighted freeware
CGIbasic	small and fast interpreter for web-scripting.
CipherLab Basic	tool to develop application programs for CipherLab 8 Series Mobile Computers using BASIC programming language
CocoaBasic	(Mac OS X)—Object-oriented dialect for using the Cocoa Framework^[18]
Color BASIC	(Tandy / RadioShack TRS-80 Color Computer)
Commodore BASIC	(a.k.a. CBM BASIC) (Various computers in CBM's line of 8-bit computers)—Was integrated in the ROM of CBM's 8-bit computers. Built on an early version of 6502 Microsoft BASIC. There were several versions—the best-known was Commodore Basic V2, as used in the Commodore 64.
Compaq BASIC for OpenVMS	DEC BASIC, renamed after DEC was acquired by Compaq. Now called HP BASIC for OpenVMS.
CoolBasic	(Windows)—A variant suited for game programming with DirectX.^[19]^[20] fi:Coolbasic
Creative Basic	(Windows)^[21]
Cubloc Basic	(Comfile Technologies)—Interpreter for the Cubloc controller
(Cybiko)	Interpreter for the Cybiko Handheld Computer for Teens
Cybiko B2C	(Cybiko)—A BASIC to C compiler for the Cybiko Handheld Computer for Teens
Cypress BASIC	(Windows)—a royalty-free VBA compatible scripting engine embedded, e.g., within HP's AssetCenter product for implementing customizations^[22]

D

BASIC dialect	Description
DAI BASIC	a very early BASIC interpreter for the Intel 8080 based DAI Personal Computer that used java-like pre-compilation.
DarkBASIC & DarkBASIC Professional	(Windows)—Efficient compiler for game programming.
Dartmouth BASIC	the original BASIC version. See also True BASIC.
Data General Business Basic	(Data General Nova and later DG minicomputers)
Data/BASIC	See: Pick/BASIC for use on the Pick Operating System
Databasic	See: Pick/BASIC for use on the Pick Operating System
DBASIC	fast nonstandard BASIC for the Atari ST written entirely in machine language
DEC BASIC	Formerly VAX BASIC; renamed after VAX/VMS was ported to Alpha processors and renamed OpenVMS. Now called HP BASIC for OpenVMS due to corporate acquisitions.
Decimal BASIC	Japanese multi-platform Basic interpreter ^[23] compatible almost 100% with ISO/IEC 10279:1991 or later
DragonBASIC	for GBA handheld video game; also useful for Nintendo DS homebrew.^[24] Dragon Basic is a sort of cross-compiler with IDE that runs on Microsoft Windows.
D-Lib	for (Microsoft Windows) is a Freeware BASIC compiler that creates bytecode executables.

E

BASIC dialect	Description
Easy AMOS	See AMOS BASIC
Emergence Basic	(Windows)^[21]
Envelop Basic	(Windows)—Visual Basic 3 clone.
Envision Basic
ethosBASIC	(Windows)—ethosBASIC is a new BASIC development system made to create computer games.^[25]
Extended Color BASIC	(TRS-80 Color Computer and Dragon 32/64)

F

BASIC dialect	Description
FaST Basic	(Atari ST)
Famicom BASIC	(Nintendo Entertainment System)—For the Nintendo Entertainment System.
FBSL	(Windows, Linux on WinE)—FREESTYLE Basic Script Language^[26]
FirST Basic	(Atari ST)
FreeBASIC	(DOS (DPMI32), MS Windows and Linux)—An open source (GPL) BASIC compiler, that employs a similar syntax to QuickBASIC's, with more advanced features like pointers and object-oriented programming, it also supports a dialect specially designed to be compatible with QuickBASIC.
FutureBASIC	(Mac OS)—Free compiled, procedural, provides access to Carbon API (Mac OS Toolbox), GUI and file system of System 6 to Mac OS X^[27]
FUZE BASIC	(MS Windows and Linux)—Highly modernized adaptation of classic BASIC.

G

BASIC dialect	Description
Galaksija BASIC	(Galaksija)—Firmware version for Galaksija home computer.
Gambas	(Linux / Unix / Cygwin)—A rapid application development environment for BASIC on Linux by Benoît Minisini. Similar approach as Visual Basic.
GamesBasic	Free object-oriented BASIC variant meant for game programming.
GBasic	(DOS on the PC)—Interpreter with many graphics routines.
GBasic	( on the ZVT PP 01)—Interpreter with many graphics routines, Made in Czechoslovakia 80's
G-BASIC	version of SORD CBASIC with SORD Graphic Language extensions for the M23 with graphics board
GeoBASIC	(Leica TPS 1000/1100 surveying stations)
geoBASIC	(Commodore 64)—For use with GEOS
GFA BASIC	(Atari ST, Amiga, DOS, Windows)—Originally conceived on the Atari ST where it became one of the most popular BASICs for that platform (it almost became a standard language for the Atari ST). Was later ported to the Amiga, DOS and Windows.
GLBasic	(main target platforms: Windows, Linux, Apple iPhone, Pocket PC. IDE environment: Windows)—optimized for games
Gnome Basic	(Linux/Unix)—project to develop a Visual Basic compatible clone for Gnome. During development, the project was discontinued.
Graphics BASIC	(Commodore 64)—extension to the original Commodore 64 BASIC V2.
Great Cow BASIC	(Microchip PIC)—Open source compiler for 10/12/16 series PIC and AVR microcontrollers.
GW-BASIC	(DOS and Windows)—By Microsoft. BASICA compatible; independent of IBM ROM routines. Came with versions of MS-DOS before 5.0. Included music macro language and advanced loops.

H

BASIC dialect	Description
HBasic	(Linux / Unix)—Object-oriented open source IDE. HBasic based on Qt IDE and a BASIC dialect. Similar approach as Visual Basic.
HiSoft Basic	(Amiga, Atari ST, ZX Spectrum)
High Tech BASIC	Version of Rocky Mountain BASIC by TransEra
HotBasic	(Win32, Linux)—Simple but powerful compiler, emits machine code. Supports GUI, console, CGI, and database programming.
HotPaw Basic	(a.k.a. yBasic, née cbasPad Pro) (Palm OS)—Interpreter with GUI and sound functions.^[28]
HP BASIC	The original Version of Rocky Mountain BASIC
HP Instrument BASIC	Another name for HP Rocky Mountain BASIC
HRAST BASIC	For HP-48G/G+/GX, HP-49G and HP-49G+/50G calculators.
HP BASIC for OpenVMS	Originally VAX BASIC; renamed to DEC BASIC after VAX/VMS was ported from VAX to Alpha processors; renamed to Compaq BASIC after Compaq acquired DEC; renamed to present name after HP acquired Compaq.
HP Basic	version on the HP 39 and 40 programmable calculators.
HP Time-Shared BASIC	(HP 2100 line of minicomputers)
HTBasic	Version of Rocky Mountain BASIC by TransEra
Hummingbird Basic	The automation facility in Hummingbird Connectivity; it replaced WinWrap Basic after version 4

I

BASIC dialect	Description
IBasic	(Windows)—With Windows API and DirectX support.
IBM Cassette BASIC	(PC)—Built into the first IBM PCs. Ran independently of DOS and used audio cassettes as a storage medium.
IBM VS-BASIC	Mainframe hybrid compiler/interpreter implementation frequently used with such operating systems as McGill University's MUSIC/SP.
ICPL	(Computervision CADDS-2/VLSI)—Interpreter tied into an integrated circuit design database.
INFOBASIC	Used on Prime Computers, a variant of Pick BASIC for use on the Pick Operating System
Integer BASIC	(Apple II series)—Steve Wozniak's own creation. Originally known simply as "Apple BASIC". For the BASICs available at the time, it was very fast and memory-efficient. Only supported integers. Came as standard on the Apple I and original Apple II
Internet Basic	Written for use with the Comet system. Both were created by Signature Systems.
IS-BASIC	The interpreter of the Enterprise 64 and 128 home computers, written by Intelligent Software Ltd.
IWBasic	(Windows) A version of Basic that generates native machine code so no runtime libraries are needed.
iziBasic	(Palm OS) Easy-to-use compiler that runs on Palm OS devices and emits stand-alone programs. Includes terminal mode and support for Palm OS GUI.^[29]

J

BASIC dialect	Description
Jabaco	simple object-oriented programming language to build applications/applets on the Java Framework.^[30]
Just BASIC	restricted "free" version of Liberty BASIC (Windows only)
JBasic	a "classic" implementation of BASIC written entirely in Java.^[31]
jvmBasic	An implementation of BASIC which compiles to Java Bytecode^[32]

BASIC dialect	Description
Kool-Bee	See KoolB
KoolB	(short for Kool-Bee) (Windows, Linux)—Open source compiler, minimal, made mainly for learning purposes.^[33]
KBasic	Basic for Qt ^[34]

L

BASIC dialect	Description
Liberty BASIC	(Windows, Mac, Linux)—Multiparadigm object oriented IDE system
LikeBASIC	(Windows)—Basic interpreter component for applications in the .NET framework environment
Locomotive BASIC	(Amstrad CPC)—built into the ROM of the Amstrad CPC
LotusScript	(IBM Lotus Notes)
LowRes Coder	(iOS)—App to create retro-style games or demos in BASIC.
Luxor Basic	(Luxor ABC 80)
Learn to Program BASIC	(Windows 95–98, Macintosh 7.5–9)—youth-oriented version, with interactive lessons to teach the user how to program

M

BASIC dialect	Description
M2000	dual vocabulary (Greek-English) Interpreter in own environment - Open Source- Written in Vb6.
MacBASIC	Apple's original BASIC for the Macintosh, released as Beta software and discontinued due to a deal with Microsoft
MAI Basic Four Business Basic	(misc. minicomputers)
Mallard BASIC	(Amstrad PCW, ZX Spectrum +3 on CP/M)—Similar to Locomotive BASIC
MapBasic	procedural language used specifically for GIS programs.
MasmBasic	over 100 BASIC-style macros for the Microsoft Macro Assembler; requires the Masm32 package.
MBASIC	(CP/M)—Further development of OBASIC, also by Microsoft. MBasic was one of the BASICs developed by Microsoft. Came with a line editor.
MELFA BASIC	used by certain Mitsubishi robots and simulation packages.
METRIC-BASIC	also known as Uppsala-BASIC
MelloCOMPLEX	Based on "COMPLEX", a variant of BASIC
MICOL BASIC	Compiled Basic based upon elements of C for the Apple ][ gs platform
Microsoft BASIC	many versions for several different CPUs and system architectures exist, and many other BASICs are derivatives of some Microsoft BASIC
Microsoft BASICA	See BASICA
Microsoft GW-BASIC	GW-BASIC
Microsoft Small Basic
Microsoft Level III BASIC	(Tandy / RadioShack TRS-80)
Microsoft Visual Basic	Visual Basic
MinimalBASIC	A compiler for ECMA-55 Minimal BASIC emitting GNU as assembly targeting 64bit x86-64 Linux^[35]
MITS 4K BASIC	Altair BASIC
MITS 8K BASIC	Altair BASIC
MMBasic	The GWBasic Clone used by the Maximite Microcomputer
Mobile BASIC	(Java enabled mobile phones)
MOLE Basic	(DOS on the PC)—Merty's Own Language Extension BASIC
Moonrock Basic Compiler	(DOS on the PC)—Small compiler
Monkey	(Supports various platforms, see page for details)—A simple but powerful programming language built primarily for Game programming
Morfik Basic	Object-oriented dialect that can used to create Web applications, server and browser client-side code. (Web)
MS BASIC for Macintosh	(Mac OS)
MSX BASIC	(MSX)—By Microsoft

N

BASIC dialect	Description
N82-BASIC	(Old NEC PC8201/8201A)
N88-BASIC	(Old NEC PC8801/9801)—Japan's most popular BASIC based on Microsoft's one
N.A.M.E. Basic	compiles into bytecode to run on the Java Virtual Machine. Can also run in interpreted mode on the JVM
Nevada BASIC	Ellis Computing Eight-bit CP/M, had 12 digit precision and matrix operations. A port of Processor Technology 8 KB BASIC
NorthStar BASIC	(Processor Technology, NorthStar Horizon, later adapted to x86 as Bazic '86) and S.A.I.L.B.O.A.T. (a basic optimized for Z80 and X86 MS-DOS)
NS Basic	(Newton OS, Symbian OS, Palm OS, Windows CE, Windows Mobile, Microsoft Windows )—IDE and Bytecode-interpreter
nuBASIC	(Linux, Microsoft Windows )— Interpreter written in C++11 for educational purposes.^[36]^[37]^[38]

O

BASIC dialect	Description
Oasis Basic	see THEOS Multi-User Basic
OBASIC	(CP/M)—by Microsoft
Omikron Basic	(Atari ST, Mac OS)—Originally developed by Omikron Software for Atari ST.^[39] In Germany it was bundled with new Atari STs for a long time. Was later ported to the classic Mac OS and was further developed for Mac OS X.
OpenBASIC	developed by MAI Systems Corporation, Inc.
Open Programming Language OPL	(Symbian OS phones and PDAs)—Originally developed for Psion's product line of organisers and PDAs. OPL used to stand for Organiser Programming Language but after becoming open source in 2003, it was renamed. Available for most of Psion's classic organisers and PDAs, Nokia 9210/9290/9300/9500 Communicators and Sony Ericsson P800/P900/P910.
OWBasic	(Pocketviewer (Casio pda))—Fast compiler/interpreter system, Open Source^[40]

P

BASIC dialect	Description
Panoramic (computer language)	For Windows, able to handle 3D world and many Windows objects.^[41]
Parrot BASIC	For the Parrot virtual machine; V 1.0 is modeled on GW-BASIC, V 2.0 is modeled on Microsoft QuickBASIC version 4.5^[42]
PBASIC	for use with the Parallax BASIC Stamp microcontroller
PeayBASIC	hand-written interpreter in C# for simple text and graphics output
Phoenix Object Basic	(Linux / Unix)—free, includes GUI builder
PIC BASIC	for use with microcontrollers
PIC BASIC Pro	aka PBP—for use with PIC microcontrollers^[43]
PICAXE BASIC	for use with PICAXE microcontrollers
Pick/BASIC	(a.k.a. Data/BASIC, Databasic) (Pick operating system)—a BASIC language, extended for business use, and embedded into the Pick environment and variations of it.
PlayBASIC	(Microsoft Windows)—Fast and feature rich, focused on 2D game development.^[44]
PowerBASIC	(DOS, Win16, Win32)—free and commercial compilers for DOS and Windows, which focus on fast compile speeds and small binaries. They are Turbo Basic successors.
Profan	(Windows)—easy to use, interpreted
Processor Technology	5 KB and 8 KB BASICs. Created for the SOL-20 computer, but widely ported to other platforms as Processor Technology published the 8080 source code. Nevada BASIC (CP/M) and Utah BASIC [MS-DOS] were the latest ports.
ProvideX	(Microsoft Windows, Linux, Unix)—Cross-platform program development language derived from Business Basic
PSX Chipmunk BASIC	(PlayStation)—For the PlayStation
PureBasic	(Microsoft Windows, Linux, AmigaOS and Mac OS X)—Cross-platform program development language. Fast compiler with many functions that creates fast and small standalone native executables which do not require runtime DLLs. It compiles with FASM and has inline support.

Q

BASIC dialect	Description
QB64	(Windows, Linux and Mac OS X)-Self-hosting BASIC compiler for Microsoft Windows and Linux. Aims at full compatibility with Microsoft QBasic and QuickBASIC.
QBasic	(DOS on the PC)-By Microsoft. Subset of QuickBASIC. Came with versions of MS-DOS from 5.0 to 6.22. Also included with DOS 7 (what Windows 95 runs on,) and available from the install CD of Windows 98.
QuickBASIC	(DOS on the PC)—By Microsoft. An evolution of BASICA/GW-BASIC to block-structured lexical syntax that does not require line numbers, with many added intrinsic functions and language features (e.g. loop and conditional control constructs, file modes, and mixed-language programming support). Has an Integrated Development Environment (IDE), intended to compete with Borland Turbo language products (e.g. Turbo BASIC and especially the contemporarily popular Turbo Pascal). Mostly backward-compatible with BASICA source code. Includes a compiler and linker, and produces MS-DOS executables. Released in versions 1.0, 2.0. 3.0. 4.0, & 4.5. QuickBASIC 4.5 was released in 1988. The QuickBASIC 4.5 IDE includes an interpreter, syntax checking, debugging aids, and online help including a full language reference.
Quite BASIC	Web based classic BASIC programming environment. No download or signup necessary. Introduced in 2006.^[45]

R

BASIC dialect	Description
RapidQ	(Windows, Linux, Solaris/SPARC and HP-UX)—Free, borrowed from Visual Basic. Useful for graphical interfaces. Works mainly with QuickBASIC instructions. (Cross-platform, free, no longer being developed). Semi-OO interpreter. Includes RAD IDE.
RBScript	(Macintosh, Mac OS X, Linux and Windows)—Scripting language based on REALbasic.
RC Basic	(Windows, Linux, Android)—Basic Compiler geared towards game development.^[46]
REALbasic	(Macintosh, Mac OS X, Linux and Windows)—Platform independent BASIC. Object-oriented Visual Basic-like Basic variant. Currently known as Xojo.
Revelation BASIC or R/Basic	(DOS on the PC)—A variant of Pick/Basic used on the Revelation DBMS and successors.
RFO Basic!	(Android)—Basic for Android.^[47]^[48]
Rocky Mountain BASIC	created by HP to control instruments through HP-IB
Run BASIC	(Mac OS X, Linux, and Windows)—Free interactive web server-based version of Liberty BASIC
RobotBASIC	(Windows)—Free BASIC interpreter and Robotic Simulator for the Windows OS that allows for Gaming and GUI graphical programming. New version will also compile to stand alone executables.^[49]

S

BASIC dialect	Description
SAM BASIC	(SAM Coupé)
S.A.I.L.B.O.A.T	SAIL Basic on Another Tack (CP/M, DOS Z80, X86, pseudo interpreted, Northstar Basic Compatible, B-Tree File System)
SAX Basic
SBAS	"Structured BASIC" popular in British schools in 1980s & 90s. Written by Bryan Tackaberry of SPA Ltd to run on RM plc computers.
S-BASIC	"Structured" BASIC, came with Kaypro CP/M systems
SBASIC	developed for Nokia 9300 and Nokia 9500 Communicator. Development not finished, stopped with version 0.9.
ScriptBasic	Cross platform (ANSI C) Open source embeddable interpreter/API. The ScriptBasic project is primarily an embeddable scripting API with examples of a command line interpreter and multi-threaded HTTP application server running as a service.
sdlBasic	Free, multiplatform, based on core of wxBasic, but uses the SDL library.
SEGA BASIC	SEGA version of BASIC dedicated to SEGA SC-3000 computer
Sharp BASIC	(Sharp pocket computers)
Simons' BASIC	A cartridge-based utility that added 114 additional keywords to the standard BASIC 2.0 on the Commodore 64 computer
Simple BASIC	for Windows R3 Intermedia Language version Traditional BASIC, made for scientific purpose.^[50]
SIMPOL	Object-oriented, made to emit code for Windows, Linux, Mac OS X
Sinclair BASIC	(ZX80, ZX81/TS1000, ZX Spectrum)
SmallBASIC	(DOS, Palm OS, Windows, Linux etc.)—A small Open source GPL-ed interpreter.
Small Basic	(Windows)—By Microsoft DevLabs Team.^[51]
smart BASIC	for iOS
SmartBASIC	(Coleco Adam)
SmileBASIC	A retro dialect of BASIC used in Petit Computer (for the DSi) and SmileBASIC (for the 3DS)
Sony BASIC	for the Sony SMC-70
SOBS	(ICT 1900 series) Southampton BASIC System
Softworks Basic	(Win32, Visual Studio.Net, Linux, Unix)—a superset of AlphaBasic
Spectacle BASIC	(Microsoft Windows—can be recompiled for Mac OS X, Linux and AmigaOS) an open source, interpreted
SQABasic	For the Rational Software designed for Robot Script
Atari ST BASIC	(Atari ST)—This came with the Atari ST
StarBasic	StarOffice Basic
StarOffice Basic	(a.k.a. StarBasic) (OpenOffice.org, StarOffice)
STOS BASIC	(Atari ST)—For Atari ST made for game programming. Predecessor of AMOS BASIC on the Amiga.
Submarine BASIC	BASIC-E
SuperBASIC	(Sinclair QL)
SV extended BASIC	(Spectravideo)—For Spectravideo 318/328 By Microsoft.

T

BASIC dialect	Description
T-BASIC	BASIC dialect used on the Wang 2200T and its Soviet Russian clone, the Iskra (Spark) 226.
TBASIC	Version of BASIC used for software development on ATTI's family of BRAT test systems
Tektronix	For the 4050 series computers, extensive graphics commands^[52]
THEOS Multi-User Basic	(THEOS operating system)
thinBasic	interpreter for Microsoft Windows
TI BASIC	(note: no hyphen) (Texas Instruments TI-99/4A)
TI Extended BASIC	(Texas Instruments TI-99/4A)
TI-BASIC	(note: hyphen) (Texas Instruments programmable calculators)
Tiger-BASIC	High speed multitasking, for microcontrollers of the BASIC-Tiger family.
Tiny BASIC	(any microcomputer, but mostly implemented on early S-100 bus machines)—Minimalist version which source code was smaller than this article, used on low-memory platforms.
TML BASIC	(Apple 2GS)—A compiled BASIC with a GUI hosted IDE for writing native GUI apps.
TRS-80 Level I BASIC	(TRS-80)—based on Tiny BASIC.
TRS-80 Level II BASIC	(Tandy / RadioShack TRS-80)—based on Microsoft BASIC
TRS-80 Model 100 BASIC	(TRS-80 Model 100)—based on Microsoft BASIC, with special support for the RAM file store, LCD display, and other built-in hardware of the TRS-80 Model 100 and Tandy 102 portable computers
True BASIC	(DOS, MS Windows, Mac OS, Linux, Unix)—Direct descendant of the original BASIC, Dartmouth BASIC, marketed by its creators. Strictly standards-compliant.
Turbo Basic	(Commodore 64)—Added 55 commands to the C64 BASIC, Released by Aztec Software, written by Julian Gardner.
Turbo Basic	(DOS on the PC)—Commercial compiler by Borland. (BASIC/Z successor) (see PowerBASIC)
Turbo-Basic XL	(Atari 8-bit family)—Freeware interpreter and compiler for the Atari 8-bit family—based on Atari BASIC. Even this 'slow' interpreter was about four times faster than the built-in BASIC. Written by Frank Ostrowski—the person who would go on to develop GFA BASIC. Came from Happy Computer.
Tymshare SuperBasic	(SDS 940)

U

BASIC dialect	Description
UBASIC	(DOS on the PC)—Interpreter with many mathematical routines. Strong emphasis on number theory. Can work with many-digit numbers, complex numbers.
UniBASIC	dialect that is part of the UniData database, with a strong focus on data access and manipulation.
UniVerse	dialect that is part of the UniVerse database, with strong focus on data access and manipulation.
Uppsala-BASIC	also known as METRIC-BASIC
Utah BASIC	Ellis Computing, had 12 digit precision and matrix operations. MS-DOS port of the Processor Technology 8K BASIC. See Nevada BASIC.

V

BASIC dialect	Description
VAX BASIC	DEC's BASIC-Plus-2 ported to VAX/VMS
VBA	See Visual Basic for Applications
VBS	See 'VBScript
VBScript	(a.k.a. VBS, Visual Basic Script, Visual Basic Scripting Edition)—A subset of Visual Basic used in ASP, Internet Explorer, or under Windows using the WSH as a general-purpose scripting language. VBScript is often used as a replacement for DOS batch files.
Vilnius BASIC	(Elektronika BK-0010-01, BK-0011M and UKNC computers)
Vintage BASIC	Cross-platform, open-source interpreter for microcomputer-era BASIC, written in Haskell.^[53]
Visual Basic	(Windows)—Microsoft's object-oriented dialect with rapid application development environment.
Visual Basic .NET	(Windows)—Version within the .NET Framework by Microsoft.
Visual Basic for Applications	(a.k.a. VBA) (Microsoft Office on MS Windows and Apple Macintosh)
Visual Basic Script	See VBScript
Visual Basic Scripting Edition	See VBScript
Visual Test	(Originally MS-TEST)—Basic in Visual Test

W

BASIC dialect	Description
Wasabi	functional dialect with features such as closures, continuations and first order functions, created at Fog Creek Software as an in-house web applications development platform. Not released to public, but often features in the influential blog of Joel Spolsky, Fog Creek founder and CEO.
Watcom Basic	Dialect by Watcom
WinWrap Basic	VBA type third party interpreter which can be linked into programmes to give them macro/VBA functionality
WordBasic	versions of Microsoft Word before MS Word 97
wxBasic	open source GPL interpreter based on the platform independent wxWidgets toolkit library. For Linux, Mac OS X (proposed) and Windows.

X

BASIC dialect	Description
XBasic	(Windows, Linux)—Open Source compiler with a GUI designer
XBLite	(Windows)—Open Source-compiler with integrated editor
Xojo	(Macintosh, Mac OS X, Linux and Windows)—Platform independent BASIC. Object-oriented Visual Basic-like Basic variant. Formerly known as REALbasic.

Y

BASIC dialect	Description
Yabasic	(Linux, Windows and PlayStation 2) Small interpreter. (GPL)
yab	(BeOS, Zeta, HaikuOS) Adaptation of Yabasic that enables the creation of graphical programs using the BeOS API.^[54]
yBasic	See HotPaw Basic

Z

BASIC dialect	Description
ZBasic	Visual Basic subset dialect for ZX microcontrollers with support for multitasking.
ZBasic (Zedcor Zbasic)	first released by Zedcor (Tucson, Arizona) in mid-1985. Versions were made for Apple, DOS, Macintosh CP/M and TRS-80 computers. In 1991, 32 Bit Software Inc. (Dallas, Texas) bought the DOS version and expanded it. Zedcor concentrated on the Apple Mac market and renamed it FutureBASIC. ZBasic was very fast, efficient and advanced, with BCD math precision up to 54 digits.
Basic	developed for Windows and Pocket PC by KRMicros (Kronos Robotics).

BASIC extensions

BASIC extensions (a.k.a. BASIC toolkits) extend a particular BASIC.
(Platforms: APCW = Amstrad PCW; A8 = Atari 8-bit family; C64 = Commodore 64; C128 = Commodore 128; Spec+3 = ZX Spectrum +3; VIC-20 = Commodore VIC-20)

BASIC 8 (C128)—Third-party extension of the C128's Commodore BASIC 7.0
Beta BASIC (ZX Spectrum)
BASIC XL Toolkit (A8)—Disk-based extension of OSS's BASIC XL for Atari 8-bits
Basic Lightning (C64)—The White Lightning development suite, by Oasis Software included also a quite capable BASIC extension for the Commodore BASIC 2.0
Exbasic Level II (C64)—Extended BASIC. An improved BASIC for the C64, which was loaded from disk or ROM cartridge.
Graphics BASIC (C64)—Third-party extension of the C64's Commodore BASIC 2.0
Laser Basic (C64)—Was Ocean Software's updated version of The White Lightning development suite, which extended Commodore BASIC 2.0. A compiler called Laser Basic Compiler was available.
Laser Basic (ZX Spectrum)
Lightning Extended BASIC (APCW; Spec+3 on CP/M)—Extended Mallard BASIC with sophisticated graphics functions
YS MegaBasic (ZX Spectrum)
Monkey Wrench II (A8)—ROM cartridge extension of Atari BASIC from Eastern House Software. Using the right cartridge slot it required an Atari 800.
Simons' BASIC (C64)—CBM-marketed improved BASIC for the C64, loaded from disk or ROM cartridge
Super Expander (VIC-20)—CBM's own cartridge based extension of the VIC-20's Commodore BASIC 2.0
Super Expander 64 (C64)—CBM's own cartridge based extension of the VIC-20's Commodore BASIC 2.0, for the C64

Z . O/I Open Programming Language

Open Programming Language (OPL) is an embedded programming language for portable devices that run the Symbian Operating System .

It can be found on the Nokia 9200, 9300 and 9500 Communicator series mobile telephone/personal digital assistant (PDA) and the Sony Ericsson P800, P900, P910 series. On classic Psion PDAs such as the Series 3, 5/5mx, Series 7, and netBook/netPad, as well as the MC218, OPL is part of the standard application suite. OPL is also included in Psion Teklogix industrial handhelds such as the Workabout mx. OPL is an interpreted language similar to BASIC. A fully Visual Basic-compatible language OVAL has been also developed.

The language was originally called Organiser Programming Language, developed by Psion Ltd for the Psion Organiser. Designed by Colly Myers with the first iteration implemented by Richard Harrison and Martin Stamp. The first implementation (without graphics) was for the original Psion Organiser (now referred to as the Psion Organiser I, 1984), and it came bundled with the Science, Finance and Math data packs. It became truly accessible as built-in software in the Psion Organiser II (1986), and the language went on to be used in the Psion Series 3 and later. After Psion retired from the portable digital assistant market, the project was delayed until 2003, when the fledgling Symbian Developer Program released it as open source. The language is now developed on SourceForge in the opl-dev project.^{[clarification needed]}
The language is not available from Symbian OS v8 and later, mainly due to lack of interest and support from major Symbian licencees Nokia and Sony ericcson Hence, OPL will most likely never be made available for the newer generation of Symbian OS phones such as Sony Ericsson P990, M600,^{[citation needed]} W950, P1i and Nokia E61i and E90. As of 2010, Nokia device developers are encouraged to use Python for S60 instead (See Python for S60).^{[citation needed]}

Example

Here is the console version of a Hello world program:

PROC main:
  PRINT "Hello World!"
  PAUSE 40
ENDP

(Source code taken from the PCDevPrimer in the OPL Wiki.)
And here is a GUI version for Nokia's Series 80 user interface:

CONST KKeyEnter%=13

PROC hello:
  dINIT "Hello"
  dTEXT "","Hello World!"
  dBUTTONS "OK",KKeyEnter%
  DIALOG
ENDP

OPL is a structured programming language. OPL programs contain PROCedures, which are much like functions in other programming languages.

The dINIT keyword in this example initializes a dialog box (intuitively enough, all dialog-box related functions begin with a letter 'd'; for clarity, this letter is in lower case, but the language is case independent). The first argument of the dialog is an optional string, which is used for the title of the dialog, displayed in the title bar.
The dTEXT function displays text, with two compulsory arguments: a left-aligned 'prompt' string, and a main string.
The dBUTTONS keyword allows you to put buttons on the dialog box - here there is a button with the text "OK". The second argument to each button is both the special notation of the shortcut key for that button and the dialog's return code, in this case the "Enter" key.
Finally, the DIALOG keyword is required for the previously initialized dialog box to be shown on the screen.

Testing dialog responses

An example:

PROC test:
  dINIT "Your Challenge"
  dTEXT "","Will your answer to this question be no?"
  dBUTTONS "Yes",%y,"No",%n
  IF DIALOG=%y
     PRINT "No it wasn't!"
  ELSE
     PRINT "Yes it was!"
  ENDIF
  GET
ENDP

In this cruel interrogative program, the Yes button is assigned the shortcut of Ctrl+y, while No has Ctrl+n, represented by %y and %n respectively. The user's input from the DIALOG is tested in the IF statement, PRINTing appropriate responses to the screen. Note that the 'GET' keyword, which gets user input without using a dialog box, is here used simply to wait for a keypress before terminating the program (otherwise it would end immediately without giving time for the user to read the text). The output from DIALOG can also be stored in a variable.
Variables specific to a procedure must be declared with the LOCAL keyword; global variables are defined with the GLOBAL keyword.

Variable types

The table below uses an example variable called 'var'.

Data Type	Syntax
Floating Point	var
Integer	var%
Long Integer	var&
String	var$(length)

Minutiae

OPL interfaced with advanced Psion Series 3 features by means of operating system CALLs, but in the later Psion Series 5mx this was changed to a so-called 'OPX' library, stored in the system ROM (the Z drive). 'OPX' libraries were also made available for the Nokia 9210, Nokia 9300 and Nokia 9500 Communicators, adding OPXs routines for handling SMS and managing Bluetooth communication.
Other OPL features include those with a letter 'g' at the beginning, for graphical functions; those with a letter 'm', for menus; and those with a letter 'd', for dialogs.

Z . O/I A basic dry of BASIC

BASIC programming language by asking its creators and early advocates about its inception, history, and influence on the modern game industry.

BASIC turns 50 this year, and in honor of the occasion we've taken the liberty of reprinting Szczepaniak's extensive article.
The BASIC programming language, or Beginner's All-purpose Symbolic Instruction Code, turned 48 this year. That's an extraordinarily long life for tech -- even longer than the commercial video game industry has been around. Since its inception, BASIC has proliferated from a single source to include now over 280 variations and growing. Just about every single model of computer (including a few game consoles) has had at least one variant. Many veteran game developers got started working with BASIC out of their bedrooms on early personal computers, and BASIC remains popular with hobbyist coders.

The fathers of the original Dartmouth BASIC are Dr. Thomas Kurts and the late Dr. John Kemeny, who died in 1992. Kurtz, who turned 84 this year, spoke with absolute clarity as he recounted BASIC's launch.

"That first BASIC saw the light of day on May 1, 1964, at 4 a.m. We were a team, but [Kemeny] was always the team leader. He did the politicking and the money-raising that was always necessary while I attended to the details. But he was always careful to give me full credit for my share of the project, whatever the project. I had already used the word BASIC for a statistics text I wrote several years earlier [Basic Statistics, 1963]. John Kemeny liked acronyms, and so we settled on BASIC, for which he devised the expansion "Basic All-purpose Symbolic Instruction Code.' By the way, it has always been 'Symbolic' and never 'Simplified.'"

Basic Beginnings

Kurtz was first introduced to computers in 1951, when he spent the summer at the Institute for Numerical Analysis at UCLA, which was in the process of building the Standard Western Automatic Computer [SWAC], a clunky contraption that used both vacuum tubes and Williams tubes for internal memory. He created a program that used SWAC to deal with tail probabilities for statistical distributions.

Five years later he met Kemeny. "Although John Kemeny had been at Princeton while I was a grad student there, I didn't meet him until he was recruiting for Dartmouth in 1956," Kurtz said. "I was recruited to teach statistics, among other things, and it turned out that IBM, MIT, and UCLA were establishing regional computer centers in the East and the West. To earn extra money I was made a "research associate" in this effort and, even before I showed up at Dartmouth for my first class, I attended a course at MIT on Share Assembly Language (SAP) for the IBM-704."

Dr. Thomas Kurts (left) and the late Dr. John Kemeny, progenitors of Dartmouth BASIC, seen above in an early promotional photograph for True BASIC.

But SAP was complicated, and Kemeny wanted to make programming accessible for students without a science background, because those students often become future decision-makers in business and government. "In some of my talks in those early days, I called programming in BASIC a 'learning machine,'" Kurtz said. "I've always felt that being able to program meant that one had to develop the ability to abstract, to construct 'mental models' of something or other. I feel that this ability leads to being able to make contributions in fields other than the sciences."

So they needed a programming language that was more accessible than Assembly. "To make SAP more palatable to nonprogrammers at Dartmouth, John Kemeny devised DARSIMCO, Dartmouth Simplified Code, by presenting SAP in terms of three-instruction sequences," Kurtz explained.

For example, to perform A + B = C, you would write:

LDA A
FAD B
STO C

DARSIMCO and SAP were both abandoned in 1957, when FORTRAN arrived at Dartmouth.

"BASIC was the only widely available interactive language. Smalltalk? Lisp? Logo? MUMPS? They didn't stand a chance against BASIC."

Although higher-level languages were generally believed to be inefficient compared to assembly language, Kurtz discovered that coding in higher-level languages saved both computer usage time -- which was a valuable and limited commodity -- as well as his personal time. So he continued to work with higher-level languages that would inform BASIC's development later on.

In 1959, an undergraduate student without a computer background, influenced by FORTRAN, prepared a higher-level language and compiler he called DART for the LGP-30 computer (a rotating drum machine), which caught Kurtz's attention. Around 1961, Kurtz and several students worked on an ALGOL compiler for the LGP-30, which was later modified to be self-contained and named SCALP. This new language was subsequently taught to hundreds of students until BASIC replaced it.

Meanwhile, Kemeny worked on one more important language in 1962 before BASIC, again for the LGP-30. As Kurtz explained:

"John Kemeny devised a simplified language for that environment he called DOPE, 'Dartmouth Oversimplified Programming Environment,' which anticipated BASIC in having one instruction per line and having instructions such as:

5 + A B C to indicate 'Add A + B and put the result in C.'

This naturally led to the BASIC form

5 LET C = A + B."

DARSIMCO, DART, ALGOL 30, SCALP, and DOPE didn't last long enough and weren't massively successful, but they all influenced Kemeny and Kurtz with regard to BASIC's fundamental principles, which he explained as:

A) We made no distinction between floating-point arithmetic; we used only double precision floating-point internally, and adopted several strategies to make loop termination come out right.

B) No format-control on INPUT and default format for printed output.

C) One line, one statement.

D) Since we needed line numbers to facilitate editing (this was before WYSIWYG screen editors), we used these line numbers as GOTO targets.

E) The word LET came from our mathematics background, because we are always saying things like "Let G be an Abelian Group." Furthermore, LET was required for assignment statements so that all statements started with a keyword. This made understanding things like X = Y + Z easier for nonscientists. For logical expressions, we used IF X = Y + Z THEN... while for assignments we used LET X = Y + Z.

F) No nonobvious punctations, like the ALGOL semicolon to terminate statements, or the mysterious FORTRAN IF (A) 100, 200, 300. There is no comma allowed after the (A). Along the same line; we used ordinary-sounding English words for the commands to the time-sharing system. HELLO rather than LOGON, GOODBYE rather than LOGOFF, NEW to create a new program, OLD to retrieve an existing program, and so on.

Interestingly enough, BASIC didn't support the INPUT statement until its third version, meaning that for the first two years it wasn't actually an interactive language -- obviously making game creation rather difficult!

Basic Time Sharing

The other major factor in BASIC's widespread adoption was the development of time sharing. With a batch computing system, it could take hours, or even days, for a program's results to arrive. Less-intuitive languages were easier to make mistakes with, and those mistakes would waste precious computer access. Time sharing allowed several people to work on one computer simultaneously, maximizing computer time.

Kurtz described the first time-sharing operating system at Dartmouth thusly:

"Two Dartmouth students, Mike Busch and John McGeachie, developed a time-sharing operating system for the combination General Electric GE-235 computer and the GE Datanet-30 front-end communications controller. This was done simultaneously with the development of BASIC and, in many ways, was more fundamental to our goals at Dartmouth than BASIC itself. GE immediately took what we had done and developed a nationwide time-sharing network. They used regionally located centers, as the cost of long-distance communication at that time was too expensive. It was in one of these centers in Seattle that Bill Gates was first introduced to computing and BASIC. My best guess is that he was about 13 years old at the time."

Kurtz and the Dartmouth team continued to refine BASIC, adding INPUT, RANDOMIZE, and ON-GOTO statements among many other revisions, until it hit its sixth edition in 1971, which remained largely unchanged for several years. Since BASIC was included with General Electric's time-sharing systems, it continued to spread until it became the most widely used programming language in the world. According to Kurtz, "At one point, around 1974, when ANSI initiated a standards effort for BASIC, it was used on more time-sharing networks, of which there were over a hundred at the time, than any other language -- my recollection is more than 80."

It was around the time of the sixth edition that David Ahl, author of the influential book 101 Basic Computer Games, was introduced to BASIC.

"I accepted a position at Digital Equipment Corporation in late 1969 in the PDP-8 Group and soon got involved in marketing minicomputers to schools and colleges," he said. "At the time, the only high-level language on DEC's smallest computers was FOCAL. However, because of the pioneering work at Dartmouth by John Kemeny and Tom Kurtz in developing BASIC and related educational applications, most colleges and high schools wanted a computer that spoke BASIC."

Unlike other programming languages, BASIC was completely unregulated, which Kurtz believes was crucial to its success.

"Dartmouth always took the point of view that what we did was public, and thus we never made any attempt to control or direct the results of our research," he said. Ahl agreed, adding, "DEC's FOCAL language was equal to BASIC in most aspects and even better in some, but it had one huge drawback: DEC was unwilling to license it to other computer manufacturers. FOCAL was fighting an uphill battle against BASIC, which was available on GE, Honeywell, HP, and other computers."

Games: BASIC's Killer App

The early 1970s saw BASIC move away from mainframes and time-sharing systems and to the burgeoning microcomputers of the day. Ahl recalled how quickly they sprang up: "DEC took the unusual step of contracting with outside vendors to develop four versions of BASIC, one for a 4K stand-alone PDP-8 (EduSystem 10), one for a small multiuser 8K PDP-8 (EduSystem 20), one for the Timeshared-8 (EduSystem 50), and one for a batch processing PDP-8 with a card reader (EduSystem 30). The most limited version was that for the 4K PDP-8 as the BASIC interpreter used 3.5K of memory, so programs had to fit in the remaining 500 12-bit bytes."

To Ahl, games were critical to BASIC's spread. "We needed to demonstrate that such a limited configuration could run real programs, so I started converting FOCAL demo programs to this low-end BASIC," he explained. "We also encouraged users who wrote programs, especially games, to submit them. In 1972 I collected together a bunch of games that I had written from scratch or converted from FOCAL along with submissions from users and published it as 101 BASIC Computer Games. The book was later revised and, in 1983, total sales topped 1 million, and it became the first million-selling computer book."

As the book included type-in listings for BASIC games, it was likely a major catalyst in BASIC's proliferation. A large base of games would appeal to anyone considering incorporating a language into a new piece of hardware -- like Gates and Altair BASIC, for example. Ahl recalls meeting Gates: "When I left DEC in July 1974 and started Creative Computing magazine...I used all my vacation time to attend computer shows and conferences in order to promote Creative Computing. One fascinating show was the Altair Conference in Albuquerque in 1975 where I met Bill Gates and learned of his intention to write a BASIC language for the Altair."

Sure enough, in 1975, MITS released Altair BASIC, which was developed by Gates and Paul Allen as the "Micro-Soft." It was an interpreter, as opposed to Dartmouth and GE's implementation of a BASIC compiler, but it suited the limitations of the Altair hardware.

Despite his influence, Ahl is reluctant to take credit for BASIC's hobbyist popularity. "Did

" I sniffed the wind. There was a book out, 101 BASIC Computer Games, and Bill Gates had written in BASIC. So I said: You've got to have these games; it's going to be the heart of a computer that's worth anything to people."

my book popularize the spread of BASIC? Maybe, but the great libraries of BASIC programs at Dartmouth, the Minnesota Educational Computer Consortium, and Huntington Computer Project along with books like Bob Albrecht's What To Do After You Hit Return were equally infuential. BASIC was the only widely available interactive language. Smalltalk? Lisp? Logo? MUMPS? They didn't stand a chance against BASIC."

BASIC continued to spread as Microsoft ported its version to new microcomputer platforms and other people developed their own BASIC variant. Apple cofounder Steve Wozniak recalls writing Integer BASIC for the first Apple computers:

"I didn't program in BASIC, but I sniffed the wind. There was a book out, 101 BASIC Computer Games, and Bill Gates had written in BASIC. So I said: You've got to have these games; it's going to be the heart of a computer that's worth anything to people...The microprocessor I used only had machine language. I'd never had any training in writing a computer language, so I pulled out a manual at work, which was Hewlett-Packard, and read through making notes of all the commands. I didn't realize their BASIC was very different from Digital Equipment's BASIC, which the 101 Games had been written for. They were very different regarding strings."

Technically, Wozniak was probably the only one to hand write a new version of BASIC, explaining:

"I could not afford a time-share assembler. That's where you take a terminal, call a local phone number, connect to some faraway computer, and type your programs in using machine language. So I wrote my programs in machine language on paper, and then I looked at little charts to figure out what ones and zeroes would be created by them. I would write the ones and zeros down in base-16, or hexadecimal, and type that into the computer I had built. It would take me 40 minutes to type my entire BASIC in. If you go back to Bill Gates, he used a computer to type the program in. I'm sure I must be the only one who wrote a language completely in my own handwriting."

BASIC and the Nascent Game Industry

After that first breakaway in the mid-1970s, BASIC variants continued to propagate across all hardware formats, and as BASIC spread internationally, it would be localized for each new country it spread to. This formed a new distinct microcosms.

In the United Kingdom, microcomputers became wildly popular. Machines such as the ZX Spectrum, Amstrad CPC, and Commodore 64 all had one or more variants of BASIC interpreter. With one of these affordable, comparatively easy-to-learn machines, a teenager in the United Kingdom could write a game in his spare time using BASIC, have a parent sign a publishing contract, and have the game be distributed on audio cassette across the country. Two examples are Ghost Town and Ziggurat by John Pickford, both made while he was still at school. From this humble start on the ZX Spectrum, he would go on to develop NES games for Rare under contract. And thanks to the BBC's Computer Literacy Project, almost every British classroom had a BBC Micro -- complete with BASIC.

Japan adopted BASIC dialects on various home computers, often ported by Microsoft. These computers included NEC models such as the PC-6001 and PC-88, as well as the MSX and X68000 formats. Some of Japan's most prominent developers learned to program using these BASIC variants, including Dragon Quest creator Yuji Horii. He first encountered BASIC on his PC-6001, reading books on the language and modifying the games he had. Using BASIC he would program one of Japan's first adventure games, the astoundingly successful and genre-defining Portopia Renzoku Satsujin Jinken, which subsequently influenced an entire generation of Japanese players and developers.

Even Nintendo created a Famicom BASIC variant (called Family Basic) in June 1984, which Pokemon creator Satoshi Tajiri of Game Freak used to develop his understanding of the Famicom. In an interview with the Tokyo Metropolitan Museum of Photography, he described the creation of his first Famicom/NES title, Quinty (aka Mendel Palace):

"It became possible to see what was actually going on inside the Famicom, when software for beginners called "Family Basic" was released. When I completely understood its mechanism, I went to Akihabara to buy a multiuse circuit board, added the terminals from my Famicom, and ran my programs over it. That was our first step. Then I made a long-lasting battery, to save the memory on the circuit board. It was all a handmade developing environment."

But how important were games to the BASIC founders? Very important, as it turns out. Kurtz explains:

"The early personal computers were primarily game machines for hobbyists. So, their versions of BASIC had instructions for dealing with joysticks, and so on. Remember, at the time that Gates [and others] did their things, BASIC was the most widely used programming language in the world. The microcomputer folks adopted it for their teeny machines, which at first were good only for game playing. It was ideal for hobbyists who could not afford to pay for time-sharing services. Serious business users couldn't imagine giving up their big machine computers to put their applications on these "toys." It's clear that Microsoft did see the potential and managed to benefit from it, but most of the other small computer companies did not."

Even now, you'll find the roots of BASIC in a lot of popular or significant games. Richard Garriott would use Applesoft BASIC when programming Akalabeth, and again when developing the first Ultima. Wizardry was started (though not completed) in BASIC. Henk Rogers' The Black Onyx, a major influence on early Japanese designers, was partially programmed in BASIC. Pitman, also in Japan, started off as a magazine type-in before it was ported to the Game Boy as Catrap. Julian Gollop, famouse for the X-Com series of strategy games, started out programming in BASIC on the ZX81 and then ZX Spectrum micros. One of his earliest BASIC games was Rebelstar Raiders on the ZX Spectrum, which itself spawned several sequels right up to 2005.

Is BASIC Still Relevant?

BASIC's significance is fading as it nears its 50th anniversary. Anyone interested in game development can use utilities like Game Maker, which don't require any programming knowledge, while more ambitious developers these days target popular platforms with better earning potential, such as iOS. Even if you want to use BASIC, where do you start? Microsoft no longer includes QBASIC with Windows, and the older DOS-based versions are incompatible with modern Windows versions.

BASIC isn't popular in academia anymore, either. "Two things happened over the years," Kurtz said. "First, many of the applications used to demonstrate the use of simple BASIC programs could be handled, for example, by spreadsheets. Second, the computer science profession insisted on introducing ridiculously complicated languages, including those that went with the secondary school computer science curriculum."

Wozniak feels it's still useful for beginners. "It was really a great language with a great purpose," he said. "People have to start somewhere, and I think that's the best starting language you could ever have...Newcomers learn things a lot better when they understand what every statement does. It's a much better starting point."

Ahl feels optimistic, saying, "Will BASIC go on? Yes, but there's a danger in saying that it will last forever like the alphabet or wheel or pliers. Nevertheless, the BASIC language has had a profound influence for 50 years, and Kemeny and Kurtz deserve a great round of applause from all of us...for the last five decades, it's been one of the towering achievements in technology and education."

Where does BASIC go from here? Maybe only BASIC itself can answer that:

GOTO 10
RUN

profile image

====== MA THE BASF IC ON COLD JOB SPEEDOMETR IC MATIC ======

[1]

[4]

[5]

[1]

[2]

[3]

[a]

[2]

[3]

[4]

[6]

[7]

[8]

[b]

[10]

[11]

[12]

[13]

[14]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[13]

[2]

[3]

[4]

[5]

[8]

[10]

[11]

[12]

[3]

[4]

[9]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[notes 1]

[11]

[12]

[13]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[notes 2]

[25]

[26]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

Influenced by

Paradigm	Procedural
Developer	Microsoft
First appeared	1991; 26 years ago (1991)
OS	MS-DOS, Windows 95, Windows 98, Windows Me, PC DOS, OS/2, eComStation
License	Part of the operating system (a variety of closed-source licenses)
Website	www.microsoft.com
QuickBASIC, GW-BASIC

ANSI/ISO Shape	Name	Description
	Flowline (Arrowhead)^[15]	Shows the program's order of operation. A line coming from one symbol and ending at another. Arrowheads are added if the flow is not the standard top-to-bottom, left-to right.
	Terminal^[14]	Beginning or ending of a program or sub-process. Represented as a stadium,^[14] oval or rounded (fillet) rectangle. They usually contain the word "Start" or "End", or another phrase signaling the start or end of a process, such as "submit inquiry" or "receive product".
	Process^[15]	Set of operations that change value, form, or location of data. Represented as a rectangle.^[15]
	Decision^[15]	Conditional operation determining which of two paths the program will take.^[14] The operation is commonly a yes/no question or true/false test. Represented as a diamond (rhombus).^[15]
	Input/Output^[15]	Input and output of data,^[15] as in entering data or displaying results. Represented as a parallelogram.^[14]
	Annotation^[14] (Comment)	Additional information about a step the program. Represented as an open rectangle with a dashed or solid line connecting it to the corresponding symbol in the flowchart.
	Predefined Process	Named process which is defined elsewhere. Represented as a rectangle with double-struck vertical edges.
	On-page Connector	Pairs of labeled connectors replace long or confusing lines on a flowchart page. Represented by a small circle with a letter inside.
	Off-page Connector	A labeled connector for use when the target is on another page. Represented as a home plate-shaped pentagon.

Kamis, 19 Oktober 2017

WORD BASIC LANGUAGE ON ELECTRONIC PROGRAM WHILE ARE SUBSTITUTE TO OPER SYNTAX AMNIMARJESLOW GOVERNMENT 9122017 LOR EL IC IN GIGO LANGUAGE CLEAR EL MS-DOS 02096010014 FOR BASIC XWAM $$ ~ 22^(99)^ ;:' $$$$$

Types

Building blocks

Common symbols

Other symbols

Software

Diagramming

Activity diagram

Domination relationship

Special edges

Loop management

Definition

Explanation in terms of algebraic topology

Applications

Limiting complexity during development

Measuring the "structuredness" of a program

Implications for software testing

Cohesion

Correlation to number of defects

Tool types

Formal methods

Applications

Example

Summarization and materialization

Approaches

Software

Verification and validation

Automated program repair

Industry use

Interactive Theorem Proving (conference)

Pre-silicon process

Reasoning

Validation

Observability

Benefits

Types of routers

How routers work

Origin

Spread on minicomputers

Explosive growth: the home computer era

IBM PC and compatibles

Visual Basic

Post-1990 versions and dialects

Calculators

Windows command line

other

Nostalgia

Syntax

Typical BASIC keywords

Data types and variables

Examples

Unstructured BASIC

Structured BASIC

Object-oriented BASIC

Standards

Dialects

0–9 ( HUMAN NUMERIC PASSING PASS )

A

B

C

D

E

F

G

H

I

J

L

M

N

O

P

Q

R

S

T

U

V

W