DEV Community: Hunter Henrichsen

Functional Programming in JavaScript

Hunter Henrichsen — Tue, 02 Jun 2020 18:12:38 +0000

Functional programming is a really useful tool to have in your toolbox. For me, it's changed how I design solutions to a bunch of different problems.

What is Functional Programming?

Functional Programming is a programming paradigm where everything is a function, and the goal is to keep everything straightforward and mathematical. Variables are intended to be kept immutable, at least on a function-level, and are expected to do what they say without any side effects. A function printObject should not also add a field to the object it takes.

The most important part, though, can be inferred from the name of the paradigm: Functional Programming. In Functional Programming, functions are the most important. Normally, this takes the form of allowing them to be stored in variables, allowing them to be used in many of the same places where we could use any other type of variable.

There are many different purely functional languages out there, but for this post I'll be focusing JavaScript. I'm going to break it down into two pieces, with the first focused on built-in tools that allow for the use of Functional Programming, and then move onto how we can create our own functions and tools that use Functional Programming.

Functional Programming in JavaScript

JavaScript is very function-first. Assigning functions to variables is an important way to create them!

const printHello = function() {
    console.log("Hello!");
}

printHello();

Not only this, but there are multiple ways to create functions. One such way is using the function keyword like above, or using the function keyword before the name of the function.

function add(firstNumber, secondNumber) {
    return firstNumber + secondNumber;
}

console.log(add(2, 4)); // Prints "6"

A third way to create functions is using arrow notation.

const yellToConsole = (message) => {
    console.log(message.toUpperCase());
}

yellToConsole("Hello!"); // Prints "HELLO!"

There are some nuances between arrow and normal functions in JavaScript, which appear in the header of the MDN page for arrow functions.

Because doing things this way is not the only way to do things in JavaScript, it's said that JavaScript is not a purely functional programming language, but the primary aspect of Functional Programming--that functions can be assigned to variables--is an important piece of the language.

The Standard Library

Two of the main places that I see functional programming in the JavaScript standard library are Array Functions and Callbacks, especially when expanded to include many commonly-used libraries like Lodash.

Each array comes with some additional functions attached.

`Map`

The map function takes a function as it's argument, and transforms the array into something else.

const numberList = [1, 2, 3, 4];

const stringList = numberList.map((number) => number.toString()); // ["1", "2", "3", "4"]

Here I'm creating an arrow function as it's parameters, but you could just as easily accomplish the same by declaring a function any other way, then passing the reference to that function to the map function.

const numberList = [1, 2, 3, 4];

function square(number) {
    return number * number;
}

const squareList = numberList.map(square); // [1, 4, 9, 16]

`Reduce`

Reduce does a similar transformation, with the added effect of combining things together. It's used to convert an array into a single value.

const numberList = [1, 2, 3, 4];

const sum = numberList.reduce((currentSum, number) => currentSum + number, 0); // 10

Notice how we get the currentSum parameter to the function? That's called an accumulator, and represents everything that's been combined so far. We also have a 0 at the end of the function call, which tells JavaScript what that accumulator should start with. This can be an empty string, if we were building a string up based on the elements in the list.

`Filter`

Filter takes a function that's used to decide if something should remain in a list, then returns a new list of things that were supposed to remain in the list. The function that filter takes is called a predicate because it takes one value, and returns either true or false based on some logic.

const numberList = [1, 2, 3, 4];

const evens = numberList.filter((number) => number % 2 === 0); // [2, 4]

Filter can also be used to delete items from a list that we can't modify. How do you think we'd accomplish that?

`Some`

Some is a combination of filter and reduce. It's used to determine if any of the values in the list match the predicate.

const numberList = [1, 2, 3, 4];

const isOneInList = numberList.some((number) => number === 1); // true

Callbacks

Callbacks are used to perform processing when something finishes. These can be chained together to allow complex processing, but can become confusing when they get nested into many layers. This confusion is part of what the motivation for async/await was. Functions inside of then blocks are callbacks in Promises.

fetch('https://api.github.com/gists/e59384900942ee13af189bf92c7adfef')
    .then(response => response.json())
    .then(json => console.log(json.description)); // Prints "Predication in C# collections."

Each of these .then calls takes a function, and whatever it returns is passed to the next .then call.

Doing It Yourself -- Writing a simple Some function

So knowing how to use these is important, but let's write our own. An easy one to do would be to recreate the some function that I showed up above. First, I'm going to decide on a signature for this function. It needs to take a list, and a function. I'm going to write a specification for these using JSDoc.

/**
 * @callback anyMatch~predicate
 *
 * A predicate that applies to any item.
 *
 * @param {any} item The item to check this condition on.
 * @returns {boolean} Whether this condition passed or not.
 */

/**
 * Imitation of the array 'some' function.
 * 
 * @param {any[]} list The list to process.
 * @param {anyMatch~predicate} predicate The predicate to apply to each item.
 * @returns {boolean} Whether any item in this list matched this condition.
 */
const anyMatch = function(list, predicate) {

};

Next we can loop through, checking each item against the predicate:

const anyMatch = function(list, predicate) {
    for(const item of list) {
        if(predicate(item)) { // The item matched the predicate.
            return true;
        }
    }
    return false; // Nothing matched the predicate.
};

Notice how we can call predicate just as if it were any other function? That's all there is to it. Now let's run some tests:

console.log(anyMatch([1, 2, 3, 4], (item) => item === 1)); // Prints "true"
console.log(anyMatch([1, 2, 3, 4], (item) => item === 5)); // Prints "false"

And it's working! I hope this was at least a little enlightening. What common scenarios do you see approaches like this working for? Let me know in the comments.

5 Lessons from Writing a Compiler

Hunter Henrichsen — Wed, 13 May 2020 04:01:25 +0000

Introduction

I'm still a student, but I'm seeing the light at the end of the tunnel. Normally I do pretty well in classes, but this class had me questioning whether that light was the end of the tunnel, or an oncoming train. The goal of this class was to take a language that the professor had written the specification for, and to write code to convert it to MIPS Assembly that we could run, while learning about the different parts that go into writing that code.

I learned a lot over the course of this project. Not all of it was about algorithms or compilers. Here's what went down, and here's what I learned from it.

Classes, Trees, and Experiences

Notes on automata and graphs, with lots of epsilon edges.

This class and its attached project were scary starting off. Rumors went around from past students about how hard the subject matter was. The professor himself even talked about how this class would be extremely difficult for the first few class periods, and I started to notice empty seats around me in the class as time went on.

Nevertheless, I persisted. Pridefully.

The class was broken up into pieces. The first piece discussed the algorithms and structures that are used to convert text in a file into something that we can use to simulate how want the program to work, the Abstract Syntax Tree. This was some of the most tedious and frustrating work that I've had to do in my six years working in code, and thus took me a long while to get through. I still held my head high, thinking that I would be able to do it.

The next piece we spent some time working with that tree, squishing nodes together where we could so that we could more efficiently use resources available, and getting things out of that tree where we couldn't. The main meat of this piece was making simple math expressions and some basic functions work. This code is the foundation for the project, and mistakes here have far-reaching consequences. At this point, I was really behind.

The third piece was about using those primitive types from the previous piece to build up custom types and arrays. These are dramatically more complex than the simple pieces above, and are expected to work in the same situations. This portion required me to make sweeping adjustments to my entire code, and I was thoroughly humbled. I got worried enough about it that I dropped the class, and focused on other work that needed to be done.

I wouldn't be writing this if I hadn't made it all the way through. I was extremely lucky, and given a unique opportunity to join back into the course. The last piece was about writing logic with these, the important pieces that make up what we use to program. Things like if statements, for loops, and while loops all fall under here.

We had planned to do some on functions, but we didn't get around to it with many adjustments to how class was delivered. After all of this, I'm glad that those adjustments were made.

Lessons

I learned a bunch of lessons about compilers and some code in general, but after having a few weeks to reflect, I've decided that those lessons weren't the most important things. Here's what I learned.

Lesson 1: Be Humble

Assembly code to print "Be Humble."

I came into this class with a bad attitude, and I ended up burning myself in the process. I approached this class with confidence because I spent some time preparing before this class on what I thought would be important. It wasn't.

I ended up facing (and eventually overcoming) problems that I didn't know how to solve, and because of my attitude, I ended up nearly failing. This was an experience that showed me that despite what I think, I have a long way to go, and a lot more to learn.

Lesson 2: Don't Be Afraid To Ask For Help

I was about halfway through writing the basic handling for expressions with less than a month left. I was behind, very behind. I sat for hours, moving text between files and going nowhere. It was close to 1AM one late night when I finally broke and started talking to some of my classmates about what they were doing, and shared my own ideas. Ironically, they were awake and working on the same portion of the project.

They really helped me out, and walked me through some of the decisions that they had made while designing their solutions to the problems. Later on in the project, I was given the opportunity to give back to some other individuals who had fallen behind, and I was grateful that I was able to be one of those individuals for someone else.

Lesson 3: Push through frustration

I spent a lot of time on the beginning of the project, because the first steps of writing a compiler are setting up recognition for the parts that make up the language. Every character, every symbol, and every keyword needs to be recognized and grouped. Writing that code manually is awful, but it's the only way to do it.

As awful as writing all of that code upfront was, having that code available in the end saved me a lot of headache. Not to mention that the gratification from having all of that finally finished was amazing, and then I got onto the next section and ran into the same thing, then seeing my computer print 2 from write(1+1) was amazing.

Lesson 4: Not Everything Comes Out Neat

Messy debugging comments within some assembly.

I came in with the idea that I could write this cleanly, as I always try to do. Keep things neatly contained in their own boxes and files, piece them together with bigger boxes, etc. That was not the case.

My code used 9 globals, had numerous cases of static-abuse, didn't manage memory, broke completely when it encountered anything it didn't expect, had files strewn all over the place, and many, many more things that I would consider to be dangerous or "unclean."

And that's fine.

This code doesn't run anything critical. No one else is going to use it. Not everything fit into the boxes that I wanted them to fit into. Sometimes I didn't have time to refactor everything the way I wanted to. But it still works, and fulfills the needs that it's expected to, and I'm okay with that.

Lesson 5: Test and Automate

This is the most concrete, but one of the most important. For the first few months of the class, I had no idea if my code was working. If I changed something, I had no idea if it had just undone a week's worth of work. Halfway through I decided that I didn't want to do this anymore, so I wrote some scripts. They were simple little things that saved me some typing, and gave me the ability to be confident that when I made a change, I wasn't hurting the work I already did.

Then I wrote scripts that ran through that, and told me how well I was doing. Seeing the script spit out successes where it had previously failed was motivating, extremely so, and doing this has motivated further testing efforts in some of my other endeavors.

All in all, I'm glad I had the opportunity to take this class, and I'm looking forward for new ways that I can use what I've taken from it in some of my other projects.