Welcome back to Teatime! This is a weekly feature in which we sip tea and discuss some topic related to quality. Feel free to bring your tea and join in with questions in the comments section.
Tea of the week: Rootbeer Rooibos from Sub Rosa Tea. A nice change from my typical tea-flavored-teas and chais, this fun, quirky tea really brightens up a dull day.
Today’s Topic: Programming Paradigms
Programming languages come in many forms, and are intended to be used in many different ways. Understanding the organization and design patterns that apply to your language helps considerably with maintainability. This stuff might be old hat to devs, but as more and more QA folks pick up a bit of programming for automation, it can be helpful to have a refresher.
Procedural Code
The very first thing we designed (programmable) computers to do was to take in a list of instructions and execute them. Fundamentally, that’s the heart of all programming; as such, everything’s built on the procedural code paradigm.
The next improvement we made was to add subroutines (sometimes called “functions”), small bits of code that could be executed as a single custom instruction. This provides code re-use as well as increased readability. Basically everything can be written this way, but it’s the primary paradigm for C, BASIC, Go, Python, and PHP.
Object-Oriented Programming
Object-oriented programming attempts to model the system as a series of discrete objects that both encapsulate data and contain the logic necessary to work with the data. The basic building block here is the object, which contains both properties (pieces of data) and methods (encapsulated bits of logic, much like subroutines). This is where you start to get your classic Design Patterns, like Singleton or Factory patterns.
Objects can be composed; a Cat object might contain a Skeleton object that has a list of bones and keeps track if any are broken. Objects can also have inheritance, where one object fundamentally is another object but with added properties or methods; for example, a Cat object might inherit from a Mammal object the ability to nurse its young and be petted. In classical inheritance, you have a Class definition which explains what all objects of a given type look like, and specific instances created from that template; Classes inherit from other Classes. In prototypical inheritance, every object is a unique snowflake that can dynamically mix-in the properties of another object, much like how bacteria can incorporate the genes of other bacteria they swallow. Objects in this system inherit directly from other objects.
Primarily object-oriented languages include Java, Ruby, and C#. You know you’re dealing with an object-oriented language when you have to declare a Class with a Main method in order to provide a starting point for even a simple application.
Functional Programming
The basic building block in a pure Functional programming paradigm is the Function. This isn’t the same as a subroutine; instead, this is a mathematical function, or “pure function”. A pure function takes inputs and returns outputs, with no state, side effects, or other changes. Functions are immutable, and the values are immutable; for a given immutable input, a function returns an immutable output. Rather than have extensive loops and conditionals, you instead are expected to compose functions together until your data is in the state you expect it to be in. If you’ve ever heard of Map-Reduce, the famous algorithm from Google, this is functional programming (Map takes a set of data and applies a function to each element; Reduce takes a set of data into a function that composes it into a single value).
Primarily functional languages include Lisp, Haskell, F#, Clojure, and Scala.
Event-Based Programming
Event-driven programming was invented basically to handle the special case of GUIs. When you’re running a Graphical User Interface, you typically want to sit idle waiting for the user to perform an action before you respond to it. Rather than have every element on the screen poll to see if it’s been clicked every so often, you instead have an “event loop” that polls for any click anywhere. Different elements subscribe to specific events, such as “was a button clicked” or “did a request from the server complete” or whatnot.
Primarily event-driven languages include Node.JS. Javascript in general is an odd mix of Functional, Procedural, and Event-Driven code, with some Objects thrown in there for extra fun.
What paradigm are you most comfortable programming in? Have you tried all of the above? Let me know in the comments 🙂