Foundations of Functional Programming in Java/TypeScript (Part 1)

Jon Rista

in JavaScript / TypeScript / Functional / Frontend Posted on

07/27/2021 12:00 AM

Functional programming. You've probably heard the term. You may even have dabbled in it. If you are a veteran, this article will not provide any useful new knowledge. Otherwise, keep reading, and start your journey into the world of functional programming.

This is the start of a multi-part series on the Foundations of Functional Programming in JS/TS. This article aims to lay a solid foundation and understanding of functional programming, how it compares to other kinds of programming paradigms and what functions really are.

There are many styles of programming. Far back, in the earliest days of programming, people actually used something called "punch cards" to program computer-like systems. After that we used assembly languages to control the CPU at a very low level.

Higher level languages introduced procedural and functional means of programming computers. From those early languages, much more advanced languages supporting high level imperative, object-oriented, and even more functional capabilities have been developed.

As complex systems emerged, such as relational database systems, more specialized languages came about. These languages, such as SQL, provided domain-specific capabilities and are often highly declarative in nature.

Declarative languages are often targeted to solving specific problems like querying a database. They tend to expose ready-made functionality, allowing the developer to simply state what they need and want done, and the underlying system deals with the nitty-gritty details of actually getting it done.

Let's dive into some of the ways we can program today, clarify what functional programming is NOT, and also cover some of the things we can't or should not do with it.

export const combineCustomersWithOrdersAndFilterHighTotals = (
	customers: Customer[],
    orders: Order[], 
    minTotal: number): CustomerWithOrders[] => {
    let customersWithOrders = [];
    for (const customer of customers) {
	    const customerOrders = [];
	    for (const order of orders) {
		    if (order.customerId === customer.id) {
			    customerOrders.push(order);
		    }
	    }
	    
	    if (customerOrders.legnth) {
		    const total = 0;
			for (const order of customerOrders) {
				total += order.total;
			}
			
			if (total > minTotal) {
	    		const customerWithOrders = {
		    		...customer
		    		orders: customerOrders;
		    	};
			    customersWithOrders.push(customerWithOrders);
		    }
	    }
    }

	return customersWithOrders;
}

Inherent to the imperative style of programming are many potential pitfalls that can give rise to whole classes of bugs. Many of which can often be difficult to track down. Imperative code is often easier to start writing; it is highly explicit about every single aspect of what a given program must do. Exactly what. Exactly how. Reasoning about your code is direct and explicit.

As programs grow, however, imperative code often allows certain idioms to become "crutches" and "focal points" for poor practices. Ultimately leading to large, complex, sprawling codebases that are often harder to understand in the long run than they were to write initially.

abstract class Animal {
	// Fields
	public gender: 'male' | 'female';
	protected _age = 0;
	protected _health: 'healthy' | 'injured' | 'sick' | 'dead' = 'healthy';
	
	// Properties
	public get name(): string {
		return _name;
	}
		
	constructor(
	    // Promoted to fields on construction
		private _name: string, 
		protected _adultAge: number, 
		protected kind: string, 
		protected parent?: Animal
	) {}

    // Methods
	public eat(grams: number): void {
		this._age = this._age + 0.2;
	}
	
	public sleep(minutes: number): void {
		this._age = this._age + 0.33;
	}

	public fight(): void {
		this._health = 'injured';
	}
	
	public procreate(): Animal[] {
		if (this._age < this._adultAge) {
			throw new Error('Animal is not yet mature!');
		}
		
		return [];
	}	
}

Note how properties of a class are often assigned within its functions. This is a mutation of local state: something that, down the road, can potentially lead to obscure bugs. Mutations are Bad (usually)!

In purely functional languages there are no objects. There may be some level of structured data types. However, they would be more akin to the "structs" of C and C++ where they are purely data without functionality. However, for the most part, functions are the only truly first-class behavioral construct.

JavaScript and TypeScript differ here, a bit, in that they do support classes and objects. Classes have their place. However, it is better to use them sparingly and only when essential. Otherwise, aim to keep your JavaScript/TypeScript code functional whenever possible.

If something does not need to reference this...then it really does not need to be a part of a class!! There may be some exceptions to that rule, and often certain frameworks will impose expectations that ultimately force some functions back into classes at one point or another. Unless and until...if you don't need it, don't create a class to encapsulate functions. Refactor as necessary, when necessary, to pull functions back into classes. In fact, whenever possible, expose existing "bare" or "free" functions in classes (as properties) while also keeping the free function for other use cases.

Another key distinction with functional languages, and a very important one for JavaScript/TypeScript developers, is that ONLY functions are used. With a true functional language, you will often, if not usually, find that "assignment" of values to variables does not happen. Assignment in that fashion does not generally exist in a purely functional language and can violate tenets like immutability outside of special contexts.

No variable assignment. I'll let that one sink in for a moment as well.

Consider: how can you write a function without variables, without assignment? Can you? For sure, it is possible! I write such code myself on a daily basis. So, it is possible. Can YOU do it?

By the end of this series of articles, my goal will be to make sure you can!

It does take a bit of a paradigm shift in how you think about software and about how you write your code. As you continue to read, take a close look at the examples that follow and take note of how, without variable assignment and with only function calls, we are able to implement the same behavior as our imperative code example above.

Well, if we don't have variables, what do we have? What can we do and what can we use in functional programming?

We have a lot, actually...in fact, we have many of the same tools we have in other procedural, object-oriented, imperative languages. With JavaScript, we still have objects, which can be useful at times, even if we generally try to avoid them with functional programming! We of course have functions, and not just functions but higher order functions (more in future articles!)

We have parameters that may be passed to functions. We have parameters that may be other functions. We have the return values from functions. Which of course, may also be other functions. Functions accepting functions and functions returning functions are a source of REAL POWER in functional languages.

We have expressions, such as the ternary (b ? t : f) the epitome of basic decision making and branching. We also have nullish coalescing (??), truthy & falsy coalescing (&& and ||), etc. We have standard operators for all those basic little mathematical and logical things we must do in effective programs: +, -, ===, !==, !, %, ^, ~, and so much more.

Expressions and operators provide a significant amount of power to functional programs. The depth of their capabilities is often lost within more complex imperative codebases, where explicit control flow and instructions and override often simpler alternatives, and highly expressive implementations might do the job just as well (and frequently, in far fewer characters!).

Of all the styles of programming originally mentioned, functional programming is often more of a "declarative" style of programming. Not quite as strictly speaking (as is the case with SQL) but with functional programming, we often do rely on the underlying system (language, platform, standard library) to deal with low-level details about getting things done and, more or less, "declare" what we want to do.

At the lowest level, some limited instructional code may exist in the form of basic expressions...but at higher levels, functional programming is highly declarative in nature. We map, filter, and reduce, rather than for, while and do loop. We pattern match or maybe use a ternary, rather than switch or if for branching.

export const filterCustomersWithOrders =
	(orders: Order[]) => (customers: Customer[]) => 
		customers.filter(customer => 
			orders.some(order => order.customerId === customer.id)
		);


export const attachCustomersToTheirOrders =
	(orders: Order[]) => (customers: Customer[]) =>
		customers.map(customer => ({ 
			...customer, 
			orders: orders.filter(order => 
				order.customerId === customer.id
			) 
		}));

export const filterCustomersWithHighTotals =
	(minTotal: number) => (customers: Customer[]) => 
		customers.filter(customer => 
			customer.orders.reduce(
				(total, order) => total += order.total, 0
			) >= minTotal
		);

First off, let's just break down the anatomy of a function. Every function has four basic parts:

1. Function Name *

2. Parameter List *

3. Return Type *

4. Implementation

The starred parts, together, represent the function signature. So at a high level, every function has a signature and an implementation. In some contexts, a function may have more than these four basic parts. With methods in a class, we may also have accessors, and with TypeScript, we may also have generic type definitions and restrictions.

5. Accessors *

6. Generic Type Definition *

These two additional parts also comprise the signature, adding more specificity. A quick example function and breakdown of its parts:

In a purely functional language, you will usually have lots of functions. If you enforce the rule of no assignments then you will often find that longer and more descriptive function names are not only useful but often essential (if simply to avoid function name conflicts or convoluted coded names when trying to keep them short).

Function names are one of the few cases where I call for some verbosity. This is not a bad thing. Be descriptive, at least to a degree. Allow your function names to support self-explanatory code. I find that well-disciplined developers will name their functions as descriptively as they can; according to not only what they do but also where and how they are usually used. In other words, contextually descriptive.

Identifiers in general should be as short as you can make them but with function names (in contrast to parameter, variable, and class names). I tend to prioritize descriptiveness over brevity (rare case!). You will see more about why as you continue to read through the article.

// ---- identifier --v
export const findCustomerNamed = 
	({ first, last}) => (customers: Customer[]) => 
		customers.find(customer => 
			customer.first === first && customer.last === last
		);
// -------- identifier --v
export const attachAddressToCustomer = 
	(address: Address) => (customer: Customer) => 
		customer 
			? { ...customer, address } 
			: customer;

// ----------- identifier --v
export const findCustomerAndAttachAddress = 
	({first, last, address}) => pipe(
		findCustomerNamed({first, last}),
		attachAddressToCustomer(address) 
	);

Many functions, although not all functions, may also specify one or more input parameters. Input parameters are anything passed to the function when called that the function may reference within the body of the function. Parameters, similar to variables, may represent scalar values (primitives: number, boolean, string, Date, Symbol, etc.) or complex values (objects, arrays, tuples (with TS), custom types (especially with TS), or even other functions!).

Parameters are a very important aspect of functions in general but often critically so with functional programming. They are the primary source of data and how we deal with parameters & provide them to each function, how we process the inputs and convert them to outputs, is a fundamental functional design aspect.

With pure functional programming, nested scopes may become common and the possible cases where "hiding" identifiers from a parent scope with identifiers from a child (more nested) scope may increase in frequency. Use descriptive names & avoid hiding identifiers.

Parameter names need not be complex. They need to be unique and specific enough to be properly understood within the context they are used. In some cases, you may find that refactoring parameter names helps to be more specific and less prone to conflict with child scopes (i.e. nested functions that may, in and of themselves, need to use similar parameters). This is an easy improvement if and when necessary:

A small tip for those who like to optimize. You can optimize yourself and the way you work as well! As programmers, we type...a lot. A LOT! It is basically what we do, day in, day out, 8, 10, 12 hours a day. One of the biggest efficiency wins you can give yourself...is to find ways to type less! To that end, be descriptive, clear, and explanatory as possible, whenever possible, with as few characters as possible! These two goals may seem at direct odds with each other...and fundamentally they are...but at times opposing yet concurrent goals lead to the best outcomes!

Note that this recommendation for function parameter names is in some cases at odds with my recommendation for function names. Parameters have a clear and specific local context...the function. That context provides meaning to parameters. Functions, on the other hand often have little to no local context, if they have any clear context in the greater application as a whole outside of the filename they are declared within. Function names, therefore, can often benefit from a certain amount of verbosity.

The next part of a function is its return type. Some functions may not have a return value, others may have a return value, and some may return an object or an array, or even a tuple (an array of fixed length with fixed value potentials at each index). By default, technically the return type of any function in TypeScript is any, which aligns with the arbitrary and dynamic nature of JavaScript. In some cases, the return type of a function may be inferred from its implementation, and that inferred type may be used down the line when the return value is passed to other functions.

With TypeScript, return types may be quite complex and may support a wide range of potential output scenarios for a given function, even going so far (with clever generic type definitions) as to DENY usage of a function if a proper output type cannot be inferred from the functions inputs during actual use.

Finally, when using TypeScript, remember that the implicit return type of each function (if not explicitly specified) is usually any, although that can potentially become unknown or even never at times, depending on the exact implementation of the function, other functions it may call, and specific nuances of generic type definitions.

If a function should NOT return a value, then it should be specified as void, or potentially Promise<void> to ensure that TypeScript can validate that no return values are actually returned by the function's implementation. This helps avoid potential subtle classes of bugs.

For now, this provides a base foundation for functional programming. The plot is cleared, prepped, and graded. Not only should you have a clear understanding of the different parts of a function: you should be able to explain the structure and nature of a function to other developers.

You should also understand some of the best practices involved in naming those parts as well as how to declare functions in an efficient manner with minimal waste. The nomenclature used to describe various parts of a function and best practices, introduced here, around declaring and implementing will be foundational to subsequent articles in this series.

Finally, this article should have imparted at least a high-level understanding of what an arrow function is and to a very basic degree what higher order functions are. We will be exploring these specific concepts as well as concepts like currying, applying curried functions, composing functions with pipes, and Array method chaining. Even leveraging TypeScript generics to constrict typings and enable richer code-time type checks in functional code and more in future installments.

Foundations of Functional Programming in Java/TypeScript (Part 1)

What is functional and what are functions?

"Functional" Programming

What It's Not

Not Imperative

Not Object Oriented

No Variables!

What It Is

What DO we have?

Declarative in Nature

What's Missing Here?

Functions

Function Anatomy

Function Name

Descriptive, Self-Explanatory

Input Parameters

Parameter Names

Return Type

In JavaScript

In TypeScript

Implementation

Prepped and Graded!

Need Support With a Project?

Recent posts

Sharing Knowledge is in our DNA