golden-demise

Recursion has always been a difficult concept for me to wrap my head around. Consequently, Closure in Javascript is also difficult to understand. Here's a brief series of exercises on Front End Masters, written here mostly to organize my thoughts and try to cement the concepts I've learned.

Consider the following function that takes an argument, and returns a function that returns that argument:

const identityf = arg => {
    return function(){
        return arg
    }
}

This is possible because of Closure, in which the context of an inner function includes the scope of the outer function. Nested functions can see block variables. On the back end, this involves using the heap instead of the stack to allow child functions to operate once the parent function is exited.

Things get more complex when you return functions:

// A function that takes a binary function, and makes it callable with two invocations
// For instance, calling liftf(multiply) (5) (6) would return 30
const liftf = func => {
    return function (first) {
        return function (second) {
            return func(first, second);
        };
    };
}

The reason that the multiple invocations(the (5) and (6) in the comments above) are possible is that the function is itself returning functions, and subsequent invocations are passed as arguments to the child functions. Multiple returns don't break the function because again, the child functions can operate even after the parent functions exit.

The process of breaking down functions with multiple arguments into a chain of single return functions is known as currying.

// This function takes a binary function and an argument, and returns a function that can take a second argument

const curry = (binaryFunction, arg) => {
    return function(secondArg){
        return binaryFunction(arg, secondArg);
    };
}

curry(add,2)(7); // is equal to 9

(Update 12/21, I wasn't on Manjaro for longer than a week before an update broke my finicky killer wifi card, and am back on Pop/Debian presently) I've recently switched employers, from a notoriously grindy place to work to a more people-centric place to work. I'm still in training, and consequently don't have any insight yet into how all of that is going to translate into my day to day work, but I've found myself in a place where I didn't foresee myself being- a Manjaro user.

I've dabbled in MANY Linux distributions over the years, and typically use either Ubuntu based distributions (for compatibility/easy targeting) or OpenSUSE Tumbleweed when I want cutting edge package versions. My new employer sent me a Dell XPS 15 with an i9 processor- which also features Qualcomm WiFi that doesn't currently have spectacular support (this support is provided by the ath11k kernel module). None of the Ubuntu, Fedora, OpenSUSE, or Arch ISOs were able to detect the WiFi card out of the box(despite the presence of the ath11k module and brand new kernel version in some cases)– which was a significant problem for me as I had no desire to compile a kernel just to use my wifi. I also didn't particularly want to ask my employer for a different computer, or buy a separate card out of pocket that is better supported as I often saw mentioned as a 'solution'.

I finally tried a Manjaro ISO out of desperation, and was pleased to find that it worked nominally with the WiFi card- until I installed it. I then was able to get things running by taking the steps in an Arch wiki article related to a similarly afflicted XPS model.

I'm definitely still getting the hang of pacman, but I'm already enjoying the presence of the AUR. It's a very nice looking system too, and clearly lots of effort has been put into customizing the look and feel of their GNOME/KDE spins, but I don't think I like the overtness of the Manjaro branding being present in my terminal (as default part of the preconfigured powerline prompt). Additionally, the experience has been rough around the edges overall (weird but non breaking errors in the package manager, lots of trouble with suspend/reboot/sound), though I attribute most of this to the markedly Linux hostile hardware.

I'll aim to update this again in the near future- though I don't see myself switching from my traditionally utilized distros yet, I'm definitely keeping an open mind. Here's hoping things stay stable as I'm ramping up at work, and that better hardware drivers make their way into the kernel.

Enter your email to subscribe to updates.