What is Programming Language

1.1 Introduction

Programming languages can be classified into different generations based on their structure and how they handle data and program organization.

First-Generation Languages (1954-1958):

These first-generation languages (Fortan 1, ALGOL 58) have the following features:

1. 1. Subprograms were seen as more labor-saving devices.
   2. Data were globally defined.

Second-Generation Languages (1959-1961):

To this generation belong such languages as Fortran 11, Algol 60, COBOL, and LISP. They have the following features

• • Nesting of subprograms was allowed.
  • Various methods were used for passing parameters from are subprogram to another.
  • Structured programming constructs were used.

Third-Generation Languages (1962-1970):

The languages belonging to this generation are PL/1, ALGOL 68, PASCAL, and Simula. The features of these languages are as under:

• • Programming-in-the-large
  • Separately compiled modules
  • Data types were introduced

The Generation Gap (1970-1990). An excess of languages developed during the seventies.

Object-Based and Object-Oriented Programming Languages (1990-Onwards):

These languages (Ada, Smalltalk, C++, Object PASCAL, Eiffel, CLOS, etc.) have the following features

1. Data-driven design methods.
2. The theory of data typing emerged.
3. Little or no global data.
4. The physical structure of an application appears like a graph, rather than a tree.

Evolution of generation of Languages

A way to differentiate between procedure-oriented and object-oriented languages is that the former focuses on procedures and functions while the latter concentrates on data objects. In a procedure-oriented programming design, a module represents a main function, such as “Read a Master Record”, whereas in an object-oriented programming design, “Master Record” is the module.

Simula-80 was the first language to introduce the concepts of classes and objects, and later languages such as Alphard, CLU, Euclid, Gypsy, Mesa, and Modula adopted the idea of data abstraction. The use of object-oriented concepts led to the development of languages such as C++, Object Pascal, Eiffel, and Ada, and LISP to Flavors, LOOPS, and Common LISP Object System (CLOS).

The concept of object-oriented programming was developed by many computer scientists from different areas of computer science, with notable contributions from Alphard, CLU, Euclid, Gypsy, Mesa, and Modula among others.

1.2. ‘Object’: An Overview

According to New Webster’s Dictionary (1981), an object is :

• some visible or tangible thing
• hat toward which the mind is directed in any of its states or activities;
• that to which efforts are directed.

An object in object-oriented programming refers to a concept or entity, such as a chair, customer, university, painting, plan, or mathematical model. Some examples are physical objects found in the real-world, while others are abstract or conceptual. Software developers create abstract objects that mimic real-world objects that are relevant to the user.

In the context of object-oriented programming, the term “object” refers to any real or abstract entity that can be manipulated through the actions or methods defined on that object, resulting in a change in its state.

We will delve deeper into the concepts of state and activities in a later section. For now, it is enough to understand that the state of an object represents the information it holds at any given time, and activities refer to the operations or methods that can change the information or state of the object.

Two other definitions are worth mentioning:

• An object is anything, real or abstract, about which we store data and those methods that manipulate the data. (Martin and Odell, 1992).
• A system built with object-oriented methods is one whose components are encapsulated chunks of data and function, which can inherit attributes and behavior from other such components, and whose components communicate via messages with one another. (Yourdon, 1994).

Central Concepts Underlying Object Orientation

Various authors have suggested various concepts that, they think, are central to object orientation. We give below some of the oft-repeated concepts:

• Encapsulation
• Classes
• State retention
• Inheritance
• Information hiding
• Polymorphism
• Object identity
• Genericity
• Message

1.3. Encapsulation

Encapsulation refers to the practice of enclosing related components within a single unit, referred to as a “capsule”. In the context of object-oriented programming, the components within this capsule are the attributes and operations. Attributes represent the data or information associated with the object, while operations define the actions or methods that can change the values of the attributes or provide access to them.

1.4. State Retention

The concept of encapsulation is not exclusive to object-oriented programming. Subroutines in early high-level languages and modules in structured design also utilize encapsulation. However, there is a distinction between encapsulation in modules and that in objects. After a module completes its tasks, it returns to its original state. In contrast, after an operation is performed on an object, it does not return to its original state, but instead maintains its final state until another operation is performed on it.

1.5. Information Hiding

One of the outcomes of encapsulation is that the internal details of how an operation is performed on an object are hidden from the public view. Only the operations that can be performed on the object are visible to outsiders. This has two main benefits:

1. it increases the security of an object by restricting the access to its internal data and methods.
2. it increases the flexibility of an object by allowing the internal implementation to change without affecting the external use.

The idea of information hiding, as implemented through encapsulation, is not unique to object-oriented programming. The concept was first proposed by Parnas in 1972 and was also used in the modular design of programs in structured design.

1.6. Object Identity

Each object is unique and can be identified by an object reference or handle. A developer can access and manipulate the object using this reference or handle. This allows a program statement to refer to the object and perform operations on it.

Customer cust_rec 1= new Customer ();

The statement “defines a variable cust_rec 1 and causes this variable to hold the handle of the object Customer, created newly” means that a variable named “cust_rec 1” is being defined and assigned the handle of a newly created object of class “Customer”. The assignment operator “-” is directing the class “Customer” to create an instance of itself, which is then being assigned to the variable “cust_rec 1”.

1.7. Messages

An object obj1 sends a message to another object obj2, requesting it to execute an action using one of obj2’s operations. For this, obj1 must have knowledge of the operations of obj2. Thus obj1 should

1. Store the handle of obj2 in one of its variables.
2. Know the operation of obj2 that it wishes to execute.
3. Pass any supplementary information, in the form of arguments, that may be required by obj2 to carry out the operation.

Further, obj2 may pass back the result of the operation to obj1.

The input arguments to the message sent by obj1 are typically parameter values defined within obj1 or variables associated with it. However, they can also be other objects. In the programming language Smalltalk, objects can reference other objects through variables and communicate with them by passing handles of other objects back and forth. This means that in Smalltalk there is no need for data as objects can be passed as arguments.

Messages can be of three types:

1. Informative (past-oriented, update, forward, or push)
2. Interrogative (present-oriented, real, backward, or pull)
3. Imperative (further-oriented, force or action).

An informative message provides the target object information on what has taken place elsewhere in order to update itself:

employee.updateAddress (address:Address)

An interrogative message requests the target object for some current information about itself:

inventory.getStatus

An imperative message asks the object to take some action in the immediate future on itself, another object, or even on the environment around the system.

payment.computeAmount (quantity, price)

1.8. Classes

A class is a blueprint or template from which objects are created, known as instances. In other words, objects are instances of a class. For example, “customer 1”, “customer 2”, etc. are objects of the class “customer” and “product 1”, “product 2”, etc. are objects of the class “product”.

The Unified Modeling Language (UML) defines a class as “a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics.” This definition does not include the actual software implementation, such as a Java class. Instead, it encompasses all specifications that come before implementation. In UML, a class that has been implemented in software is referred to as an implementation class.

A type is often used to refer to a group of objects that share the same attributes and characteristics. It differs from a class in that it may not include any methods, which are the implementation of an operation and describe the steps or procedure of that operation.

Although objects of a class are structurally identical, each object:

1. has a separate handle or reference and
2. can be in different states.

Normally, operations and attributes are defined at the object level, but they can be defined at the level of a class. Thus, creating a new customer is a class-level operation:

new Customer();

The class operation “Customer()” creates a new customer object(constructor). Similarly, a class-level attribute “no0fCustomers Created” that keeps track of the number of customer objects created by the class customer:

noOfCustomersCreated: Integer

no0fCustomers Created is a class attribute that is incremented by 1 each time the operation New is executed.

The UML notation of a class, an instance of a class, and an instance of a class with a specific name are as under:

1.9. Inheritance

Inheritance is a feature that allows a subtype D to implicitly inherit all the attributes and operations of a supertype C as if they were defined directly on D. This means that D can use the attributes and operations of C without having to redefine them.

It’s important to note that the terms subtypes and supertypes are used instead of subclasses and superclasses (even though the latter terms are more commonly used in this context) because we are referring to operations and attributes only, not methods.

In this scenario, classes “Manager” and “Worker” are both considered as “Employees.” Thus, attributes such as “Name”, “Address” and “EmployeeNo” and operations like “transfer”, “promote” and “retire” are defined in the supertype “Employee.” These attributes and operations are valid for and can be used by the subtypes “Manager” and “Worker” without having to redefine them. Additionally, these subtypes can have their own attributes and operations, specific to them. For instance, an attribute “OfficeRoom” and operation “attachOfficeRoom” can be defined for the “Manager” class and an attribute “DailyWage” and operation “computeDailyWage” can be defined for the “Worker” class.

The relationship between a supertype and subtype can be best represented using a Generalization-Specialization (Gen-Spec) diagram. The example of “Manager” and “Worker” inheriting from “Employee” can be depicted using a Gen-Spec diagram, as shown in the example below.

Here, Employee is a generalized class, and Manager and Worker are specialized classes.

An alternative UML notation is given below

To define a correct subtype, two rules are to be satisfied:

1. The 100% Rule. The subtype conforms to 100% of the super-type’s attributes and operations.
2. The Is-a Rule. The subtype is a member of the super-type.

The Gen-spec diagram is often called an ‘Is-a’ diagram. Often a subtype can inherit attributes and operations from two super-types. Thus a Manager can be both an Employee and a Shareholder of a company. This is a case of multiple inheritances.

While languages such as C++ and Eiffel support these features, Java and Smalltalk do not. Multiple inheritances lead to problems of :

1. Name-clash
2. Incomprehensibility of structures

More about their problems will be cited later in the text.

1.10. Polymorphism

Polymorphism is a concept derived from Greek, with “poly” meaning “many” and “morph” meaning “form”. It allows the use of the same name for similar services provided by different objects. Typically, different object types are related in a hierarchy with a common supertype, but this is not always the case (especially in dynamic binding languages like Smalltalk or languages that support interfaces like Java).

In the first example, “getArea” is an operation in the supertype “Hexagon” that defines a general method for calculating the area of a polygon. The subtype “Hexagon” inherits this operation, and thus the method for calculating its area. However, if the polygon is a “Triangle” or “Rectangle”, the operation “getArea” would imply calculating the area through simpler methods such as (1/2) base x height or the product of two adjacent sides, respectively.

In the second example, “Payment” types include cash, credit, or cheque. The same operation “authorization” is executed differently in different Payment types. For instance, in “CashPayment”, “authorize” verifies for counterfeit paper currency, in “CreditPayment”, it evaluates creditworthiness, and in “ChequePayment”, it checks the validity of the cheque.

In the above examples, the concept of overriding is applied. The operations “getArea” and “authorize” defined in the supertype are redefined in the subtypes, where different methods are employed.

Polymorphism is often achieved through dynamic binding, also known as runtime binding or late binding. It is a method in which the specific code to be executed is determined only during runtime, when the message is sent, as opposed to at compile-time.

While polymorphism allows the same operation name to be defined differently across different classes, overloading allows the same operation name to be defined differently multiple times within the same class. These overloaded operations are differentiated by the signature of the message, meaning the number and/or class of the arguments. For example, two operations, one without an argument and the other with an argument, may execute different code:

giveDiscount

giveDiscount (percentage)

The first operation invokes a general discounting scheme allowing a standard discount percentage, while the second operation allows a percentage discount that is specified in the argument of the operation.

1.11. Genericity

Genericity allows defining a class such that one or more of the classes it utilizes internally are only supplied at runtime, when an object of this class is instantiated. This type of class is known as a parameterized class. In C++, it is called a template class. To use this feature, one must define a parameterized class argument when defining the class. At runtime, when the need arises to instantiate a specific class of items, the required argument value must be passed. For example, a parameterized class can be defined like this:

class Product <Product type>;

while instantiating a new object of this class, we supply a real class name as an argument:

var Product 1: Product Product. New <Gear>;

or

var Product 2: Product Product. New <Pump>;

Download PDF