Abstraction, Procedural Abstraction, and Early Computing History

Definition: Managing complexity by “abstracting away” information and detail to focus on the relevant concepts. Source: CodeHS.

High level abstraction: a summarized version that omits many details.
Low level abstraction: includes the nitty-gritty details; much more detail than most people need.

Example 1 (High level): Mom says: “Hi sweetie, how was your day?”
- You reply: “It was OK, same as yesterday.”
- Mom asks: “Did you learn anything new?”
- You reply: “Not really.”
- Interpretation: This is high level abstraction — concise, no specifics about activities.
- Conclusion: It is High Level Abstraction (Probably too high for Mom’s liking).
Example 2 (Low level): Dad says, “I would like you to mow the grass today, at 8:00pm because at 8:00pm, the sun will be starting to set, and the temperature should be $101$ , instead of $108$ .
- Instructions include: mow all sections, use the edger, make a $90^{\circ}$ cut around the sidewalk, trim around trees, mailbox, the house and anything the edger missed, and take a large thermos of water; hydrate as needed.”
- You reply: “Yes, sir, I’d be happy to.”
- Interpretation: This is low level abstraction — lots of detailed steps.
Summary: High level vs Low level are shown in repeated examples to contrast abstraction granularity.

Turn-left() repeated three times vs turn_right(): a sequence of three simple left-turn commands is a low-level detail; a single right-turn can be viewed as a higher-level abstraction of the same navigation.
Page notes: “IT IS…… Low Level Abstraction (at least lower level)” when showing multiple turnleft() calls vs a single turnright().
Conversely: a single instruction that expresses the overall orientation change can be considered High Level Abstraction in the same context.

Richard Rombouts: “A procedure or function is an abstraction over a group of statements/expressions. When calling the procedure/function, you don’t need to know all details of the implementation, these are abstracted away from the user.”
Ratnakar Sadasyula: “Procedural abstraction is when we know what a method or procedure (function) does, or what we want it to do, but we do not know how it does it.”
CodeHS: “Defining the steps of a program without worrying about exactly how each step works under the hood.”

CodeHS: Programming languages abstract away all of the complex details to help manage complexity.

Assembly language (Page 16):
- Widely used mid-20th century.
- Assembly code had to be converted to executable machine code by an assembler before execution.
- Low-level language with a strong one-to-one correlation between language instructions and machine code instructions ( $1:1$ mapping).
- Support for constants, comments, assembler directives, symbolic labels (memory locations, registers), and macros.
COBOL (Page 17):
- Acronym for “Common Business-Oriented Language.”
- Compiled English-like language designed for business use.
- Used in business, finance, and administrative systems for companies and governments.
- High-level language that uses readable constructs like “MOVE 1 to I.”
A bit of History (Page 18): general historical context leading to modern programming practices.

IBM System/Programmer workflow (Pages 19–20):
- A standard card form existed for punching source statements (IBM form). The punched cards represented lines of code.
- Automation: card readers could feed and read hundreds of cards per minute (around $1000\,/\text{min}$ ).
- Typical workflow: write code by hand, punch onto cards. Deck(es) were submitted for execution, and results were returned after some time depending on backlog.
Card-based programming reality:
- Each card holds one line of code (up to 80 columns).
- The printed results followed after processing the deck.

Early structured programming movement introduced with FORTRAN in a structured form for better readability and maintainability.

Page 23: Comments are important for long-term maintainability.
- Why: As programs grow in length and complexity, it becomes difficult to understand what a program does and where, unless it is properly commented.
Page 24: Real-world example illustrating maintenance challenges without comments:
- A scenario where a corporate acquisition or reorganization leads to many changes across many programs.
- A teammate who commented their code makes future modifications easier, reducing risk and time needed to implement changes (e.g., changes related to a feature like a “blue checkmark”).
- Message: “THANKS BUDDY!” for good comments.

Page 25: API = Application Programming Interface — a set of tools for building software applications.
- In CodeHS, in SuperKarel, all Karels commands are APIs. We cannot see the underlying code that actually runs.
- They are hidden functions; we call them instead of coding the internal implementation.
- Examples: move(), turn_right()

Abstraction allows us to manage complexity, re-use code, and focus on what matters at a given level of detail.
Procedural and API abstractions enable developers to rely on well-defined interfaces without needing to understand implementation details.
Comments and documentation are essential for future maintenance, especially when team changes occur or requirements evolve.
Historical context shows how programming languages evolved from low-level, hardware-near representations (assembly) to higher-level, human-readable constructs (COBOL, FORTRAN) to support business needs and maintainability.
Practical implications include maintainability, portability, and collaboration; ethical considerations include ensuring documentation does not mislead or hide important limitations, and keeping APIs stable to avoid breaking dependent code.

Abstraction is a fundamental principle in computer science used to manage complexity across layers: hardware, assembly, languages, libraries, and APIs.
High-level abstractions enable cognitive focus on algorithm design and problem-solving rather than low-level syntax and machine specifics.
Low-level abstractions are valuable for performance tuning, systems programming, and understanding what actually happens at the machine level.
Procedural abstraction formalizes the concept of “divide and conquer” in programming by encapsulating procedures and exposing interfaces.