Unit 10: Programming Languages and Programming Process
I. Orientation: Programming Languages and the Development Process
A programming language is a formal notation for expressing algorithms that a computer can execute, ranging from raw binary the hardware reads directly to human-readable syntax that must be translated. This unit tracks that spectrum from machine level upward and then follows the disciplined process by which software is planned, built, and maintained.
- Program: a set of instructions directing a computer to perform a task; written in source code, then translated to executable form.
- Source vs. object code: source code is human-written text; object code is the machine-readable binary produced from it.
- Translators: three kinds convert source to machine code:
- Assembler: converts assembly language into machine code, one-to-one.
- Compiler: translates an entire high-level program into object code at once before execution.
- Interpreter: translates and executes a high-level program line by line at runtime.
- Generations: languages are grouped into generations (1GL machine, 2GL assembly, 3GL procedural, 4GL declarative/query, 5GL logic/AI) reflecting rising abstraction from hardware.
- Abstraction principle: the higher the language level, the closer it is to human reasoning and the further from hardware detail, trading raw control for readability and portability.
II. Categories of Programming Languages
A. Classification by level and paradigm
Languages are categorised both by how close they sit to the hardware and by the style of problem-solving they enforce.
- Low-level languages: machine-dependent, tied to a specific processor's instruction set; includes machine and assembly language.
- High-level languages: machine-independent, portable across processors after recompilation; use English-like keywords.
- Procedural (imperative): program is a sequence of statements and procedures; e.g., C, Pascal, FORTRAN.
- Object-oriented: program organised as objects bundling data and methods; e.g., Java, C++, Python.
- Functional: computation expressed as evaluation of functions, avoiding changing state; e.g., Haskell, Lisp.
- Logic/declarative: the programmer states facts and rules rather than steps; e.g., Prolog, SQL.
B. Trade-offs across categories
The choice of category balances speed, ease, and control.
- Execution speed: low-level code runs fastest because no translation overhead remains at runtime.
- Development speed: high-level languages cut coding time through built-in libraries and readable syntax.
- Portability: high-level programs move between machines; low-level programs must be rewritten per architecture.
III. Machine and Assembly Language
A. Definition and role
These are the two low-level languages that sit closest to the hardware, forming the first and second generations.
- Machine dependence: both are written for one specific processor family and cannot run unchanged on another.
- Direct hardware access: they permit precise control over registers, memory addresses, and I/O ports.
B. Machine Language
Machine language is the only language a CPU executes directly, expressed entirely in binary.
- Binary form: every instruction is a pattern of 0s and 1s, e.g.,
10110000 01100001to load a value into a register. - First generation (1GL): requires no translator; the processor decodes it as-is.
- Instruction structure: each instruction has an opcode (operation to perform) and an operand (data or address to act on).
- Drawbacks: error-prone, extremely hard to read or debug, and non-portable across processor types.
C. Assembly Language
Assembly language replaces binary opcodes with short symbolic mnemonics, one step above machine language.
- Mnemonics: memory-aid keywords stand for operations, e.g.,
ADD,SUB,MOV,JMP. - Worked example:
ASMMOV AL, 61h ; load hex value 61 into register AL ADD AL, 05h ; add 5 to the value in AL - Assembler: a translator converts each mnemonic into its exact machine-code equivalent, largely one-to-one.
- Symbolic addressing: labels and variable names replace numeric memory addresses, easing maintenance.
- Use today: device drivers, embedded systems, and performance-critical routines where hardware control matters.
IV. Higher Level Languages
A. Definition and characteristics
High-level languages (3GL and beyond) let programmers write instructions in near-English syntax, insulated from hardware detail.
- Machine independence: the same source compiles or interprets on many machines.
- Translator required: a compiler or interpreter bridges the gap to machine code.
- Readability: keywords like
if,while,printmake logic self-explanatory. - Built-in support: standard libraries handle common tasks such as math, I/O, and string handling.
B. Compiled versus interpreted execution
High-level languages reach the CPU by two contrasting routes.
- Compiled: the whole program is translated to object code before running; produces fast executables but a slower build step. Examples: C, C++.
- Interpreted: each statement is translated and run on the fly; slower execution but flexible testing and portability. Examples: Python, JavaScript.
C. Representative languages and generations
Each family suits a distinct problem domain.
- FORTRAN: early 3GL for scientific and numerical computing.
- COBOL: business data processing, verbose English-like syntax.
- C: systems programming, close to hardware yet portable.
- Java: object-oriented, "write once, run anywhere" via the JVM bytecode.
- Python: general-purpose, interpreted, prized for concise readable code.
- Fourth generation (4GL): non-procedural, closer to natural language, e.g., SQL for database queries.
- Fifth generation (5GL): based on problem constraints and logic, used in AI and expert systems, e.g., Prolog.
D. Advantages and limitations
The abstraction that makes high-level languages easy also costs some efficiency.
- Advantages: faster development, fewer errors, easier debugging, portable code.
- Limitations: less direct hardware control and generally slower than equivalent low-level code due to translation overhead.
V. WWW Development Languages
A. Purpose and principle
Web development languages build and power pages served over the World Wide Web, split by where they run.
- Client-side: executed in the user's browser to control structure, style, and interaction.
- Server-side: executed on the web server to process requests, run logic, and access databases.
B. HTML — structure
HyperText Markup Language defines the content and layout of a web page.
- Markup, not programming: uses tags to describe elements rather than express algorithms.
- Tag syntax:
HTML<h1>Welcome</h1> <p>This is a paragraph.</p> - Role: provides the skeleton — headings, paragraphs, links, images, and forms.
C. CSS — presentation
Cascading Style Sheets control the visual appearance of HTML elements.
- Separation of concerns: style is kept apart from structure, so one stylesheet formats many pages.
- Rule syntax:
CSSh1 { color: blue; font-size: 24px; } - Cascade: rules apply by specificity and order, letting styles override predictably.
D. JavaScript — client-side behaviour
JavaScript adds interactivity that runs inside the browser.
- Dynamic content: manipulates the Document Object Model (DOM) to change pages without reloading.
- Event handling: responds to clicks, input, and timers, e.g., validating a form before submission.
- Ubiquity: the standard scripting language every major browser executes natively.
E. Server-side languages
These run on the server to generate pages and handle data.
- PHP: embedded in HTML, widely used to build dynamic pages and connect to databases.
- ASP.NET / JSP: Microsoft and Java server-side frameworks producing pages on request.
- SQL: queries and updates the databases behind data-driven sites, e.g.,
SELECT name FROM users;. - Request–response cycle: browser sends a request, server-side code processes it, and HTML is returned to the client.
VI. The SDLC of Programming
A. Definition and principle
The Software Development Life Cycle (SDLC) is a structured, phased process for planning, creating, testing, and maintaining software.
- Purpose: deliver quality software on schedule and budget by proceeding through defined stages.
- Iteration: later phases can feed back into earlier ones as requirements or defects surface.
B. Phases of the SDLC
Each phase produces a deliverable that feeds the next.
- Problem definition / requirement analysis: identify what the software must do; gather and document user requirements in a specification.
- Design: plan the solution — system architecture, algorithms, data structures, and interfaces; often expressed as flowcharts or pseudocode.
- Coding (implementation): translate the design into source code using a chosen programming language.
- Testing: verify the program works and meets requirements.
- Debugging: locating and fixing errors found during testing.
- Error types: syntax errors (rule violations caught by the translator), logic errors (wrong results despite valid syntax), and runtime errors (failures during execution).
- Deployment / implementation: install the working software in the user's environment for actual use.
- Maintenance: correct faults, adapt to new environments, and enhance features after release.
C. Development models
Different models order the phases to suit project needs.
- Waterfall: phases flow strictly downward, each completed before the next begins; simple but inflexible to change.
- Iterative / Agile: software is built in repeated small cycles, delivering working increments and welcoming changing requirements.
D. Documentation and tools
Supporting artefacts keep the process disciplined and the product maintainable.
- Algorithm: a finite, ordered set of steps solving a problem, written before coding.
- Flowchart: a diagram using standard symbols (oval for start/end, rectangle for process, diamond for decision) to show program flow.
- Pseudocode: structured English describing logic without language-specific syntax.
- Documentation: internal comments and external manuals that explain the program for future users and maintainers.
Did this save you a night before the exam?
LPU Notes is free, and it stays free. Ads cover part of the server bill. The rest comes out of a student's own pocket: the domain, the storage, and keeping the site up through the weeks everyone needs it at once.
The payment button didn't load. An ad blocker or a filtered network is the usual reason. to try again.
Nothing here is ever locked, and nothing unlocks. Chip in only if it was worth it. What it pays for →