Imperative Paradigm
Since the development of early computers (e.g. ENIAC), the common architecture involved separating Data and Processing.
Data is sent to the CPU for processing and the result is sent back to memory for storage.
The CPU is a sequential device; instructions are processed one at a time in a predetermined sequence.
This von Neumann concept has been implemented in every computer, which then has lead to the development of procedural or imperative languages.
In this course, we have studied the imperative paradigm in detail, as it remains widely used and many of its methodologies are useful foundations to mastering other paradigms.
Imperative languages use sequencing, decisions and repetition as their main problem solving methods. Data and processing are separated with imperative languages. We create variables for data storage and then we perform processes on them. Each program has a beginning and a distinct end. This is not the only way of doing things.
Limitations of the Imperative Paradigm
- Difficulty solving certain types of problems
- Many real life problems do not have definite answers or they have a variety of answers
- Other problems can be solved using strategies that cannot be stated easily in strict mathematical terms.
- For example, doctors diagnose diseases in patients using symptoms and a certain amount of intuition gained from experience with other patients.
- Driving a car involves far more than knowing how to operate the controls.
- Good drivers are able to become an integral part of the vehicle; they sense potential dangers before they become problems.
- The need to specify code for every individual process
- The imperative paradigm requires that every part of the problem must be solved in complete detail before the final software will operate.
- For example, when using topdown design thorough testing cannot commence until the final lowest level subroutines have been written.
- Imagine the subroutine required to sort was not present within a database management system (DBMS).
- The whole application would fail even though this sort subroutine is a very minor part of the larger application.
- Now imagine it was not necessary to specify details of every single process. Instead imagine the software could infer a suitable method of solution at runtime. If this were the case then software will be able to react to the changing needs of users without the need for modification.
- This is a significant aim of the logic paradigm and is why the logic paradigm is used to develop many artificial intelligence applications.
- Difficulty of coding for variability
- Well-structured imperative programs can be designed so that modules of code can be readily reused; however this is not an integral part of the imperative paradigm.
- It would be preferable if code could be used to solve related problems without the need to be rewritten
- This reusability should be an integral part of the paradigm in much the same way as our brain uses past experience to solve new related problems
- Is there a paradigm that will encourage the reuse of code? If so, then the task of software developers will be simplified and the quality of the resulting products improved.
- Many other industries reuse components in a variety of contexts.
- For example, the padding in a lounge chair can also be used in the seat of a car or to provide sound- proofing in a studio.
Emerging Technologies
The first programmers had to program in machine language; a series of binary digits.
The programmer was forced to think like the machine and the language was dependent on the processor.
John von Neumann was ‘using’ his students to convert his code into binary machine language for input using punched cards.
- Apparently one of his students asked why the machine could not perform the conversion.
- Von Neumann replied that the resources of the computer where far too valuable to be wasted on such menial tasks. This must have made his students feel particularly valuable!
- Of course, eventually assembler languages emerged to perform this precise task.
- At the time, assembler languages were viewed as a way of removing the programmer from the technical aspects of implementation so they could focus on solving the problem.
- Compared to today’s modern languages assembler is extremely primitive.
The ever-increasing speed of the technology underpinning computer hardware has allowed programming languages to further remove the programmer from the machine code.
- The emphasis is on creating programming tools to assist in the development of software products without the need for the programmer to directly interact with lower level CPU processes.
- The final software product may not always be as efficient as a similarly developed machine code product, however its development is certainly a simpler and more intuitive process.
The imperative paradigm has evolved over the years from lower-level languages that directly accessed the computer’s hardware functions. Computers are now powerful enough that different ways of viewing and solving problems can be utilised.
In the next section, we look at some different approaches that are emerging to assist in the solution of problems
