1.6Programming paradigms & languages

To close this chapter, we cover the design philosophies (paradigms) for how to actually assemble the algorithms and data structures learned so far into a larger program. The differences between paradigms are not about "which syntax is available" but about differing ideas of how to manage complexity. This section also touches on the common languages programs and systems use to exchange data (markup formats, APIs).

1.6.1The three major programming paradigms

• Procedural programming describes processing as "a sequence of steps executed top to bottom." The pseudocode from the previous section is also based on this idea. It is easy to follow the flow of control, but as a program grows, the loose coupling between data and the code that acts on it can make maintenance harder.
• Object-oriented programming bundles data (attributes) together with the code that operates on it (methods) into an "object." It breaks a large system into components (objects) organized by role, making each component easier to develop and reuse independently.
• Functional programming views computation as "applying mathematical functions" and avoids side effects (changing state outside the function) as much as possible. Composing functions that always return the same output for the same input (pure functions) makes it easier to avoid unexpected bugs during concurrent processing.

1.6.2The three pillars of object-oriented programming

• Encapsulation prevents an object's internal data from being manipulated directly from outside, forcing access through defined procedures (methods). Hiding the internal implementation makes it possible to change the implementation freely without affecting external code.
• Inheritance lets a new class (a subclass) take on the attributes and methods of an existing class (a superclass). Gathering common parts into the superclass lets you write only the differences in the subclass, avoiding duplication.
• Polymorphism lets the same method call trigger different behavior depending on the class of the object it is called on. The calling code does not need to know the specific class it is dealing with.

1.6.3Representative languages, data formats, and APIs

• Representative language tendencies: Python (a general-purpose language widely used in machine learning and data analysis), Java (object-oriented, large-scale business systems), C (low-level, close to hardware, embedded development), R (specialized for statistical analysis and data analysis), and Go (concurrency, server-side for cloud infrastructure).
• HTML (screen structure), XML (a general-purpose tag-based data description suited to strict schema validation), and JSON (a lightweight key-value data description, the mainstream choice for web APIs) all serve as common formats for exchanging data between programs or systems.
• An API (Application Programming Interface) is a "window" that lets another piece of software's functionality be called without knowing its internal implementation. A library is a pre-packaged, reusable set of general-purpose functionality that gets built into a program. Both share the common goal of "avoiding reinventing the wheel."

Consider a development team designing payment processing that must support several payment methods (credit card, e-money, bank transfer). A naive procedural implementation would embed an ever-growing chain of if payment-method = credit-card then ... elseif payment-method = e-money then ... branches inside the payment logic, and every new payment method added would require touching this sprawling chain. Adopting object-oriented design instead, you define a method such as executePayment() on an abstract superclass "PaymentMethod," and each subclass—credit card, e-money, bank transfer—inherits that method and overrides it with its own implementation. The caller writes the same paymentMethod.executePayment() call regardless, and the actual behavior that runs depends on which payment method it is—this is polymorphism. Inside each class, sensitive data such as card numbers or API keys is kept off-limits from direct external manipulation, accessible only through defined methods—thorough encapsulation. Adding a new payment method (say, QR-code payment) then requires no changes to existing branches at all—just one new subclass. When this payment logic communicates with an external payment-processing provider, it typically calls the provider's API, exchanging request and response data in the lightweight JSON format. Rather than writing part of the payment logic (say, encryption) from scratch, using a trustworthy library avoids reinventing the wheel and delivers a secure implementation in far less time.

1.6.4Section summary

• The three major paradigms: procedural (a top-to-bottom sequence) / object-oriented (data and behavior bundled together) / functional (avoiding side effects, favoring pure functions)
• The three pillars of OOP: encapsulation (hiding internals) / inheritance (taking on a superclass's functionality) / polymorphism (same call, different behavior)
• API = a window for calling functionality, library = reusable components. Data exchange uses HTML/XML/JSON (JSON is the mainstream choice for web APIs)