Forem: Joshua Newell Diehl

JavaScript - Writing Functional Flows with Custom Pipes

Joshua Newell Diehl — Tue, 17 Oct 2023 19:43:55 +0000

A very simple coding problem is often encountered early on in one's journey through programming, as it is a precursor to more interesting problems. It usually reads something like this:

Given an alphanumeric input of type {string},
write a function that returns a string in the reverse order

We'll use this familiar problem as the contrived basis for demonstrating the awesome possibilities of functional pipes.

Now, some may well have gotten cozy with the use of slick libraries like ramda and lodash, but perhaps fewer have a solid understanding of the mechanisms used.

The star player

We'll start by taking a patient look at the custom JavaScript pipe implementation that we'll use in the examples to come.

I've also included a more traditional syntax for all the mustache heralds out there (let us know in the comments what syntax you prefer!):

const pipe = 
     (...functions) =>
     (val) =>
        functions.reduce((prev, func) => func(prev), val);

// 
// OR
//

function pipeB(...functions) {
     return function(val) {
          return functions.reduce((prev, func) => {
               return func(val)
          }, val)
     }
};

Those of us accustomed to writing Object-Oriented programs may find this syntax foreign. It uses functional techniques like currying and closures that will allow us to wrap, or decorate, our other functions.

The key operation, though, is the reduce that we call on our functions.

Let's break this down a bit.

We can deduce that:

The pipe accepts a series of functions and returns a function.
That function accepts a value and returns a reduce function that we call on our series of functions.
Every time our reducer iterates, one of our functions consumes the value and passes its output to the next function

What does all that do for us, then?
So, every one of the functions that we supply to the pipe will consume our value in a step-by-step sequence, one after the other. Here's where the concept of a pipe and it's semantic exactness begins to wax into full shape.

Imagining the purpose and form of a series of interconnected pipes, we can lay out a few functions with the expectation that they will be similarly pieced together:

const splitString = (string) => string.split("");
const reverseArray = (splitString) => splitString.reverse();
const joinArray = (reversedArray) => reversedArray.join("");

Now let's create a custom flow with the pieces of our pipe:

const reverseStrFlow = pipe(splitString, reverseArray, joinArray);

The result here is a new function that accepts a value, so consuming our input will look like this:

const reversedString = reverseStrFlow(stringToReverse);

Finally, here is our code all together with example i/o:

const pipe = 
     (...functions) =>
     (val) =>
        functions.reduce((prev, func) => func(prev), val);

const splitString = (string) => string.split("");
const reverseArray = (splitString) => splitString.reverse();
const joinArray = (reversedArray) => reversedArray.join("");

const reverseStrFlow = pipe(splitString, reverseArray, joinArray);

const testString = "peloponnesian pumpkin";

const reversedString = reverseStrFlow(testString);
// expected output: "nikpmup naisennopolep"

For the record, one would rarely find meaningful need to write this much code for a problem slayable by a sexy one-liner:
const reverseString = (string) => string.split("").reverse().join("")
I only hope to diminish the what in order to clarify the how:

By flowing our value through a pipe made of functional pieces!

A key point in beginning to imagine the usefulness of this technique is to remember that we can create any number of custom pipes with any number of functional pieces that we need. This makes the composition of complex operations possible with less code.
The benefits of the compositional style are numerous:

Reusability

Building in pieces allows for many possible unique combinations

Testability

Test for simple inputs and outputs

Ease of debugging

Smaller pieces, smaller problems

Avoid the pitfalls of inheritance

Ditch complex inheritance hierarchies that carry dead weight

...and many more

Now that we've tantalized your tasters with some functional flavors, let's wrap things up with a final working example, this time with syntax highlighting:

Full Code on Repl

I'm honored if you've read this far ...

Keep going, keep growing, and don't forget to have fun!

Until next time,
Joshua

Side by Side Series: Rust & Go - The Builder

Joshua Newell Diehl — Wed, 27 Sep 2023 22:59:25 +0000

Welcome to the very first episode in my side-by-side series!

Our work is to explore the unique implementations of various design patterns in two popular languages.

Our goal: to obtain a clearer understanding of language-agnostic strategies that can be applied to nearly any programming project!

The experiments in this series are best suited to readers with prior programming experience.

Important Notes

Though the examples used do emulate a practical use case to some extent, they are in no way meant to represent "the best" way of doing things. In the interest of not distracting from the underlying pattern in question:
Examples make use of core libraries but avoid third-party packages wherever possible.
Performance implications are ignored.

The Pattern

A definition excerpted from my favorite design patterns reference:

"Builder is a creational design pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code." - Refactoring Guru

In contrast to a tightly-coupled inheritance model, the Builder Pattern offers a compositional approach to instantiating objects. It empowers us to accomplish a kind of polymorphism by using the same core constructors to account for a variety of possibilities, all while designing code that is organized and safely encapsulated.

Our example features a derived example of a "Configuration Builder", wherein our app's Server configuration can be constructed piece by piece without concern for empty fields, as the builder pattern allows us to directly manage the population of each field in the object.

The Implementation

PSEUDOCODE

Define a struct for a configurable object.
Define a builder responsible for populating its optional fields.
Begin with an empty object which can be incrementally "built".

The code in both examples is made public for the sake of consistency.

Rust

// RUST

struct Config {
    address: String,
    port: u32,
    secure: bool
}

pub struct ConfigBuilder {
    address: Option<String>,
    port: Option<u32>,
    secure: Option<bool>
}

impl ConfigBuilder {
    pub fn new() -> ConfigBuilder {
        Self {
            address: None,
            port: None,
            secure: None
        }
    }
}

Go

// GO

type Config struct{
    address string
    port uint32 
}

type ConfigBuilder struct {
    address string 
    port uint32
}

func NewConfigBuilder() *ConfigBuilder {
    return &ConfigBuilder{}
}

The apparent redundancy in the Go code is a bit off-putting at first. Why do we plan to implement two different structs with seemingly identical fields?

We'll see how the builder pattern will allow us to overcome the lack of a nil-handling type and respond to the inevitability of emptiness | ^_^ |.

PSEUDOCODE

Implement methods to set each field on the Builder struct.
Implement a build method that returns a completed struct with the appropriate fields.

Rust

// RUST

... // snipped

impl ConfigBuilder {
    pub fn new() -> ConfigBuilder {
        Self {
            address: None,
            port: None,
            secure: None
        }
    }

    pub fn set_address(mut self, addr: String) -> Self {
        self.address = Some(addr);
        return self;
    }

    pub fn set_port(mut self, port: u32) -> Self {
        self.port = Some(port);
        return self;
    }

    pub fn set_secure(mut self, secure: bool) -> Self {
        self.secure = Some(secure);
        return self;
    }

    pub fn build(self) -> Config {
        Config {
            address: self.address.unwrap_or_default(),
            port: self.port.unwrap_or_default(),
            secure: self.secure.unwrap_or_default(),
        }
    }
}

... // snipped

Go

// GO

... // snipped

func (cb *ConfigBuilder) setAddress(addr string) {
    cb.Address = addr
}

func (cb *ConfigBuilder) setPort(port uint32) {
    cb.Port = port
}

func (cb *ConfigBuilder) setSecure(secure bool) {
    cb.Secure = secure
}

func (cb *ConfigBuilder) build() *Config {
    if cb.Port == 0 {
        cb.Port = 3001
    }

    if cb.Address == "" {
        cb.Address = "127.0.0.1"
    }

    return &Config{
        Address: cb.Address,
        Port:    cb.Port,
        Secure:  cb.Secure,
    }
}

... // snipped

Notes

My understanding is that method chaining is not entirely idiomatic in Go, but Rust, in contrast, favors this syntax.

This is why Rust's builder methods return Self, while Go's do not.

In either case, only once build is called do we return a completed struct.

PSEUDOCODE

Construct an object using the builder.
Print the resulting object using a custom display implementation.

Rust

// RUST

... // snipped


fn main() {
    let cfg = ConfigBuilder::new()
        .set_address(String::from("127.0.0.1"))
        .set_port(8080)
        .set_secure(true)
        .build();

    println!("{cfg}");
}


impl std::fmt::Display for Config {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(
            f,
            "PORT: {}\nADDRESS: {}\nSECURE: {}",
            self.address, self.port, self.secure
        )
    }
}

... // snipped

Go

// GO

... // snipped

func main() {
    bldr := NewConfigBuilder()
    bldr.setAddress("128.20.10.3")
    bldr.setPort(8080)
    bldr.setSecure(true)

    config := bldr.build()

    config.display()
}

func (c *Config) display() {
    fmt.Printf("PORT: %v\nADDRESS: %v\nSECURE: %v", c.Port, c.Address, c.Secure)
}

... // snipped

Everything Together

Rust Final

// RUST

fn main() {
    // method chaining! lookin' good
    let cfg = ConfigBuilder::new()
        .set_address(String::from("127.0.0.1"))
        .set_port(8080)
        .set_secure(true)
        .build();

    // Print struct as defined by our std::fmt::Display implementation
    println!("{cfg}");
}

// what we're building
pub struct Config {
    pub address: String,
    pub port: u32,
    pub secure: bool,
}

/*
Rust std lib includes a standardized trait for implementing
a custom display method!
*/
impl std::fmt::Display for Config {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(
            f,
            "PORT: {}\nADDRESS: {}\nSECURE: {}",
            self.address, self.port, self.secure
        )
    }
}

// The struct responsible for creating our Config
pub struct ConfigBuilder {
    address: Option<String>,
    port: Option<u32>,
    secure: Option<bool>,
}

impl ConfigBuilder {
    // instantiate empty
    pub fn new() -> ConfigBuilder {
        Self {
            address: None,
            port: None,
            secure: None,
        }
    }

    pub fn set_address(mut self, addr: String) -> Self {
        self.address = Some(addr);
        return self; // enable method chaining
    }

    pub fn set_port(mut self, port: u32) -> Self {
        self.port = Some(port);
        return self;
    }

    pub fn set_secure(mut self, secure: bool) -> Self {
        self.secure = Some(secure);
        return self;
    }

    pub fn build(self) -> Config {
        /* 
        Since Option is a Rust type, it comes with a plethora of 
        useful methods out-of-the-box.
        unwrap_or_default() will either return the value wrapped 
        in Some or the default for that value.  (All primitives 
        have clearly-defined defaults)
        */
        Config {
            address: self.address.unwrap_or_default(),
            port: self.port.unwrap_or_default(),
            secure: self.secure.unwrap_or_default(),
        }
    }
}

Go Final

// GO

package main

import "fmt"

func main() {
    // call methods line by line in Go?
    bldr := NewConfigBuilder()
    bldr.setAddress("128.20.10.3")
    bldr.setPort(8080)
    bldr.setSecure(true)

    config := bldr.build()

    config.display()
}

// The object we're building
type Config struct {
    Address string
    Port    uint32
    Secure  bool
}

// a helper method for custom printing
func (c *Config) display() {
    fmt.Printf("PORT: %v\nADDRESS: %v\nSECURE: %v", c.Port, c.Address, c.Secure)
}

// struct responsible for creating our config
type ConfigBuilder struct {
    Address string
    Port    uint32
    Secure  bool
}

func NewConfigBuilder() *ConfigBuilder {
    return &ConfigBuilder{}
}

func (cb *ConfigBuilder) setAddress(addr string) {
    cb.Address = addr
        // not returning self
}

func (cb *ConfigBuilder) setPort(port uint32) {
    cb.Port = port
}

func (cb *ConfigBuilder) setSecure(secure bool) {
    cb.Secure = secure
}

func (cb *ConfigBuilder) build() *Config {
        // simple, traditional handling of defaults
    if cb.Port == 0 {
        cb.Port = 3001
    }

    if cb.Address == "" {
        cb.Address = "127.0.0.1"
    }

    return &Config{
        Address: cb.Address,
        Port:    cb.Port,
        Secure:  cb.Secure,
    }
}

Side-by-Side, PRETTIFIED

The Insights

The Rust standard prelude includes some powerful tools for implementing the Builder Pattern in Rust.

Namely, the std::Option enum type. Option offers versatility and expressiveness without sacrificing clarity. It is a safer, more semantic alternative to the empty nil type.
The Option type is simple.

There are only two variants:

Some(T), where T is generic over any type, and
None

The Option type allows us to easily maximize the flexibility offered by The Builder Pattern.
Deciding on our own how best to represent an empty value isn't necessary.

Both Go and Rust forgo more traditional Object-Oriented features like inheritance. Instead, we first define custom data structures, and then define separately their implementations.

The inherently decoupled nature of these languages encourages composition. One could write structs representing more complex combinations of builders without modifying or duplicating the underlying implementation details of any!

Conclusion

I hope you had fun exploring The Builder Pattern as represented by these two powerful, comparable, but ultimately unique languages.

We should always remember that while we write code for execution by the computer, the design of our code is an effort made to ease the burden on ourselves and others in understanding our work.

Keep going,
keep growing,
and don't forget to have fun!

Essential React Hooks

Joshua Newell Diehl — Mon, 07 Aug 2023 20:01:39 +0000

Though this article may be enjoyed by anyone curious, the content is best suited to TypeScript developers who have some experience with React.

HOOKS

useNewTab
useViewportQuery
useClipboard
useIntersectionObserver
useCursorPosition

Starting off simple,

we want our domains visible to the user as long as possible, and we'd rather not eat their bread crumbs. useNewTab.

useNewTab

const useNewTab = (url: string) =>
  window.open(url, "_blank")

Often all we really want is to open a tab, but the .open method call actually returns a handle to the new window, allowing for some neat possibilities programmatically. At the behest of cross-site protections, of course.

I recently encountered a situation where

the client ordered a full-size pdf document display on viewports of laptop size or larger, but wanted a simple download link for the pdf on mobile viewports. I needed to conditionally render components based on viewport size. Enter useViewportQuery.

useViewportQuery

function useViewportQuery() {
  const [dimensions, setDimensions] = useState([window.innerWidth, window.innerHeight])

  useEffect(() => {
    function handleResize(_: UIEvent) {
      // There are other dimension properties on the window as well, 
      // such as outerWidth and outerHeight
      setDimensions([window.innerWidth, window.innerHeight]) 
    }

    window.addEventListener('resize', handleResize)

    // Don't forget to clean up!
    return () => window.removeEventListener('resize', handleResize)
  }, [])

  return dimensions;
}

// Since the hook returns a tuple, we can call it like this:
const [width, height] = useViewportQuery();

Dig this one? Check out the Resize Observer API for related strategies.

The browser is full of delicious APIs

which a couple of our custom hooks make use of. This first one, using the Clipboard API, can make copying important text content from the webpage breezy and painless for our users.
Bear in mind that there are many different ways to go about this, so I've included a couple different examples. Be sure to research browser compatibility before making a decision.

useClipboard

/* 
Here our goal is to simply write text to the clipboard,
so we return a boolean so we can handle any errors at the call site.
*/
const useClipboardWriter = async (text: string): Promise<boolean> {
  try {
        await navigator.clipboard.writeText(text)
        return true;
    } catch (err) {
        console.error("Failed to write to clipboard ... ")
        return false;
    }
  }

/*
Here's a more complete implementation, with most of the code 
simply accounting for the fact that the clipboard API is
asynchronous and error-prone.
*/
export function useClipboardManager() {
    const { clipboard } = navigator;

    const read = async () => {
        try {
            await clipboard.readText();
        } catch (err) {
            throw new Error("Failed to read clipboard text...") 
        }
    };

    const add = async (text: string) => {
        try {
            // read-append-overwrite
            // local storage vibes?
            const current = await read();
            await clipboard.writeText(current + text);
        } catch {
           throw new Error("Failed to add text to clipboard...")
        }
    }

    const clear = async () => {
        try {
            await clipboard.writeText("")
        } catch {
            throw new Error("Failed to clear clipboard text...")
        }
    }

    return [read, add, clear]
}
/* Similar to how react hooks such as useState return setters,
we return functions that manage the clipboard's state.  
We don't need to store anything in our component's state 
because the browser stores the clipboard for us.
*/
const [read, add, clear] = useClipboardManager();

Note that the user must provide permissions for your web app to access the clipboard API.

When I first discovered the Intersection Observer,

I couldn't help wondering how I hadn't encountered it sooner. The API offered the ideal solution to problems I had previously encountered, such as triggering an animation when an element comes into view.

useIntersectionObserver


function useIntersectionObserver(ref: MutableRefObject<any>) {
  const [isIntersecting, setIntersecting] = useState(false);

  useEffect(() => {
    // Define what happens when our referenced element is 'observed',
    // or has been 'intersected'
    const options = {
      // root: window,  // We can set the visibility basis manually here,
      // but the default of 'window' is what we want
      threshold: 1, // 100% of the element must be visible within the 'root'
    }
    const observer = new IntersectionObserver(
      ([entry]) => {
        // Synchronize state locally
        setIntersecting(entry.isIntersecting);
      },
      options, 
    );

    // Observe our element if a reference exists
    ref.current && observer.observe(ref.current);

    return () => {
      observer.disconnect();
    };
  }, [ref]);

  return isIntersecting;
}

// Now that our hook is established, all we have to do
// is call pass our element reference within the component
// and respond to the boolean state accordingly,

const intersectRef = useRef(null);

const isIntersecting = useIntersectionObserver(intersectRef);

// e.g. if (isIntersecting) { playAnimation() };

I believe that user interaction is the key feature

that sets software apart from other forms of media. Unlike audio, video, or text, software depends on the user's participation, and it is up to the engineer to ensure the user feels that their interactions are impactful or meaningful in some way.
The mouse provides a rich source of eventfulness for the UX designer. Every movement, click, and scroll can be tracked and responded to accordingly.
The following hook, useCursorPosition, makes it incredibly simple to track the state of the mouse cursor.

useCursorPosition


type CursorPosition = { x: number; y: number };

function useCursorPosition(): CursorPosition {
  const [position, setPosition] = useState<CursorPosition>({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (e: MouseEvent) => {
      setPosition({ x: e.clientX, y: e.clientY });
    };

    window.addEventListener("mousemove", handleMouseMove);

    return () => {
      window.removeEventListener("mousemove", handleMouseMove);
    };
  }, []);

  return position;
}

// Not much to comment on here.  
// The hook returns a simple object with {x, y} mouse coordinates.

const { x, y } = useCursorPosition();

Conclusion

The possibilities with custom hooks are endless, and I fully expect to amend this list in the near future as my adventure continues.
In the meantime:
Keep going, keep growing, and happy coding!

Fancy Fun w/ Functional Decorators

Joshua Newell Diehl — Fri, 30 Jun 2023 17:32:39 +0000

The following discussion assumes familiarity with writing functions in a high-level programming language.

TLDR; Skip to the goodies.
Skip to cache implementation
Skip to execution
Results

The decorator pattern provides a concise and elegant way to add functionality to pre-existing code. The programmer may write the decorating function once and thereafter decorate any number of functions, anywhere. Sound like too much freedom? As is the nature of programming, there are virtually limitless create-o-logical, electroreasonable ways to write things. It's my hope to ground the discussion with practical, actionable examples which might justly and concisely demonstrate the potential of the decorator pattern.

Given the name, it would be natural to imagine there's something ~fancy~ about decorators. They are not, in fact, frivolous adornments (Though the programmer may find them pretty!).

The truth is they are simply a way of writing functions guided by a specific design pattern.

Thankfully, Python and JavaScript both support higher-order functions, meaning all valid functions qualify as "first-class citizens" which can be passed as function arguments and returned from other functions.

Cool. Why does it matter?

The careful reader may reason that "citizens" isn't an entirely semantic way to think about pseudolinguistic abstractions dependent on electricity ... What is meant can be thought of more simply: first-class citizens are treated like values. They have clearance to go anywhere other values can go.

And for our decorators to work, we need to be able to pass functions as values into the decorating function.

Decorators are not exclusive to any specific language, to be clear. One can write a decorator function in JavaScript or Python or another functional language much the same. As two of the most commonly used modern languages, and two I am at least familiar with, I've chosen JS and Python to demonstrate decorators through code in the examples to come.

Now that we've sufficiently murked the water with our stirring, let's see if we can clear things up.

The decorator pattern can be implemented as follows

The decorator takes a function or functions as it's argument:

# PYTHON
def decorator(func):
    pass

// JAVASCRIPT
function decorator(func) {
    return;
}

It's important to note that a decorator should return a function (or in some cases, a class). Our goal is always to extend, transform, or modify another function's ability, and so we must return a function so that we can use it later as a new and improved "decorated" version.

So we'll setup another function inside the decorator's body and return it:

def decorator(func):
    # *args allows for a variable number of arguments
    def modifier(*args):
        return func(*args)
    return modifier

function decorator(func) {
    // rest operator allows for a variable number of arguments
    function modifier(...args) {
        return func(...args);
    }
    return modifier;
}

There's a lot going on here, and some of it involves closure, which is too rich a topic to indulge intermittently. One may content oneself with the idea that closures allow our functions to keep track of internal values. They are packaged up for future use and modification!

Our function is now available to the innermost scope so that it can be augmented, modified, or enhanced by the decorator. Nonetheless, our decorator remains useless. We need a problem to solve.

Pretend Problem

We need to optimize some functions that perform computationally intensive work.
Each function is pure, meaning that, given the same inputs, the function will always produce the same output.
It is likely that the function will frequently be called with inputs identical to previous calls.

Given these understandings, memoization will be our chosen strategy. And the decorator pattern turns out to be an elegant choice for implementing it!

In order to properly demonstrate memoization, we need a function that emulates an "expensive operation":

"""
Adds x to itself x times
"""
def cpu_spinner(x):
    values = [x for _ in range(x)]
    return sum(values)

/**
Adds x to itself x times
*/
function cpuSpinner(x) {
    return Array.from({ length: x }, (_) => x)
        .reduce((sum, val) => (sum += val), 0);
}

Note: One may note that, compared to the javascript implementation, the python code appears overwhelmingly simple. This may be related to the fact that, being a data science-centric language, Python is in some ways more optimized for math.

Sooo, we have a couple of ~highly sophisticated~ and super expensive operations. Now we need to modify our decorator implementations for memoization, allowing the functions to "remember" previous inputs and their respective results. In both implementations, our cache is a simple hash table that stores the input function's arguments as a key, and the result of the function call as the value for that key:

def memoize(func):
    # Initialize structure to hold previous results
    cache = {}

    def wrapper(*args):

        """
        If we've passed these args before, 
        return early with the stored result
        """
        if args in cache:
            return cache[args]
        """
        Otherwise, execute function and store in cache as
        [args]: result
        """
        result = func(*args)
        cache[args] = result
        return result

    return wrapper

The JavaScript version's logic is essentially identical, but because we can't store complex objects as keys, we need to stringify the key (or use a JS Map that can:

function memoize (func) {
  const cache = {}

  function wrapper (...args) {
    const key = args.toString()
    // return early with result if it's stored
    if (key in cache) return cache[key]
    // otherwise store in cache
    const result = func(...args)
    cache[key] = result
    return result
  }
  return wrapper
}

Note that these solutions follow the same decorator template we set up previously, albeit with some simple logic in between. The key here is that the decorator allows the inner function to keep track of a stateful value. The inner function captures a reference to it's outer, lexical scope, which in this case includes our mutable cache. This capturing behavior is what is known as closure, and it makes possible class-less statefulness and other functional strategies.

NICE

Typically, functions don't need to concern themselves with the context of previous calls. But in the event that the programmer requires persistence across subsequent calls, as in the case of our memoization strategy, a thorough understanding of closures may prove something of a weapon.

It's finally time to ~decorate~ our wildly expensive functions. since 2004, Python has included support for a dedicated decorator syntax. While JavaScript has not, the underlying principle and application is much the same. For python, it's a simple matter of annotating the expensive function with @name_of_decorator_func:

@memoize
def cpu_spinner(x):
    """
    Adds x to itself x times
    """
    return sum([x for _ in range(x)])

For JS, we can accomplish the same thing by simply passing the function we wish to memoize as an argument to the decorator, returning a decorated version of the function to be called later:

const memoizedCpuSpinner = memoize(cpuSpinner);

Now, let's make this ~groovy~ experiment even more fun by including yet another decorator function that follows the very same decorator pattern. Don't worry, this one's even simpler than our memo implementation. But instead of memoizing, this final decorator will time the execution of our memoized functions, so we can explicitly see just how effective memoization can be.

For python, we'll have to import the time module:

import time

def timer(func):
    """
    Immediately before and after the function call,
    we capture the time and print the difference as `elapsed`
    """
    def wrapper(*args):
        start_time = time.process_time()
        result = func(*args)
        elapsed = time.process_time() - start_time
        print(f"Elapsed: {elapsed:.3f} ")
        return result

    return wrapper

Before any pitchforks crest my horizon, I should make very clear that the results of my tests are highly subjective and dependent on a wide range of extraneous factors. But I believe the results, regardless of their inherent imprecision, should sufficiently illustrate the potential power of memoization.

JavaScript's console object should serve just fine for this simple example:

function timer (func) {
  function wrapper (...args) {
    console.time('JavaScript')
    const result = func(...args)
    console.timeEnd('JavaScript')
    return result
  }
  return wrapper
}

Execution

Let's tie everything together with a final record of our work, along with several function calls to our decorated functions, fully timer-wrapped and memoized. We'll also include some print statements necessary for digesting our results.

# *PYTHON
def memoize(func):
    cache = {}
    # Let's add a second stateful value that will track execution count
    count = 0

    def wrapper(*args):
        nonlocal count
        count += 1
        print(f"Execution count: {count}")
        if args in cache:
            print(f"Cached result for {args}: {cache[args]}")
            return cache[args]
        result = func(*args)
        print(f"Uncached result for {args}: {result}")        
        cache[args] = result
        return result

    return wrapper


def timer(func):
    def wrapper(*args):
        start_time = time.process_time()
        result = func(*args)
        elapsed = time.process_time() - start_time

        print(f"Elapsed: {elapsed:.3f} ")
        return result

    return wrapper


# Syntax sugar for passing the annotated function as an argument
@timer
@memoize
def cpu_spinner(x):
    return sum([x for _ in range(x)])


expensive_input = 100_000_000

cpu_spinner(expensive_input)
cpu_spinner(expensive_input)
cpu_spinner(expensive_input)

/* JAVASCRIPT */

// This time, for fun, we'll implement a function expression
const cpuSpinner = (x) => 
  Array.from({ length: x}, _ => x).reduce((sum, val) => (sum += val), 0)


function memoize (func) {
  const cache = {}
  let count = 0

  function wrapper (...args) {
    count += 1
    console.log(`Execution count: ${count}`)
    const key = args.toString()
    // return early with result if it's stored
    if (key in cache) {
      const result = cache[key]
      console.log(`Cached results for argument ${key}: ${result}`)
      return result
    }

    const result = func(...args)
    console.log(`Uncached result: ${result}`)
    cache[key] = result
    return result
  }

  return wrapper
}


function timer (func) {
  function wrapper (...args) {
    console.time('Elapsed')
    const result = func(...args)
    console.timeEnd('Elapsed')
    console.log('\n')
    return result
  }
  return wrapper
}

const timedMemo = timer(memoize(cpuSpinner))

const expensiveInput = 100_000_000
timedMemo(expensiveInput)
timedMemo(expensiveInput)
timedMemo(expensiveInput)

Results && Conclusion

The point with our chosen experiment is not the speed of the language itself, nor how the performance of each language compares against the other (neither is designed for speed in general). The key takeaway concerning memoization is the proof that each subsequent call to the function using the same argument produces its result almost instantaneously.
The reasons why the Python code outperforms the JS and the reason why the JS still takes a fraction of a second to retrieve a memo-ized value are questions explored in the PostNotes.

Python

Call #1
Uncached result: 1e+16
Execution timer: 4,469ms

Call #2
Cached result for argument 1e+8: 1e+16
Execution timer: 000ms

Call #3
Cached result: 1e+16
Execution timer: 000ms

JS

Call #1
Uncached result: 1e+16
Execution timer: 9,347ms

Call #2
Cached result for argument 1e+8: 1e+16
Execution timer: 306ms

Call #3
Cached result: 1e+16
Execution timer: 442ms

All of the redundancies here are meant to drive home the point that memoization is only effective when a function receives input identical to a previous call and that function is entirely free from side effects. Otherwise, we can't count on the result being the same as the previous call based solely on the input.

We can see that the first function call takes a notable amount of time to finish executing: 4,469ms and 9,347ms for Python and JS respectively. We can see given the timing of subsequent calls with the same input argument that the result is produced nearly instantaneously by comparison.

It is my hope that, by this point, it is clear why these results can be expected. If a function is truly pure, we can count on our identical arguments to produce identical results. So we use closure to keep a record of previous args and their paired output using a hash table which we've called cache. Every time the function is called, our memoization decorator checks the hash table to see if the result is already recorded. If so, the entire operation amounts to a quick lookup in the hash table to retrieve the expected value.

Bye For Now

For quick reference, a few concepts we explored throughout this experiment:

Thanks so much for reading!

Stay tuned in to the following section for some random tidbits that didn't make the cut.

As always,
Keep growing!

PostNotes

Fun Fact:

I accidentally produced a fatal heap overflow error in Node.js when I attempted to increase the input by 5x. I suspect this is related to poor handling of memory by filling an array without a dedicated range operator like the one we used in the Python implementation. If you know of a more efficient way to populate a JavaScript array for experiments of this kind, please let me know!

And for fun, here's a screen snip of the abbreviated error:

Cool Function, dude

Here's a JavaScript version of the memoize decorator that aims to be as concise as possible by leaning all the way into the functional style. Though not necessarily practical or easy to read, it was groovy and fun to devise:

Anonymize the second function and return it implicitly.

Pass the cache silently as a default argument, eliminating the need to declare it inside the function body that we no longer have, but still exposing it to the inner function's lexical scope as is necessary for closure.

Celebrate victory.

const functionalMemoize =
  (func, cache = {}) =>
  (...args) => {
    const key = args.toString()
    if (key in cache) return cache[key]
    const result = func(...args)
    cache[key] = result
    return result
  }

Sneaky Snake

The Python implementation of the "expensive function" which I chose somewhat at random came out short, sweet, incredibly readable and relatively fast. The near-zero execution time seen in the memoized Python results makes sense considering the simplicity of a hash table lookup. So why the costly calls in the JavaScript version?
Short answer, I don't actually know. 🙃
But when I removed all console logs from the implementation, the results came much nearer to zero. This suggests that writing to stdio is more expensive in JS than in Python, but this mystery may go the way of the tootsie pop.

For now ...

How to be a Programmer

Joshua Newell Diehl — Tue, 03 Jan 2023 00:17:20 +0000

Turn off the fourth alarm and turn on the tower,

then start the magic beans a-brewing.

Prime your tired head with a pep talk while brushing those teeth;

you're gonna need it.

Restore all recently closed tabs and be grateful

for a remembering machine, reliable and efficient.

Imagine streams of lightning on copper highways.

Impossible speed.

Marvel for a moment.

Don't dwell on how much you love programming.

Love doesn't pay.

Force yourself to work on that one project

that might hopefully impress some critical someones

you haven't even met yet.

The tasklist is long and it's time to dive in.

Start with what time forgot yesterday.

Find a rhythm, stretch your fingers.

Hot water helps when the blood is fighting cold.

You're stuck before you've started.

Reach out to the documentation and I'm sorry

it's so terrible.

Remember how difficult it is to write great docs and
get over it.

You're immediately reminded of how little you know

because this popular library has twelve paragraphs

describing installation.

Spend thirty minutes scanning pages and likely not find

what you came here for.

You're frustrated now so

have some breakfast.

Eat anything that resolves to brain sugar.

Finally some progress but you can no longer ignore

those aching muscles.

Sit on the floor and stretch it out while

the dog licks your face.

Visit stack overflow with a pressing question but

quickly discover that 42 other people have asked the same.

Lose another opportunity to boost site reputation.

Remain a noob.

At least you found the answer.

You've finally found your flow so

interrupt it to retrieve more coffee.

Run back to the throne excited because you suddenly came up with a beautiful solution to that one thing.

It doesn't work.

Spill hot coffee on your pants.

Restart the dev server and rejoice;

only one hour wasted.

Celebrate by finally getting some work done.

Explore alternative libraries because this one

doesn't support that 15-line dependency

of a dependency

of a dependency of

that one exclusive library with 600

severe vulnerabilities.

You're seeing red with dry eyes so

decide to rewrite the whole project in python.

Write a 300-line module in hour 9

that runs beautifully on the first try

and remember why

it's all worth it.

Return to line 1.

Tiers of Tamperability

Joshua Newell Diehl — Sat, 17 Dec 2022 13:43:00 +0000

I get my socks rocked by the clear semantics of methods like freeze and seal.

One can freeze an object, encasing the object inside an icy, impenetrable shell, or seal an object, as if casting a partial blessing or sealing the matter shut.

These kinds of metaphors may characterize the ways in which the programmer comes to think about the use of their tools and learns to mnemonically reference them for increased retention.

Freeze & Seal

Object.freeze and Object.seal, together with let and const, define the "hierarchy of tamperability", which determines how much an object can be tampered with.

Okay ... I made all that up ... I just mean to suggest that thinking of JavaScript objects in terms of their "tamperability tiers" can be a meaningful framing. (But I won't be offended if you prefer to call it immutability like everyone else)

Tier 1 - `let`

Tier 2 - const

Tier 3 - seal

Tier 4 - freeze

Tier 5

UNKNOWN

An iceberg on the tip of my tongue

I hope you're getting excited, cause we're about to build a logical metaphor with high-level, pseudo-natural machine speak!!! (Di-hydrogen monoxide, amirite?)

// Absurdly complex mock object that we're definitely gonna 
accidentally try to modify the deeply nested properties of

const iceberg = {
  above: {
    name: "marylee",
  },
  surface: {
    name: "alabaster",
    submerged: [
      { visions: ["joy", "grief"] },
      {
        regrets: null,
        fightLeft: 100,
        fears: {
          one: "failure",
          two: "deep, cold water",
        },
      },
    ],
  },
};

// Super chill function that prevents the silly oopsies we make
   swimming too deep

const deepFreeze = (nestedObject) => {
  const propNames = Object.getOwnPropertyNames(nestedObject);
  // Traverse
  for (const name of propNames) {
    const value = nestedObject[name];
    // Check for reference-type value
    if (value && typeof value === "object") {
      // Recurse
      deepFreeze(value);
    }
  }
  // Freeze each of type "object"
  return Object.freeze(nestedObject);
}

const absoluteZero = deepFreeze(iceberg);

So,

We have this big messy ice rock.

We pass it as input to our deepFreeze function, and

we capture the prop names at the current depth as an array.

Then, we loop over each property and check its value.

If the value is an object, we make a recursive call on the nested value.

By the end of our for...of loop, the entire depth of the parent object has been visited.

Objects are frozen as the function calls are popped from the stack, beginning with the last field evaluated.

You've unlocked Tier 5:

the ~DEEP FREEZE~

Tamperability:

ABSOLUTE ZERO

It's worth mentioning that JavaScript is also equipped with the methods required to evaluate these states, and the language offers even more tamper control than was mentioned here by way of Object.preventExtensions. JavaScript provides the programmer with fine-grained access to an object's mutability settings.

This flexibility is one of the many reasons I love JavaScript. We have the freedom to sovereignly decide how much to allow our objects to change. However, as a functional fanatic, Object.freeze is the only one of these available methods that I occasionally call on. As per recommendations put forth by the functional approach, it's best to eliminate mutability altogether.

In Conclusion,

Consider that:

Java is the dad who never lets you try anything exciting cause it's not safe.
JavaScript is the dad who lets you choose so you can learn from your mistakes.

There are of course excellent and meaningful reasons for building stricter rules into a language, not least of all to avoid pernicious bugs. The reliability of languages that enforce these rules is clear and palpable.

But that doesn't make working with them any more fun.

!!!
If you have your own examples of languages or features that offer mutability control, please share them with us in the comments below!

Forem: Joshua Newell Diehl

JavaScript - Writing Functional Flows with Custom Pipes

The star player

Reusability

Testability

Ease of debugging

Avoid the pitfalls of inheritance

Full Code on Repl

Side by Side Series: Rust & Go - The Builder

The Pattern

The Implementation

PSEUDOCODE

Rust

Go

PSEUDOCODE

Rust

Go

PSEUDOCODE

Rust

Go

Rust Final

Go Final

The Insights

Conclusion

Essential React Hooks

HOOKS

Starting off simple,

useNewTab

I recently encountered a situation where

useViewportQuery

The browser is full of delicious APIs

useClipboard

When I first discovered the Intersection Observer,

useIntersectionObserver

I believe that user interaction is the key feature

useCursorPosition

Conclusion

Fancy Fun w/ Functional Decorators

The decorator pattern can be implemented as follows

Pretend Problem

Execution

Results && Conclusion

Python

JS

Bye For Now

PostNotes

Fun Fact:

Cool Function, dude

Sneaky Snake

How to be a Programmer

Turn off the fourth alarm and turn on the tower,

Restore all recently closed tabs and be grateful

Don't dwell on how much you love programming.

The tasklist is long and it's time to dive in.

You're stuck before you've started.

You're immediately reminded of how little you know

You're frustrated now so

Finally some progress but you can no longer ignore

Visit stack overflow with a pressing question but

You've finally found your flow so

Restart the dev server and rejoice;

Explore alternative libraries because this one

You're seeing red with dry eyes so

Tiers of Tamperability

Freeze & Seal

Tier 1 - let

Tier 2 - const

Tier 3 - seal

Tier 4 - freeze

Tier 5

An iceberg on the tip of my tongue

So,

You've unlocked Tier 5:

Tamperability:

ABSOLUTE ZERO

In Conclusion,

Tier 1 - `let`

Tier 2 - `const`

Tier 3 - `seal`

Tier 4 - `freeze`