StackAnatomy - Medium

Forever Functional #39 — Workers and Promises

Federico Kereki — Sun, 01 Sep 2024 12:43:28 GMT

Forever Functional #39 — Workers and Promises

JavaScript provides concurrency when using async functions; even if a single processor does all the work, several tasks may be ongoing simultaneously. To get better performance, you may use web workers (at the front end, in a browser) and worker threads (at the back end). This article will show you how to work with workers in a functional, efficient way.

The basic mechanism for using workers is messaging, but that has some limitations-plus, it really isn’t very functional!- so let’s see how we may use workers in a functional way to optimize the performance of our code.

A sample worker

In a previous article, we saw that a naïve straightforward implementation of the Fibonacci numbers could have serious time performance issues. Let’s use that as a worker, so we’ll have something to do that might take a long time, depending on whatever argument we pass to it.

// File: ./workers/sample_fib_worker.mjs

import { parentPort } from 'worker_threads';

const fibonacci = (i) => (i < 2 ? i : fibonacci(i - 1) + fibonacci(i - 2));

function fakeWorker(n) {
  const result = fibonacci(n);
  parentPort.postMessage(`fib(${n})=${result}`);
}

parentPort.on('message', fakeWorker);

The parentPort attribute is how the worker communicates with the parent. Then, we have the definition of the i-th Fibonacci number and how we'll use it. Finally, the last line defines, by using the onmessage method, what the worker should do with the argument it receives. The received value will be passed to the fakeWorker function, which will use the postMessage method to return the calculation's result; in this case, something like fib(7)=13.

Using workers through messages

Suppose we wanted to perform the Fibonacci calculations in a thread to avoid blocking Node’s event loop (at the back end) or seemingly showing a dead, non-responding screen (at the front end). The simplest way of doing this is as follows; we’ll use Node.js for simplicity, but code would be similar at a browser.

import { Worker } from 'worker_threads';
const worker = new Worker('./workers/sample_fib_worker.mjs');

worker.postMessage(40);
worker.postMessage(35);
worker.postMessage(45);
worker.postMessage(15);

worker.on('message', console.log);

process.stdin.resume();       // keep Node running
process.on('SIGINT', () => {  // on Control+C, end
  worker.terminate();
  process.exit();
});

First, we create a worker based on the code we saw in the previous section. We send several messages (using the postMessage method), and the four requests will be queued and processed in the order they are received. The last lines are just to keep Node running (otherwise, the program would end before the worker had a chance to do its job) and to clean up (by terminating the worker) on Control+C.

The output is the following.

fib(40)=102334155
fib(35)=9227465
fib(45)=1134903170
fib(15)=610

This works well, but if you wanted to call the same worker several times in parallel, that would require creating separate workers and handling messages in different ways. (As is, the four calls in our example are processed serially.) Also, message passing doesn’t look very functional, so let’s try using promises.

Using workers through promises

We can create a promise out of a worker and have it resolved when the worker sends its result.

import { Worker } from 'worker_threads';

const callWorker = (filename, value) =>
  new Promise((resolve, reject) => {
    const worker = new Worker(filename);
    worker.on('message', (value) => {
      resolve(value);
      worker.terminate();
    });
    worker.on('error', (err) => {
      reject(err);
      worker.terminate();
    });
    worker.postMessage(value);
  });

The callWorker function builds a promise, given the worker to create and the value to pass to it. If the worker succeeds, the resolve function is used to fulfill the promise; on an error, reject is called instead. In both cases, we terminate the worker because it's done.

Now, we can run several workers in parallel.

callWorker('./workers/sample_fib_worker.mjs', 40).then(console.log);
callWorker('./workers/sample_fib_worker.mjs', 35).then(console.log);
callWorker('./workers/sample_fib_worker.mjs', 45).then(console.log);
callWorker('./workers/sample_fib_worker.mjs', 15).then(console.log);

We are creating four promises that will run in parallel. We are just logging their results here, but we could obviously do other things. The output will be in different order because the four calls do not take the same time to complete.

fib(15)=610
fib(35)=9227465
fib(40)=102334155
fib(45)=1134903170

This is very good and enables us to parcel out work to threads and work in parallel as well. However, there’s an issue; every time you use callWorker, a new worker has to be created (so code must be read and parsed again), which will cause delays. What can we do?

Using workers with a pool

As we saw earlier, workers can stay unterminated, and as they receive new messages, they can reply to them. This suggests a solution: keep the workers in a pool, do not terminate them, and reuse them if possible. When we want to call a worker, we first check the pool to see if there’s already an appropriate available (meaning, not in use) worker. If we find it, we can directly call it, but if not, we create a new one.

The pool entries will have three attributes:

worker, the worker itself
filename, which was used to create the worker
available, which is set to false when the worker is running, and to true when it's done and ready to do a new calculation

The callWorker method now becomes:

// file: ./workers/pool.mjs

import { Worker } from 'worker_threads';

const pool = [];

export const callWorker = (filename, value) => {
  let available = pool
    .filter((v) => !v.inUse)
    .find((x) => x.filename === filename);
    
  if (available === undefined) {
    available = {
      worker: new Worker(filename),
      filename,
      inUse: true
    };
    pool.push(available);
  }

  return new Promise((resolve, reject) => {
    available.inUse = true;
    available.worker.on('message', (x) => {
      resolve(x);
      available.inUse = false;
    });
    available.worker.on('error', (x) => {
      reject(x);
      available.inUse = false;
    });
    available.worker.postMessage(value);
  });
};

The callWorker code has two parts. Initially, it searches the pool for an available worker ( inUse should be false) with the correct filename. If the search fails, a new worker is added to the pool. After that, the logic is similar to what we saw in the previous section; the main difference is that we must update the inUse attribute appropriately.

Using this pool works the same way as earlier, but the difference is that it won’t create unnecessary workers if it can reuse previous ones. We still use promises and have parallel processing, but we now add a bit more efficiency; a win!

Conclusion

Using workers provides several benefits, like processing in different threads, which isn’t as common in JavaScript as in other languages such as Java or Rust. Using workers through promises enables a more functional working style, and the final addition of a pool gives extra performance; several wins for us!

If you want to read about programming (including functional programming, of course), algorithms in general, and data structures and their applications, take a look at my DATA STRUCTURES AND ALGORITHMS IN JAVASCRIPT and MASTERING JAVASCRIPT FUNCTIONAL PROGRAMMING books.

Originally published at https://blog.openreplay.com.

Forever Functional #39 — Workers and Promises was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #38 — Of maps and pipes, chains and nests, and more

Federico Kereki — Sun, 01 Sep 2024 12:43:25 GMT

Forever Functional #38 — Of maps and pipes, chains and nests, and more

Can we combine functions by using mapping? What about this in relation to function composition and pipelining? And what does it have to do with chaining and nesting? This article will reply to all those questions, showing you how to join functions together for clearer, more expressive code.

The array .map(...) method is very powerful and lets us write more understandable code. Let's ask a theoretical question and see where it takes us. Could we apply map() to other types and not only to arrays? Why not?

In this article we’ll start by extending types to allow mapping, and then get into pipelines, chaining, nesting, and several other functional programming concepts; just wait!

Mapping for other types

First, we could add it to basic types, such as booleans, numbers, bigInts, and strings. On the other hand, it seems that adding mapping to null, undefined, and symbol wouldn't be that great, so we'd skip that. And, obviously, adding a map() method to objects (or to class definitions) is straightforward; no mystery there.

In all cases code would be something like this — we’ll only show two definitions to avoid repetition:

Boolean.prototype.map = 
  function(fn) { 
    return Boolean(fn(this));
  };

Number.prototype.map = 
  function(fn) {
    return Number(fn(this));
  };

We can now write things like the following two examples, and let’s use pointfree style for a more “functional-programming-ish” style:

const not = (x) => -x;
let someFlag = true;
someFlag.map(not); // false

const negate = (z) => -z;
let aNumber = 22;
aNumber.map(negate); // -22

This isn’t a real win; we could have written not(someFlag) and negate(aNumber) equally well. There's a slim advantage: we can now clearly chain sequences of operations. Let's go with a simple example.

const add1 = z => z+1;
const times10 = z => 10 * z;

aNumber.map(add1).map(times10).map(negate); // -230

This starts to look more interesting; the alternative way, negate(times10(add1(aNumber))) wouldn't have been equally clear. We'll look into this a bit more, but first, we must answer the question: what about using map() with functions?

Mapping functions

Functions are (trivially!) essential, and we should investigate what mapping would mean for them. The logical definition would be as follows; if we have f1 and f2 functions and we write f1.map(f2), that should return a function that first runs f1 and then applies f2 to whatever f1 returned.

Function.prototype.map = function (fn) {
  return (x) => fn(this(x));
};

add1.map(times10)(3); // 40

So, x => f1.map(f2)(x) is equivalent to x => f2(f1(x)), and in general x => f1.map(f2).map(f3)...map(fn)(x) would be the same as x => fn(...f3(f2(f1(x)))). This is a well-known functional programming concept that we should look into!

Maps as composition?

The kind of expression we wrote in the previous paragraph, when you have a sequence of functions call in which the output of one function is the input of the next one, is called composition. Formally, in mathematical terms, instead of fn(...f3(f2(f1(x)))) you could also write (fn∘...∘f3∘f2∘f1)(x). If you wish, you can read ∘ as after, so f2∘f1 is f2 after f1, etc.

If we wish, we can write a general compose(...) function; it's not hard - can you see why and how the code below works?

function compose(...fns) {
  return fns.reduceRight(
    (f, g) =>
      (...args) =>
        g(f(...args)),
  );
}

So, instead of writing x => f1.map(f2).map(f3)(x) you could go with x => compose(f3, f2, f1)(x) - but that goes a bit against the grain; the order of functions is reversed! There's another concept we should look into: pipelining!

Maps as pipes

In Unix and Linux, the idea of running a first command, passing its output as input to a second command, whose output will be input for yet a third command, etc., is called a pipeline. This is a basic philosophy of Unix, and Doug McIlroy, the creator of the pipelining concept, explained:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
Expect the output of every program to become the input to another, so far unknown program.

To give an elementary example (from my Mastering JavaScript Functional Programming book) if you wanted to count how many LibreOffice text documents there are in a directory, the following pipeline would do:

ls -1 | grep "odt$" | wc -l

How does this work?

The first command lists all the files in a single column, one filename per line.
The second command gets the list of files and filters (let pass) only those that end with “odt”, the standard file extension for LibreOffice Writer documents.
The third command gets the filtered list and counts how many lines there are in it.

Given that pipelining is just like composition but working “the other way”, we can quickly whip up the following:

function pipeline(...fns) {
  return fns.reduce(
    (result, f) =>
      (...args) =>
        f(result(...args)),
  );
}

In that case, we could write any of the following versions — though the last two won’t work until the pipeline operator proposal is accepted:

aNumber.map(add1).map(times10).map(negate);
aNumber.map(add1.map(times10).map(negate));

pipeline(add1, times10, negate)(aNumber);
aNumber.map(pipeline(add1, times10, negate));

(add1 |> times10 |> negate)(aNumber); 
aNumber.map(add1 |> times10 |> negate);

What do you think? Personally, I believe that this “ chaining style” for successive functions is clearer than the alternative “ nesting style” (based on composing) which adds the extra complexity of listing the functions in reverse order. The piping way, the fluent interface pattern, is more understandable, and adding our map/pipe method allows us to easily use it.

Conclusion

We started this article by wondering about extending the usage of map() to other data types, went from there to using it on functions, and ended up considering typical functional programming topics such as composition and pipelining. JavaScript can be considered a multi-paradigm language, and the examples we've seen here confirm that... and also allow you greater freedom to achieve the maximum clarity in your code!

Originally published at https://blog.openreplay.com.

Forever Functional #38 — Of maps and pipes, chains and nests, and more was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #40 — Better Error Handling with Monads (Part 1)

Federico Kereki — Sun, 01 Sep 2024 12:42:27 GMT

Forever Functional #40 — Better Error Handling with Monads (Part 1)

What are monads? How do you create them in JavaScript, and how do you use them? What problems do they solve? Why should one care about monads and add them as a tool for development? This article will start with basic requirements to show what monads are and how to create them, and in the second part we’ll see how and when to use them, simplifying error handling everywhere.

Using the .map() method allows for shorter, clearer, declarative-style programming, so we would want to be able to use it more. In a previous article, we saw that we could extend individual types to allow adding this method to them. However, that is sort of limited and requires repeating the definition for each type. So, we'll work in a different, more general way and eventually get to monads, which are way more powerful than just "types with maps"!

We’ll start by defining containers, which work with any type
We’ll then add some features and get more power with functors
We’ll finish by adding some more capabilities and producing monads

We could do this using classes, but we’ll go with vanilla JavaScript, which is as basic and compatible as possible. We’ll be using object constructors instead of classes, and closures instead of attributes, as you’ll see.

The curse of the monad is that once you get the epiphany, once you understand-”oh that’s what it is”-you lose the ability to explain it to anybody. Douglas Crockford

First Step: Defining Containers for all data types

We want something that will contain a value of any type and (at the very least) allow us to apply a .map() method to it. The following code does just that:

function Container(x) {
  this.map = (fn) => fn(x);     // ➊
  this.toString =               // ➋
    () => `${this.constructor.name}(${x})`; 
  this.valueOf = () => x;       // ➌
}

Let’s study the code. The method we care about is .map(); given a fn function, it applies it to the container's value x ➊.

Note: The x value is not stored as an attribute but rather accessed through a closure, making the value inaccessible from the outside.

We added a couple more methods. The standard .toString() method is overridden to get a more accurate description of the container and its value ➋. Finally ➌, the .valueOf() method is just a help for debugging, because you could easily write someContainer.map(console.log) and see the container's value.

How do we use these containers? We can create a container with a value of any type; an example follows.

const plus1 = (x) => x+1;      // ➊
const ccc = new Container(22); // ➋
ccc.map(plus1);                // ➌ 23
ccc.valueOf();                 // ➍ 22
ccc.toString();                // ➎ Container(22)

First ➊ we define an auxiliary plus1() function that we'll use in our tests. Then ➋ we create a container for a numeric value, 22. The following line (written in pointfree style) shows how to use .map() ➌ with the same notation used for arrays. Finally, the last lines ➍ ➎ illustrate our additional methods; we see that the original ccc container wasn't modified and still has the 22 value inside.

OK, these containers work, but they are roughly equivalent to variables. We wanted to be able to use .map(), and we managed that, but we cannot chain operations as we did in our previous article on fluent interfaces, so we must work a bit more, and go from containers to functors.

Second Step: Adding more power by using Functors

Containers are good, but we need .map() to return a container so we can chain more operations. By changing the definition of the operation, we have moved to a new kind of object, a functor.

Essentially, a functor is just a container (as we’ve created it), but we need its .map() operation to return a new functor, not just a value. This is precisely what happens with arrays: when you use .map(), you produce a new array, so now we realize that arrays are functors! The needed change is small.

function Functor(x) {
  Container.call(this, x);             // ➊
  this.map = (fn) => 
    new this.constructor(fn(x));       // ➋
}

We start ➊ by invoking the Container constructor, so our functors will share their three methods. The following line ➋ overrides the inherited .map() method with a new implementation that returns a new functor, allowing us to chain operations as in the example below.

const plus1 = (x) => x+1;
const ccc = new Functor(22);           // ➊
const ddd = ccc.map(plus1).map(plus1); // ➋
ddd.map(plus1).valueOf();              // ➌ 25
ddd.toString();                        // ➍ Functor(24);

This example is like the one for containers, but instead of creating a container ➊ we built a functor. This allows us ➋ ➌ to chain several operations. The last line ➍ shows that ddd is a functor containing 24.

These functors are better suited for coding than our plain containers, but there still are a couple of kinks we must work out; let’s go on to monads!

Third (and last) Step: Get maximum flexibility by using Monads

There’s a problem we still need to consider… Let’s assume a fun functor and a makeFun(...) function that returns a functor. What would fun.map(makeFun) produce? The answer: we'd get a functor whose value would be a second functor! This would make coding very difficult; to apply a function to the value in the second functor you would have to write code such as fun.map(makeFun).map((x) => x.map((y) => someOtherFunction(y))); neither practical nor clear!

We will extend functors to create a new type, monads. We want monads to be able to “unwrap” the value a function returns (if needed) so we won’t get values wrapped two or more times. We will have a new unwrap() (internal) function, and a .chain() method that will use it to unwrap possibly wrapped values.

function Monad(x) {
  Functor.call(this, x);                 // ➊
  const unwrap = (z) => z.chain ? 
    unwrap(z.valueOf()) : z;             // ➋
  this.chain = (fn) => 
    new this.constructor(unwrap(fn(x))); // ➌
}

Monads are functors, so we start ➊ by calling the corresponding constructor. Our unwrap() function ➋ detects if its argument is a monad by seeing if it has a .chain() method; other ways of doing this detection could be used. The .chain() method ➌ is precisely like .map(), but it takes care of unwrapping whatever is returned by fn(x), so the resulting monad won't be wrapping anything more than once.

Working with monads is, so far, exactly the same as with functors. The only difference is that you would probably prefer using .chain() to avoid double wrapping for values, but in most cases, .map() will do.

Functions in monads

So far, we have been storing “common” values in monads, like numbers. But, as with variables, we could think of storing a function in a monad, like in the example below. Would that work? Of course, it should, but how would we use the contained function?

const nnn = new Monad(22);      // ➊
const add = (x) => (y) => x+y;  // ➋
const fun = nnn.map(add);       // ➌

We first create a monad ➊ containing a number. The add() function, written in curried style as usual in functional programming. When we apply add() to the monad ➌ we get a new monad whose value is a function that will add 22 to whatever it's applied to. But how will we be able to do that? We could write something awkward like the following, using two .map() operations, but that's not clear or practical!

const ooo = new Monad(9);
const ppp = ooo.map((x) => fun.map((f) => f(x)));

Instead of that roundabout way of working, we’ll define a new .ap() method that will allow us to apply a function in a monad to any value that allows mapping.

function Monad(x) { 
  // ...all the previous code, plus:
  this.ap = (v) => v.map(x); // ➊
}

fun.ap(ooo);                 // ➋ Monad(31)

We need just one line ➊ to define the new .ap() method, which will apply the contained function to a given value v by mapping. We can see this working ➋ more clearly; we can now apply the function in the fun monad to another monad ( ooo) without complications.

Note: you could want to write something like fun.ap(9), but that wouldn't work because plain numbers don't provide a .map() method. Can you fix this so .ap() will also work with numbers, strings, booleans, etc.? We'll leave this up to you as an exercise!

Conclusion

We have now reached our first goal; we implemented monads! We started with basic containers, made a small change to get functors, and added more power to get monads. We did all of this using vanilla JS, starting from basic requirements.

However, just showing how monads are defined is interesting, but the real deal is seeing why and how they simplify coding, dealing with errors, working with missing values, and more — we’ll get to that in part 2 of this article; stay tuned!

Originally published at https://blog.openreplay.com.

Forever Functional #40 — Better Error Handling with Monads (Part 1) was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #41 — Better Error Handling with Monads (Part 2)

Federico Kereki — Sun, 01 Sep 2024 12:42:22 GMT

Forever Functional #41 — Better Error Handling with Monads (Part 2)

The first part of this article explained monads and wrote vanilla JS code for them. Now, this second part answers the big question: What are monads good for, and why should you use them?

Monads have several uses, so let’s start by showing how to deal with “the billion dollar mistake”, mishandling null values, in a very simple way.

Null values: “The Billion Dollar Mistake”

Anthony Hoare, the inventor of Quicksort, spoke a few years ago about his “invention” of null references:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Given the unending list of bugs that have occurred because of null pointers, missing values, undefined results, and the like, it seems that any solution that helps deal more carefully with this kind of situation would be welcome! It happens that monads do allow such a workaround; let’s introduce the Maybe monad and see how the problem practically goes away with very simple code… even if the following definition (which we won't use) is totally obscure!

All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor. Saunders Mac Lane

Dealing with missing values: the MAYBE monad

Let’s see our first example. Assume we have a value that may or may not be present. A Maybe can be two different monads:

A Just ("just a value") when the value is present
A Nothing when the value is absent (so it is null or undefined)

Let’s first see Maybe, which actually is a factory that will produce either Just or Nothing monads.

function Maybe(x) {
  isEmpty(x)                  // ➊
    ? Nothing.call(this)      // ➋
    : Just.call(this, x);     // ➌
}

The isEmpty() function ➊ checks if the passed value is null or undefined; I’ll leave it up to you to code it. When we create a Maybe, depending on the value we pass to it, a Nothing ➋ or a Just ➌ will be created.

Let’s see the other two monads we need, starting with Just.

function Just(x) {
  Monad.call(this, x);            // ➊
  this.isNothing = () => false;   // ➋
  this.map = (fn) =>              // ➌
    new Maybe(fn(x));
  this.chain = (fn) =>            // ➍
    new Maybe(unwrap(fn(x)));
}

Since Just extends Monad, we start ➊ by calling the required constructor. We are adding an isNothing() method ➋, so given a Maybe, we can test if it is a Nothing or not; for a Just, isNothing() returns false. The map() ➌ and chain() ➍ methods are similar to what we saw earlier; the difference is that after mapping or chaining, a Maybe is returned instead of a generic Monad.

We can now look at the Nothing monad.

function Nothing() {
  Monad.call(this);
  this.isNothing = () => true;         // ➊
  this.map = this.chain = () => this;  // ➋
  this.toString= ()=> "Nothing()";     // ➌
}

Let’s just highlight the differences with Just. The .isNothing() function here returns true. The .map() and .chain() methods ➋ do nothing at all; they just return the monad itself, ignoring whatever arguments you pass to them. Finally ➌ we must fix the .toString() method because Nothing monads contain no values.

How would you use a Maybe? The idea is that you get a value, construct a Maybe, and then just chain operations. If the value isn't empty, the operations will be performed, but otherwise, they will be ignored. The following example shows a simple case. Note we are using pointfree notation:

const plus1 = (x) => x + 1;    // ➊
const times2 = (x) => 2 * x;

new Maybe(100)  // ➋
  .map(plus1)   // ➌
  .map(times2)  // ➍
  .toString();  // ➎ Just(202)

new Maybe(null) // ➏
  .map(plus1)
  .map(times2)
  .toString();  // ➐ Nothing()

First ➊ let’s define some simple functions to test our monads. If ➋ you build a Maybe with a nonzero value (100) you can increment it by one ➌ and duplicate the result ➍ and you'll end ➎ with a Just(202) monad. (Note that we could have used .chain() instead of .map() and it would have produced the same result.) On the other hand, if you start with a null ➏ the operations are ignored, and you end ➐ with a Nothing instead. You didn't have to write any if statements anywhere; the Maybe, whether a Just or a Nothing works accordingly.

Note: If you remember it, this is the same we showed when we built our booleans out of functions! In that case, TRUE and FALSE were functions that dealt differently with whatever you passed to them; here, Just and Nothing work in the same way.

Dealing with default values

But let’s add to this! You would want to use a default value instead when dealing with possible missing values. You could use isNothing() and write tests, but that wouldn't use the power of monads! Instead, let's add an orElse() method to specify what value to use when you get a Nothing. (Of course, orElse() won't do anything if you got a Just.)

function Just(x) {
  // ...all previous code, plus:

  this.orElse = () => this;          // ➊
}

function Nothing() {
  // ...all previous code, plus:

  this.orElse = (x) => new Maybe(x); // ➋
}

The new .orElse() method ➊ won't do anything for a' Just' monad. Conversely, for a Nothing monad ➋ .orElse() will produce a new Maybe, most likely not a Nothing. (Why would you pass an empty value to the .orElse() method for a Nothing? That would just produce a new Nothing.)

We can now see examples dealing with missing and default values.

new Maybe(1900) // ➊
  .orElse(50)   // ➋
  .map(plus1)   // ➌
  .toString();  // ➍ Just(1901)

new Maybe(null) // ➎
  .orElse(50)   // ➏
  .map(plus1)
  .toString();  // ➐ Just(51)

new Maybe(null) // ➑
  .map(plus1) 
  .orElse(50)   // ➒
  .toString();  // ➓ Just(50)

In the first example ➊ we start with a Just(1900), so orElse() doesn't do anything ➋ and after incrementing the value by 1 ➌ we end with a Just(1901) ➍. The second case is more interesting; after starting with a Nothing ➎ the orElse() produces a Just(50) ➏ which is then incremented, thus ending ➐ with a Just(51). The third case shows a variation; again, we start with a Nothing, we then use map() (but without any effect), and we apply orElse() ➒ so we finish ➓ with a Just(50); where you place the orElse() makes a difference!

A realistic example

Let’s go with a real-life example. Assume that, given a customer’s id, we want to show what country he lives in. There are some issues, though:

The customer id might be wrong
The customer id could be correct, but he could not have an address field
The customer could have an address, but without a countryCode field
The customer could have a countryCode field, but its value might be wrong

You would usually deal with this by writing many if statements, but the solution is much simpler with Maybe monads. Let's assume that we have:

a getCustomer() function that, given an id, returns a Just with the customer's data (if the customer exists) or a Nothing otherwise
a countryCodeToName() function that, given a country code, returns the country name, or undefined instead
a getField() function that, given an object and a field name, returns that field from the object, or null instead. We can easily code const getF = (field)=> (obj) => obj ? obj[field] : null; for that.

Now, how can we display the customer’s country name or “N/A” instead? A single line does the job — though we will display in several lines for clarity:

getCustomer(22)                 // ➊
  .map(getField("address"))     // ➋
  .map(getField("countryCode")) // ➌
  .map(countryCodeToName)       // ➍
  .orElse("N/A")                // ➎
  .map(console.log);            // ➏

Now that we’ve seen a complete example with Maybe monads, let's consider some extra monads for other cases.

Dealing with errors: the EITHER monad

When some operation produces an error, we may want more data about it. We’ll create an Either monad, which can be a Left (if there was an error) or a Right (if no error was produced). For instance, a function doing an API call would return a Left or Right monad, depending on how the call went.

First, let’s look at Either itself, which (as in the case of the Maybe monad) is another factory that produces either Left or Right monads.

function Either(l, r) {          // ➊
  !isEmpty(l)                    // ➋
    ? Left.call(this, l)         // ➌
    : Right.call(this, r);       // ➍

  this.toString =                // ➎
    () => `Either(${l},${r})`;
}

To create an Either, let's use the "error-first" strategy that Node.js uses. If the first argument is not empty ➋ we assume there was an error, and produce a Left ➌; otherwise the second argument represents data and we use that to produce a Right ➍. We have to override the standard .toString() method ➎ to produce a better description of the object.

Let’s get into the details. The Left monad (see below) resembles the Nothing one. Instead of a isNothing() function ➊ we'll have a isLeft() one; we could have called it isError() instead, but I wanted to keep the same naming style. The .map() and .chain() methods ➋ do nothing.

function Left(x) {
  Monad.call(this, x);                 
  this.isLeft = () => true;           // ➊
  this.map = this.chain = () => this; // ➋
}

On the other hand, Right is similar to Just. The .isLeft() method logically returns false ➊. The .map() method is more complex, so we'll just show pseudocode ➋. We have to evaluate fn(x) and check if it produced an error ➋ and, depending on that, return either a Left or a Right. The same type of logic ➌ applies to .chain().

function Right(x) {
  Monad.call(this, x); 
  this.isLeft = () => false;          // ➊
  this.map = (fn) =>                  // ➋
    // call fn(x) and store it in v
    // if fn(x) produced an error e, 
    // return new Left(e)
    // otherwise return new Right(v)
  this.chain = (fn) =>                // ➌
    // similar to .map() but unwrap v
    // when creating the new Right
}

If you are coding a Node-style callback, which expects error and data parameters, producing an Either is straightforward, along the lines of the code below. Note that you would surely do something with the new Either, not just return it:

function someCallback(error, data) {
  return new Either(error, data)
    // do some operations with the Either
}

Working with Either is very much the same as with Maybe; the only difference is that when you got a Left you can check its value (with .valueOf()) and use that for whatever you want. Other than that, Left mirrors Nothing, and Right mirrors Just.

Recovering from errors

How can we recover from issues? We can add a .recover() method; it will do whatever we need when there is an error (when we have a Left) but nothing otherwise (when we have a Right). With Maybe, we wanted to pass a default value to use; here, we had to pass a function to deal with the error. The extra code is as follows:

function Left(x) {
  // ...all previous code, plus:
    
  this.recover = (fn) =>               // ➊
    // evaluate fn() and store it in v  // ➋
    // if it produces an error e,
    // return new Left(e)
    // otherwise return new Right(v)
}

function Right(x) {
  // ...all previous code, plus:

  this.recover = () => this;           // ➌
}

If you got a Left, .recover() will invoke your function ➊ and produce a new Left or Right ➋ based on whatever the function does. Using .recover() with a Right ➌ produces no effect.

Dealing with exceptions: the TRY monad

We can go further with the previous Either monad. Consider a function that might throw an exception. We can use the Try monad to produce an Either (a Left or a Right) as before. The needed code is shown below:

function Try(fn) {
  try {
    Right.call(this, fn());       // ➊
  } catch (e) {
    Left.call(this, e.message);   // ➋
  }
}

// Or, equivalently:

function Try(fn) {
  try {
    Either.call(this, null, fn());
  } catch (e) {
    Either.call(this, e.message, null);
  }
}

Logic is very simple; we call the fn() function, and if there’s no exception ➊ we return a Right with whatever the function returned, and if an exception e was thrown ➋ we return a Left with the exception. The second alternative implementation does the same, albeit a tad more indirectly.

Usage is straightforward: We could just rewrite our previous example, which showed a customer’s country, by having getCustomer() return a Try; no further change would be needed.

Dealing with future values: Promises

We’ve left the simplest example for the end: promises! It so happens that JavaScript’s own promises are already pretty much like monads. We can make do by just modifying Promise.prototype a bit:

Promise.prototype.map =
  Promise.prototype.chain =
    Promise.prototype.then;    // ➊

Promise.prototype.ap =         // ➋
  function(otherPromise) {
    return this.map(otherPromise.map);
  };

There’s an issue; promises always unwrap their values (so if you have a promise that resolves to a promise that resolves to a value, you get just one promise that resolves to a value, not a promise wrapped in another promise, according to the standard specification) so .map() and .chain() behave the same way, as a synonym for .then().

We can add an .ap() method with ease ➋ and the code is equivalent to what we saw in the previous article for monads; check it out.

Conclusion

Over these two articles, we have seen what monads are and how they help write simpler, more declarative code. Considering how monads are sometimes explained, a crucial detail is that just focusing on HOW they are built instead of WHAT they are suitable for actually misses the point of having monads at all. The implementation of monads isn’t that complex -we only needed a few lines of vanilla JS- so you can now start taking advantage of them for your own work; go ahead!

Forever Functional #37 — Can AI do that?

Federico Kereki — Mon, 29 Apr 2024 22:13:09 GMT

Forever Functional #37 — Can AI do that?

Given the advances in Artificial Intelligence (AI), often coupled with Machine Learning (ML), which have provided us with tools like ChatGPT and others, the question pops up again: Is there anything AI cannot do? Can AI do anything we can think of? This article will consider that question, look at an interesting problem, and see whether AI can handle it.

An old question

The idea that machines could do everything dates back to Alan Turing, the English mathematician who was key to breaking German secret codes during World War II, as shown in the movie “The Imitation Game”. Back in 1950 (many years before we had computers even minimally approaching the power and capabilities of modern ones), he wrote a paper, “Computing Machinery and Intelligence”, in which he considered the question, “Can machines think?” The paper is very interesting and defined a test (“Turing’s Test”) by which it could be possible to decide whether machines can be said to think.

In the article, Turing considered nine possible objections and finally decided it was possible that machines could think, but not at that time. The article also discussed what is meant by “thinking”!

If we want to consider that question, it seems that our question, “Can AI do that?” (meaning, anything we can dream of, and in particular, thinking) could have a positive answer, though it’s still pending… so we’re left with an uncertainty. Let’s consider instead a rather simpler question, whose answer could be a boon to developers, mathematicians, logicians, and more!

A simpler (?) question

Instead of thinking about machines being able to do any task requiring intelligence, or about thinking in particular, let’s focus on a single issue: given a program, can we decide whether it works or not? This is very ambitious because we should be able to specify what programs should produce for every possible input, so let’s tone down the question a bit. Instead of that very general first question, let’s just think about applying AI to detect whether a function may end in an infinite loop. If a function loops forever, we’re certain the function is not correct, so at least that’s a good step forward. We may not know if a function works well, but we may be sure if it doesn’t.

An aside: if we could decide whether a function will always stop, we’d be able to prove mathematical theorems very simply! For instance, suppose we wanted to see whether the Goldbach Conjecture (which says that every even number greater than 2 can be expressed as the sum of two prime numbers) is true. We could write a goldbachTest() function that would test if the conjecture was true for ever-increasing values 4, 6, 8, 10... etc., stopping only if the conjecture failed for some value. If we applied our "loop detection" function to goldbachTest, and it said that the function would loop forever, we'd know the conjecture was true, and false otherwise!

Let’s start thinking about our problem, detecting whether functions are “infinite-loop-less” or not. Is this possible? For at least some functions, the answer is “yes”. For example, if you consider functions that do not include looping statements (while, for) and do not call other functions (or themselves, using recursion), we can be sure they must always end. Furthermore, recognizing these very special "linear" functions could be done by a program that wouldn't even need AI; you can write it with ease.

However, we want to be able to work with any function and see whether it may enter an infinite loop. What about using AI and ML to detect them? For example, how do we teach a machine to recognize cats? An ML method is based on processing many images, some of which show cats and some do not. Eventually, a decision engine “learns” to distinguish cats from non-cats, and this has been done many times.

In that way, we could think of teaching a machine to recognize looping functions by feeding it with lots of different functions, some of which are loopless and some of which are not, and hope that the ML method produces our desired result: an algorithm capable of deciding whether any function may or may not enter an infinite loop. But would this work?

A paradoxical limit

The ML idea is there, and we know it can work, at least for some problems; could it work for ours? Let’s suppose it would: our process would end by producing our desired willLoop(fn) function that, given any fn function, would precisely return either true (if the function could enter an infinite loop) or false (if the function would always be guaranteed to finish).

But the (assumed) existence of this willLoop function implies an inevitable paradox! To see it, imagine we wrote a mystery(fn) function as shown below:

function mystery(fn) {
  if (willLoop(fn)) {
    return true;
  } else {
    while (true) { 
      /* loop forever! */
    }
  }
}

What does mystery do? Given a fn function, if:

fn will loop in some case, mystery returns true
fn will never loop, mystery enters an infinite loop

And now, the big question: what happens if we call mystery, giving the mystery function itself as its parameter?

Don’t object to the idea of feeding a function with its own code. For instance, Prettier is written in JavaScript, and we can use Prettier to format itself. Similarly, we can use ESLint to detect problems in its own code. Even if it may be a bit unusual, in principle, there’s no objection to calling a function with its own code as an argument.

Let’s analyze what happens if we call mystery(mystery).

if willLoop(mystery) returns true (meaning that mystery will loop forever), then mystery will return a value and finish, but
if willLoop(mystery) returns false (meaning that mystery will never loop), then mystery will enter an infinite loop.

This is contradictory! There’s no way out of this paradox (similar to Bertrand Russell’s “Barber Paradox”) other than deciding that mystery cannot exist, and this implies that willLoop cannot exist either... pity!

In computability theory, we would say that our problem, detecting whether functions may or may not enter an infinite loop, is undecidable. The “Halting Problem” was shown in 1936 to be another undecidable problem; Alan Turing later provided a different proof of the fact.

Conclusion

The limits and capabilities of AI, based on ML or not, are clearly growing every day, and we don’t yet know how far they may go. However, as we have shown here, applying AI and ML to the problem of deciding if a function may enter an infinite loop is unrealistic and cannot succeed without producing an impossible logical paradox.

There are limits to AI, after all!

Originally published at https://blog.openreplay.com.

Forever Functional #37 — Can AI do that? was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #36 — D.I.Y. Booleans?

Federico Kereki — Thu, 29 Feb 2024 11:30:58 GMT

Forever Functional #36 — D.I.Y. Booleans?

Could you program if you didn’t have booleans? What about lacking and, or, and other operators? Would you be able to cope without if or while statements? Functional Programming is very powerful, and in this article, we'll see how we can make our own booleans in a fully functional way.

What do we use boolean values for? The answer is simple: to pick one thing or another. For instance, in an if statement, you do one thing or another depending on the value. If we can only work with functions, we will represent a boolean value by a function; there is no other option!

Given two values, the boolean function that represents “true” returns the first. Similarly, given two values, the boolean function that represents “false” will return the second. We can write:

const TRUE  = (trueValue, falseValue) => trueValue;
const FALSE = (trueValue, falseValue) => falseValue;

Can we do something with these? Let’s start with something simple, to get used to these values gradually. We can write a toString() function to transform the boolean value into a string.

const toString = boolValue => boolValue("T", "F");

console.log(toString(TRUE));   // "T"
console.log(toString(FALSE));  // "F"

In our implementation, boolean expressions will always be evaluated as TRUE or FALSE.

Writing our boolean operators

OK, we now have the most basic values, TRUE and FALSE. But, if we had no booleans, we would not have any boolean operators either! So, what can we do? Let’s start with the simplest one.

The “not” operator

The first operator we’ll work out is the equivalent of JavaScript’s !: given a boolean value x, we want to write something corresponding to !x.

const NOT = (X) => X(FALSE, TRUE);

How does this work? Keep in mind that a boolean value is now a function that receives two values and returns the first if the boolean value represents “true” or the second if it represents “false”. Here, we pass FALSE and TRUE as values, so if the boolean value represents “true”, FALSE will be returned, and if the value represents “false”, TRUE will be the result. We can test this quickly:

console.log(toString(NOT(TRUE)));  // "F"
console.log(toString(NOT(FALSE))); // "T"

Study this carefully, and make sure you understand how this works because the following operators are a bit more involved but require the same kind of thinking.

The “or” operator

Let’s create a version of the “OR” (||) operator, so given two boolean values, X and Y, we can write something equivalent to X||Y. First, we must remember how the operation works; check its truth table below.

The truth table for the OR operator

Checking the table above, we can say that:

if X is TRUE, the result is TRUE, no matter what Y is.
if X is FALSE, the result matches the value of Y.

We can transform this into code:

const OR = (X, Y) => X(TRUE, Y);

Let’s work this out, which is more involved! Suppose X represents TRUE. In that case, it will return the first argument it's given (in this case, TRUE), so when X is TRUE, OR(X, Y) is also TRUE. On the other hand, if X is FALSE, it will return the second argument it's given (here, Y), so in that case, OR(X, Y) will equal Y. Everything is according to our analysis of the table above.

The “and” operator

Let’s move on to the “AND” (&&) operator, so given x and y we can calculate x && y. The truth table for it is as follows.

The truth table for the AND operator

In summary:

if X is FALSE, the result is FALSE no matter what Y is.
if X is TRUE, the result matches the value of Y.

This is transformed directly into code:

const AND = (X, Y) => X(Y, FALSE);

This analysis is very similar to what we did for OR. Without going into much detail, if X is TRUE, it will return the first argument it's given (so, Y), and if X is FALSE, the AND will be FALSE; again, the working of this function matches our analysis.

By the way, you could also implement (more mysteriously) OR = (X,Y) => X(X,Y) and AND = (X,Y) => X(Y,X); can you work out why? See the last section of the article for these and other questions.

Operators for circuit building

We’re on a roll! Let’s go for some other operators. In electronic circuit design NOR and NAND logic gates are frequently used. (Why? This has to do with the concept of "universal operators", but we won't go into that here. NAND is also known as the "Sheffer stroke", X↑Y, and NOR as the "Webb Operator", X↓Y.)

The truth table for the NOR and NAND operators

The definitions are simple:

X NOR Y is just the negation of X OR Y, so !(X || Y), equivalent to !X&&!Y.
Similarly, X NAND Y is the negation of X AND Y, so !(X && Y) or, equivalently, !X||!Y.

const NOR  = (X, Y) => NOT(OR(X, Y));
const NAND = (X, Y) => NOT(AND(X, Y));

We won’t go into details; after all, the code fully matches the definitions we gave above, and it’s easy to verify they work correctly.

Other operators

So far, we’ve been able to transform several JavaScript operators into our functional style. What about some other operators that are less commonly used? The three we will see are:

X XOR Y, exclusive OR (but not the bitwise ^ operator). This is written as X⊕Y or X⊻Y in boolean algebra.
X EQU Y, equivalence, usually written as X↔Y or X≡Y
X IMP Y, implication, written as X⊃Y or X⇒Y

The following table resumes the trio.

The truth table for the XOR, EQU, and IMP operators

We can note:

The results of X XOR Y and X EQU Y are always the opposite.
X XOR Y is equivalent to X !== Y or, equivalently, (X && !Y) || (!X && Y)... uglier!
X EQU Y is equivalent to X === Y or (X && Y) || (!X && !Y)
X IMP Y is always true unless X is TRUE and Y is FALSE, so !X || Y. (Check it out!)

const XOR = (X, Y) => X(NOT(Y), Y); 
const EQU = (X, Y) => X(Y, NOT(Y)); 
const IMP = (X, Y) => X(Y, TRUE);

Can you see how these work? Going directly to the definitions is best. For instance, let’s see XOR: if X is TRUE, then the result will be NOT(Y), and if X is FALSE, the result will be Y, as we saw earlier. (I'll leave the other two expressions to you.) The match between the boolean algebraic definitions and the actual JavaScript code gives us a lot of confidence in the validity of the results.

Writing conditional statements

We now have functional equivalents to boolean values, but what about using them? After all, the standard if and while JavaScript statements are not designed to work with our invented values. We will have to show that we can write our alternative implementations of both statements so we will be able to code anything we want to.

Writing our if statements

Now, what would an if look like? It would be a function (naturally! we only have functions!) with three parameters:

booleanFn, a function that returns a boolean value
thenFn, a function to be executed if the boolean value means "true"
elseFn, a function to be executed if the boolean value means "false"

(Why are we providing functions? We don’t want anything to be evaluated unless it’s necessary. For example, if the boolean value is evaluated as TRUE, we will then evaluate thenFn() and ignore elseFn(); we will only evaluate what we really need.)

We would then write:

const ifThenElse = (booleanFn, thenFn, elseFn) =>
  booleanFn()(thenFn, elseFn)();

For example, let’s write a statement that will print out “AM” or “PM” depending on the time of the day. Let’s assume an isMorning() function that returns a TRUE boolean value in the morning and a FALSE one in the afternoon.

const printAM = () => console.log("It's AM");
const printPM = () => console.log("It's PM");

ifThenElse(isMorning, printAM, printPM);  // AM or PM as it may be

The isMorning() function would be written as follows. Keep in mind this is a very simple example; in reality, the evaluation could be much longer and more complex:

const isMorning = () =>
  new Date().getHours() < 12 ? TRUE : FALSE;

Why are we writing this using the ternary operator? The reason is that in a purely functional language, any test would return either TRUE or FALSE, our functions, but in JavaScript (which, after all, does have booleans!) we have to do the conversion ourselves.

Writing a while loop

We’re almost done; we managed to write basic TRUE and FALSE values, implemented several boolean operators, and also have an if alternative; we only need a while equivalent for looping, and we'll have all the tools we could ever need.

This will be a tad trickier than the if code. In Functional Programming, instead of loops, we use recursion. The functional way of doing a while loop would be the following.

const whileLoop = (booleanFn, loopFn) =>
  booleanFn()(
    () => {
      loopFn();
      whileLoop(booleanFn, loopFn);
    },
    () => {}
  )();

Let’s start by describing the parameters of the whileLoop() function.

booleanFn is, as in the if implementation, a function that will return a boolean value
loopFn is a function that will be executed in every pass of the loop, as long as the evaluated boolean value is TRUE.

How does this work? If booleanFn() evaluates to TRUE, the first argument to the function will be evaluated - it will execute loopFn() and recursively call itself again. On the other hand, when booleanFn() evaluates to FALSE, a "no operation" function will be executed, and the loop will end; good!

Let’s finish with a short example showing a countdown loop.

let number = 5;
const checkPositive = () => MakeBool(number > 0);
const loopFn = () => console.log(number--);
whileLoop(checkPositive, loopFn); // 5 4 3 2 1 in that order

Can you follow how this works? The part that’s usually harder to understand is the usage of recursion to do the looping; after you wrap your head around that, the rest follows quickly.

Conclusion

We started this article by wondering what we would do if we had to code without having boolean values and operators, and also lacking basic flow statements like if and while. By applying functional programming ideas, we were first able to produce our own TRUE and FALSE equivalents. We then added several operators to be able to build complex expressions, and we finally produced functional versions for if and while statements.

Initially, it seemed like we were getting into an impossible situation, but we solved all the issues. Of course, working with JavaScript, you wouldn’t do this — why would you? After all, booleans are an integral part of the language, so there’s no need to do all this rigmarole to get what you already have!

The article's objective was to help you widen your horizons and realize that Functional Programming goes even further than letting you use functions in some ways; it allows you to elegantly express many concepts and operations, all with the same basic tools—impressive!

I cannot say it better: as it reads in an article by Alex Beal,

“In the end, this might strike you as nothing more than a useless programming trick. In a sense that’s right. I’d never use this in my own code. What makes this technique so valuable is that it actually fits into the broader context of lambda calculus […] In the language of lambda calculus, you’re given only a very basic set of tools. […] Incredibly, it turns out that that’s all you need.”

References

If you want to learn more about the techniques we used here, you should read about Church Encoding and Scott Encoding; both representations are the same for boolean values.

In the mood for some questions?

If you want to experiment a bit more, try your hand with these questions.

#1. Show that these OR versions are equivalent to the one we wrote.

const OR1  = (left, right) => left(left, right);
const OR2  = (left, right) => right(right, left);

#2. Do the same for these alternatives to our AND.

const AND1 = (left, right) => left(right, left);
const AND2 = (left, right) => right(left, right);

#3. Show that if X is a boolean value, X(Y,Z) is equivalent to (X && Y) || (!X && Z).

#4. Using the previous result, prove that our NOT, OR, AND, etc., definitions are correct.

#5. Show that our implementations of AND and OR also apply JavaScript's "short circuit" evaluation rules.

#6. Do the alternative versions for AND and OR from questions #1 and #2 also apply short circuit evaluation like JavaScript?

#7. Can you modify ifThenElse(...) so its third parameter will be optional?

#8. After implementing the change in the previous question, can you shorten whileLoop(...) to use ifThenElse(...) and take advantage of the optional parameter?

Check the complete series of articles on Functional Programming and JavaScript:

https://medium.com/stackanatomy/forever-functional-the-series-616ad90645b4

Originally published at https://blog.openreplay.com.

Forever Functional #36 — D.I.Y. Booleans? was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #34 — Maximize JavaScript’s Performance WITHOUT Transducers

Federico Kereki — Tue, 19 Dec 2023 22:21:23 GMT

Forever Functional #34 — Maximize JavaScript’s Performance WITHOUT Transducers

In the previous article on transducers we saw a way to optimize long sequences of operations on arrays, but the solution wasn’t that trivial. Many readers wondered whether we could achieve the same result more simply, and this article will tackle that: we won’t use transducers (as we did before) but with the help of some functional programming, we’ll get equally good solutions.

Let’s remember our original problem — which was a trivial example meant to highlight the issues we had. We had an array, and we wanted to (1) take only odd values, (2) duplicate them, (3) keep values under 50, and (4) add 3 to them. The following code achieved this:

const testOdd = (x) => x % 2 === 1;
const duplicate = (x) => x + x;
const testUnderFifty = (x) => x < 50;
const addThree = (x) => x + 3;

const myArray = [22, 9, 60, 24, 11, 63];

const newArray = myArray
  .filter(testOdd)
  .map(duplicate)
  .filter(testUnderFifty)
  .map(addThree``
console.log(newArray); // [21,25]

What’s the problem here? Every time you apply an operation, a new intermediate array is created, and with large amounts of data, the extra time may be significant.

In the previous article, we described a solution based on trying to go array element by array element and applying all transformations in order, and we developed transducers for that. But we may make do with something simpler! Let’s see that.

A first (but not too good) solution

Our example was straightforward, and some readers objected by reasoning that it was pretty clear that the only values of the original array that we’d pick would be odd ones, under 25, and then we would duplicate them and add three, so a simple loop could do the job… and we wouldn’t even need the original four functions we used!

const simplifiedPass = (someArray) => {
  const result = [];
  someArray.forEach((value) => {
    if (value % 2 && value < 25) {
      result.push(value * 2 + 3);
    }
  });
  return result;
};

const newArray2 = simplifiedPass(myArray);
console.log(newArray2);

This works and is perfectly correct — but it’s hard to generalize. With our simple example, deducing which numbers would be processed was easy, but in real life, the logical checks could be very complex, and you wouldn’t be able to reduce them to a single test as we did here. So, while this shows that optimization is doable, the method itself cannot be applied in every case; we need a more general solution.

A second (also handcrafted) solution

As in the previous case, we can do better by going element by element and applying maps and filters in sequence.

const singlePassFourOps = (someArray) => {
  const result = [];
  someArray.forEach((value) => {
    let ok = false; // ①
    if (testOdd(value)) {
      value = duplicate(value);
      if (testUnderFifty(value)) {
        value = addThree(value);
        ok = true;
      }
    }
    if (ok) { // ②
      result.push(value);
    }
  });
  return result;
};

const newArray3 = singlePassFourOps(myArray);
console.log(newArray3); // [ 21,25 ]

We use an ok variable ① to learn if a value from the original array passed all tests ②. Each filter() is transformed into an if, and each map() updates value. If we reach the end of the operations, we set ok to true, which means we'll push the final value into the result array. This works! However, we had to write a function from scratch, and we may be able to achieve a more general solution.

A third (and more general) solution

The previous code requires writing a function for each set of transformations. However, what about passing all the mapping and filtering functions in an array? This would mean we could write a general function that could deal with any combination of filters and maps.

There’s a problem, though: how will we know whether a function in the array is meant to be a filter or a map? Let’s have an array with pairs of values: first an “M” or “F”, meaning “map” or “filter”, and then the function itself. Testing the first value of the pair will let us know what to do with the second value, the function.

const singlePassManyOps = (someArray, fnList) => {
  const result = [];
  someArray.forEach((value) => {  // ①
    if (
      fnList.every(([type, fn]) => {  // ②
        if (type === "M") { // ③
          value = fn(value);
          return true;
        } else {
          return fn(value); // ④
        }
      })
    ) {
      result.push(value);
    }
  });
  return result;
};

const newArray4 = singlePassManyOps(myArray, [
  ["F", testOdd],
  ["M", duplicate],
  ["F", testUnderFifty],
  ["M", addThree],
]);
console.log(newArray4);

This works: we go through the array, element by element ①. For each function in the array ②, if it’s a map ③ we update value, and otherwise we test whether to go on or not ④. Why are we using every() instead of foreach()? The key is that we want to stop going through the array of functions as soon as a filter fails, but foreach() doesn't have a nice way to stop the loop. On the other hand, every() stops looping as soon as a false result is encountered - which will happen if a filtering function returns false. (And, by the way, that's why we return true after a mapping, so every() won't stop.) This is going better! Can we make it simpler?

A fourth (and simpler) solution

We can simplify the work by writing a pair of functions to help us produce the needed array; given a function, they will produce the right pair of values.

const applyMap = (fn) => ["M", fn];
const applyFilter = (fn) => ["F", fn];

With these functions, we can change the code above to the following.

const newArray5 = singlePassManyOps(myArray, [
  applyFilter(testOdd),
  applyMap(duplicate),
  applyFilter(testUnderFifty),
  applyMap(addThree),
]);
console.log(newArray5);

This is nicer, and also declarative in aspect: you clearly see we first apply a filter ( testOdd), then a map ( duplicate), etc., in the same sequence as in our original code. Also, performance is optimal; we don't have any intermediate arrays, and we don't perform any unnecessary filters or maps. We're done! However...

The fifth (and definitive) solution

In the previous article, we mentioned we wouldn’t always want to finish by producing an array; we could want to apply a final reduce() operation. We can fix this by making the initial value of result and the function that updates it optional, with predefined default values.

const singlePassMoreGeneral = (
  someArray,
  fnList,
  initialAccum = [],
  reduceAccumFn = (accum, value) => {
    accum.push(value);
    return accum;
  }
) => {
  let result = initialAccum;      // ①
  someArray.forEach((value) => {
    if (
      fnList.every(([type, fn]) => {
        if (type === "M") {
          value = fn(value);
          return true;
        } else {
          return fn(value);
        }
      })
    ) {
      result = reduceAccumFn(result, value); // ②
    }
  });
  return result;
};

const newArray6 = singlePassMoreGeneral(myArray, [
  applyFilter(testOdd),
  applyMap(duplicate),
  applyFilter(testUnderFifty),
  applyMap(addThree),
]);
console.log(newArray6);

Apart from adding initialAccum (the initial value of the accumulator for the reducing operation) and reduceAccumFn (the reducer function itself) the other changes are the initial value for result ① and the way result is updated ②.

We can test the code by finding the sum of the final values.

const newValue = singlePassMoreGeneral(
  myArray,
  [
    applyFilter(testOdd),
    applyMap(duplicate),
    applyFilter(testUnderFifty),
    applyMap(addThree),
  ],
  0,
  (x, y) => x + y
);
console.log(newValue);

This worked! We can now apply any sequence of mapping and filtering operations optimally, optionally finishing with a reducing step if desired.

Summary

We started the article trying to find a simpler, though equally powerful, way of optimizing a sequence of operations on a large array. We went from a very simple solution, which wasn’t general enough, to a final solution that’s fully equivalent to the transducers’ one, although arguably easier to understand, despite also using functional programming in many ways. This goes to show the validity of the idea that “there’s more than one way to skin a cat”- or, in our case, “to optimize array processes”!

Don´t miss the first part of this article, in which we used transducers to solve the problem.

Forever Functional #32 — Maximize JavaScript’s Performance With Transducers

Also, check the next article, which shows how we optimized the transducer-less solution to greater performance.

Forever Functional #35 — Optimizing JavaScript… Which Way?

Originally published at https://blog.openreplay.com.

Forever Functional #34 — Maximize JavaScript’s Performance WITHOUT Transducers was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Forever Functional #33 — Complex Typing in TypeScript, Part 2

Federico Kereki — Tue, 21 Nov 2023 10:58:38 GMT

Forever Functional #33 — Complex Typing in TypeScript, Part 2

Adding types to some functional programming constructs may not be simple, and this article will show you different ways of providing data typing for currying higher-order functions.

In the previous article we saw how to work out a TypeScript version of our partial application code. This proved to be feasible but a bit tricky! In this second part, let’s turn our attention to another functional programming tool, currying, and see how to develop a fully typed TypeScript version.

Just to help you remember, currying transforms a function with several parameters into a new function that receives the first argument and returns a function that receives the second argument, which in turn returns a final function accepting the last, third argument and producing the result. (For the reasons and advantages of doing this, refer to the previous article.) The following image from my Mastering JavaScript Functional Programming book, shows the concept.

For an example (taken from the book) we could have:

const make3 = (a: string, b: number, c: string): string => `${a}:${b}:${c}`;

const f1 = curry(make3);
// (arg: string) => (arg: number) => (arg: string) => string

const f2 = f1("A");
// (arg: number) => (arg: string) => string

const f3 = f2(2);
// (arg: string) => string

const f4 = f3("Z");
// string -- f4 equals "A:2:Z"

The make3() function receives three arguments and produces a string. When curried, you get a f1() function that receives the first argument and returns a function, f2(), that receives the second argument and returns a final f3() function, that receives the last argument and returns the value that make3() would have returned.

The JavaScript code to implement a currying higher-order function was as follows:

const curry = (fn) =>
  fn.length === 0 ? fn() : (p) => curry(fn.bind(null, p));

The function is recursive, and that’s a challenge for typing. Let’s see how to do that, but first we’ll go with a simplified version.

Checking types — the simple version

If we knew that we’d never curry functions with, say, more than four parameters, we could make do with a simple, though longish solution.

type SimpleCurry = 0 extends P["length"]
  ? R
  : EQUALS<1, P["length"]> extends true
  ? (a: P[0]) => SimpleCurry<[], R>
  : EQUALS<2, P["length"]> extends true
  ? (a: P[0]) => SimpleCurry<[P[1]], R>
  : EQUALS<3, P["length"]> extends true
  ? (a: P[0]) => SimpleCurry<[P[1], P[2]], R>
  : EQUALS<4, P["length"]> extends true
  ? (a: P[0]) => SimpleCurry<[P[1], P[2], P[3]], R>
  : never;

In this type definition, P represents the array of types for the parameters of the function we are currying, and R represents the result type for that function.

When the function has no parameters, we return R. This is correct because in our curry() function, if fn.length is zero, we call fn() and return the produced value.
if the function has one parameter, we return a curried function with no parameters
if the function has two parameters, we return a curried function with just one parameter.
if the function has three parameters, we return a curried function with two parameters.
if the function has four parameters, we return a curried function with three parameters.
if the function has five or more parameters, we return never indicating an error.

This is fairly straightforward, and we can now write the following, which works perfectly well. Note I changed from an arrow function to a classic definition; we’ll see why, below.

function curry(
  fn: (...args: P) => R
): SimpleCurry;

function curry(
  fn: (...args: any[]) => any
): SimpleCurry, ReturnType> {
  return fn.length === 0
    ? fn()
    : (x: any) => curry(fn.bind(null, x));
}

You may wonder why we have two definitions for the function. TypeScript cannot verify that our curry() function works correctly because it cannot deduce that, for every function, it will eventually produce a result instead of another curried function. We used a trick in the previous article, which serves well here. We are defining an overloaded function, but with just one signature, which loosens things up for TypeScript. (By the way, it is possible to define overloading for arrow functions, but I think it's clearer how I did it.) Obviously, this isn't a very safe way of working; you have to ensure on your own that the function is type-correct because this trick essentially bypasses some of TypeScript's checks!

So, our limited version works well, but let’s aim for a version that works with any number of parameters.

Checking types — the full version

Since the currying function is recursive, we must work recursively. There are two cases that we must consider:

if we curry an unary function (that is, with a single parameter) the result will be the function itself
if we carry a function with two or more parameters, the output will be a unary function (with the first parameter) that will return a (curried) function that will deal with the rest of the parameters.

We can write this the following way:

type FullCurry = P extends []
  ? R
  : P extends [infer H]
  ? (arg: H) => R // only 1 arg
  : P extends [infer H, ...infer T] // 2 or more args
  ? (arg: H) => FullCurry<[...T], R>
  : never;

Let’s analyze the code. Again, P is the array of function parameters types, and R is its result type.

with no parameters, the type is R
with a single parameter of type H, the result of currying is a function that gets an H-type argument and produces an R-type result
with more parameters (H and the rest, which we collectively call T - "H" and "T" stand for "Head" and "Tail", as usual when working with lists) the result of currying is a function that gets an H-type argument and produces a curried function with T-type parameters that eventually returns an R-type result

The full TypeScript code is essentially the same, only using the new FullCurry type instead.

function curry(
  fn: (...args: P) => R
): FullCurry;

function curry(fn: (...args: any) => any) {
  return fn.length === 0
    ? fn()
    : (x: any) => curry(fn.bind(null, x));
}

We’ve done it! This recursive type definition can deal with any number of parameters, so we have a general solution. However, remember a restriction: currying only works with functions that have a known, fixed number of parameters, and our code won’t work with other functions.

Summary

We’ve shown how complex typing also applies to currying, and we have to use an overloading trick to achieve this. Currying is an essential functional programming technique, and in this article, we’ve seen how to use it with TypeScript for better, safer coding; it’s a win!

Originally published at https://blog.openreplay.com.

Forever Functional #33 — Complex Typing in TypeScript, Part 2 was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Optimize Vue With Web Workers

AndaMary — Wed, 25 Oct 2023 00:16:19 GMT

Web workers are a modern web technology that provides a way to run JavaScript in the background, parallel to the main execution thread. This concurrency model is especially beneficial in the browser environment, where, traditionally, JavaScript runs in a single-threaded fashion. They enable web applications to run background scripts without interfering with the main thread, and this article will show you how to use them.

Vue.js is a progressive JavaScript framework used for building user interfaces, especially single-page applications (SPAs). It is renowned for its simplicity and component-based architecture. Since its introduction, it has evolved as one of the leading JavaScript frameworks, primarily because:

Reactivity: Vue’s reactive data-binding system lets developers synchronize the UI with the underlying data model effortlessly.
Component-based: This architecture facilitates code reusability and modular development.
Lightweight: Vue is incrementally adoptable, meaning developers can start small and scale with complexity as needed.

Developers cherish Vue because it is easy to integrate and facilitates the creation of powerful single-page applications (SPAs) and user interfaces.

In today’s web, where applications are becoming increasingly dynamic and data-driven, performance is no longer a luxury-it’s a necessity. Users expect snappy responses, fluid animations, and instantaneous feedback. Here’s where web workers come in:

Non-blocking Operations: Web workers can perform tasks without interfering with the main thread. This means the user interface remains entirely responsive while a web worker can process data or perform computations. Heavy computations or processing can hinder a web application’s responsiveness. Web workers mitigate this by running tasks in parallel, ensuring the main thread remains unblocked.
Optimal CPU Utilization: On multi-core processors common in today’s devices, web workers can truly shine by leveraging parallel processing capabilities.
Scalable Web Applications: As web applications grow and take on more complex tasks, web workers provide a means to manage this complexity without sacrificing performance. They are, in essence, a step forward in building scalable, high-performance web applications.

Understanding Web Workers

To understand the significance of Web Workers, it is crucial first to comprehend the environment in which JavaScript traditionally operates. JavaScript, by design, is a single-threaded language. This means it has one call stack and one memory heap, executing one operation at a time.
While this single-threaded nature simplifies state management and ensures consistency in operation, it can also introduce challenges, particularly with performance. For instance, long-running or computationally intensive tasks can block the main thread, leading to an unresponsive user interface, an issue often termed the “JavaScript freeze”.

The traditional solution to this issue involved techniques such as asynchronous callbacks, promises, or, more recently, async/await. However, while these solutions provide a way to work around the blocking issue, they don’t solve it entirely — the code is still technically running on the same single thread.

This is where Web Workers come into play. A web worker is a script the browser runs in the background, separate from the main execution thread. This means that no matter how intensive the operations a worker performs, it won’t block the user interface or other user-triggered scripts.

A web worker is, in essence, a JavaScript file hosted on a server, created using the Web Worker API’s Worker() constructor. Once instantiated, the worker operates in its own execution environment parallel to the main thread.

Each web worker has its own JavaScript context and global scope. It doesn’t share any state with the main thread, which helps ensure data consistency and eliminates the risk of race conditions, a common issue in multi-threaded environments.

Running tasks in the main thread versus a web worker has distinct advantages and drawbacks.

Main Thread: When tasks run on the main thread, they can access the page’s DOM and directly manipulate it. They can also use window methods and objects. However, long-running or complex tasks can block user interactions, leading to a “frozen” or laggy interface.
Web Worker: Tasks running inside a web worker do not block the main thread, ensuring a smooth, responsive user interface, even when heavy computation occurs in the background. However, web workers cannot access the DOM, limiting their use to non-UI tasks. Furthermore, they require a message-passing mechanism for communication with the main thread, which can be slightly more complex to manage.

Despite their limitations, web workers represent a significant step forward in JavaScript’s journey towards efficient multithreading and parallel processing capabilities, opening up new possibilities for performance optimization in web applications.

Integrating Web Workers in Vue.js

Before you start, identify the tasks in your application causing the UI to become unresponsive or are computationally heavy. These are prime candidates to be moved into a Web Worker.

One situation where Web Workers excel is in the realm of image processing. For example, when it comes to blurring an image, each pixel must be adjusted based on its neighboring pixels. This task can be computationally demanding for images. This may lead to unresponsive user interfaces if performed on the main thread.

Why Choose a Web Worker for Image Blurring? Three reasons come to mind:

Enhanced Responsiveness: Blurring an high-resolution image can take time. If done on the thread, it can temporarily freeze the application and hinder user interactions. The main thread remains available by delegating this task to a web worker. Ensures that the application remains responsive.
Improved Performance: Parallel processing can significantly boost image processing capabilities. On devices with cores, leveraging a web worker allows for processing by utilizing these cores effectively.
Separation of Concerns: Image processing algorithms can be intricate and involved. We maintain focused application logic that prioritizes UI-related tasks by isolating this functionality within a web worker.

The following sections will illustrate how to create a Vue application that utilizes a Web Worker for blurring images. Users can upload images and instantly view the version within the application without experiencing any noticeable lag or delay. This is a feature that truly highlights the capabilities and efficiency of Web Workers in real-world usage scenarios.

Create the Worker File

Web Workers run in a separate file. Let’s create a new file called imageBlurWorker.js.

In imageBlurWorker.js, you can add your computation-intensive code:

self.onmessage = function (e) {
 const imageData = e.data;
 const blurredData = applyBoxBlur(imageData);
 postMessage(blurredData);
};

function applyBoxBlur(imageData) {
 // Your image blurring logic here.
 // E.g;
 const width = imageData.width;
 const height = imageData.height;
 const data = new Uint8ClampedArray(imageData.data);

 const outputData = new Uint8ClampedArray(data.length);

 for (let y = 0; y < height; y++) {
   for (let x = 0; x < width; x++) {
     const pixelIndex = y * width * 4 + x * 4;
     const redSum = [0, 0, 0];
     const pixelCount = 9;

     for (let dy = -1; dy <= 1; dy++) {
       for (let dx = -1; dx <= 1; dx++) {
         const neighborY = y + dy;
         const neighborX = x + dx;

         if (
           neighborY >= 0 &&
           neighborY < height &&
           neighborX >= 0 &&
           neighborX < width
         ) {
           const neighborIndex = neighborY * width * 4 + neighborX * 4;
           redSum[0] += data[neighborIndex];
           redSum[1] += data[neighborIndex + 1];
           redSum[2] += data[neighborIndex + 2];
         }
       }
     }

     const outputIndex = y * width * 4 + x * 4;
     outputData[outputIndex] = redSum[0] / pixelCount;
     outputData[outputIndex + 1] = redSum[1] / pixelCount;
     outputData[outputIndex + 2] = redSum[2] / pixelCount;
     outputData[outputIndex + 3] = data[pixelIndex + 3]; // Alpha channel
   }
 }

 return {
   width: width,
   height: height,
   data: outputData,
 };
}

In the applyBoxBlur function, we implemented a basic box blur algorithm, a type of neighborhood averaging. The idea is to replace each pixel's color value with the average of its neighboring pixels, including itself.

Here’s a step-by-step breakdown:

function applyBoxBlur(imageData) {
 // 1 Extract the width, height, and data from the image
 const width = imageData.width;
 const height = imageData.height;
 const data = new Uint8ClampedArray(imageData.data);
 const outputData = new Uint8ClampedArray(data.length);

 // 2 Iterate over each pixel in the image
 for (let y = 0; y < height; y++) {
   for (let x = 0; x < width; x++) {
     const pixelIndex = y * width * 4 + x * 4;
     let redSum = 0,
       greenSum = 0,
       blueSum = 0;
     let pixelCount = 0;

     // 3 For each pixel, look at its immediate neighbors (the 3x3 grid around the pixel)
     for (let dy = -1; dy <= 1; dy++) {
       for (let dx = -1; dx <= 1; dx++) {
         const neighborY = y + dy;
         const neighborX = x + dx;

         // 4 Check boundaries to ensure we don't access pixels outside the image
         if (
           neighborY >= 0 &&
           neighborY < height &&
           neighborX >= 0 &&
           neighborX < width
         ) {
           const neighborIndex = neighborY * width * 4 + neighborX * 4;
           redSum += data[neighborIndex];
           greenSum += data[neighborIndex + 1];
           blueSum += data[neighborIndex + 2];
           pixelCount++;
         }
       }
     }

     // 5 Compute the average color value
     outputData[pixelIndex] = redSum / pixelCount;
     outputData[pixelIndex + 1] = greenSum / pixelCount;
     outputData[pixelIndex + 2] = blueSum / pixelCount;
     outputData[pixelIndex + 3] = data[pixelIndex + 3]; // Alpha channel (transparency) remains unchanged
   }
 }

 // Return the new image data (blurred version)
 return {
   width: width,
   height: height,
   data: outputData,
 };
}

Initialization: We extract the image’s dimensions and data. We extract the width and height of the image. The Uint8ClampedArray is a typed array that clamps the values between 0 and 255, which is perfect for our RGBA values
Iterate Over Pixels: For each pixel in the image, we determine the average color value of its neighbors.
Determine Neighbors: We look at each pixel’s immediate neighbors (the 3x3 grid around the pixel).
Sum Color Values: pixelIndex determines the index in the data array for the current pixel.redSum is then initialized to store the summed values for red, green, and blue channels, respectively, and we iterate over the neighboring pixels using the nested loops. For each neighbor, we calculate its position in the data array using neighborIndex. We then add the neighbor's red, green, and blue values to our redSum array.
Calculate Averages: outputIndex determines the position of the current pixel in the output data array. We then divide the summed values for each channel by pixelCount (9, representing the 3x3 grid) to get the average. These averaged values are then stored in the outputData array.

The box blur is a simple and effective method for image blurring, but it’s worth noting that other, more advanced blurring techniques are available. The box blur provides a uniform blur, but other methods can provide more nuanced or directional blurs, depending on the desired effect.

Instantiate and Use the Worker in Your Main Application

In your main JavaScript file or within a specific module where you need to use the worker:

// Initialize the worker
const worker = new Worker("imageBlurWorker.js");

// Set up an event listener to receive messages from the worker
worker.onmessage = function (event) {
 const result = event.data;
 console.log("Received result from worker:", result);
};

// Send data to the worker
const someData = { /.../ };
worker.postMessage(someData);

// Remember to terminate the worker when you're done
// worker.terminate();

Implement a web worker into Vue to create an image blur app

For example, Let us incorporate the web worker into a Vue component.

In your Vue component, you can instantiate a worker using the Worker constructor, passing the path to your worker script as an argument:

const worker = new Worker('./imageBlurWorker.js');

Post messages to the worker and listen for its response.

To send data to the worker, use the postMessage method:

self.postMessage(blurredData);

To listen for messages from the worker, assign a function to the onmessage event handler of the worker:

self.onmessage = function (e) {
 const imageData = e.data;
 const blurredData = applyBoxBlur(imageData);
};

Demonstration in a Vue component

Here’s how you might use the Image blur worker within a Vue component:

Image before blurring:

Output of result of blurred image:

Clean up and terminate the worker

When the component is destroyed, or when you no longer need the worker, you should terminate it to free up resources:

worker.terminate();

This should be done in the beforeDestroy lifecycle hook in Vue to ensure it happens when the component is destroyed.

Following this guide, you can offload intensive computations to a separate thread in your Vue.js applications, resulting in smoother, more responsive user interfaces.

Benefits of Using Web Workers in Vue.js

There are several benefits to using web workers.

Enhanced Performance and Scalability

When you delegate computational tasks to a Web Worker, the main thread remains free to handle other critical tasks. As a result, your application can accommodate more concurrent operations and scale more effectively, leading to a noticeable performance boost.

To illustrate, if your application includes complex data processing tasks or sophisticated algorithms that can create a noticeable delay, you can offload these tasks to a Web Worker. This approach ensures that these time-consuming tasks won’t block the main thread, leading to a more responsive application.

Improved User Experience

With Web Workers, the user interface remains highly responsive, leading to a better user experience. This is because the main thread, responsible for user interactions and UI rendering, remains unblocked and can immediately respond to user actions. Therefore, users won’t experience a frozen or unresponsive interface, even during heavy computations.

Asynchronous Operations

Web Workers thrive in handling tasks that are asynchronous or involve operations like fetching data, working with indexedDB, or crunching large datasets. They can handle such operations independently, sending the results back when ready. This allows Vue.js to continue executing other tasks, including updating the DOM and responding to user events.

Ultimately, using Web Workers in Vue.js provides considerable performance benefits, improves user experience, and allows for more efficient use of modern hardware. It represents a significant evolution in how we can build complex and highly responsive web applications.

Drawbacks and Limitations of Web Workers

Of course, there are some drawbacks as well.

Lack of DOM Access

Web Workers operate on their own thread and cannot access the DOM. This limitation stems from the potential conflicts that could arise from having multiple threads interact with the DOM simultaneously. While this design helps ensure thread safety, any DOM manipulation must happen on the main thread. For instance, you can’t manipulate Vue components directly from a Web Worker or use Vue’s reactivity system within a worker. This means you’ll have to send messages back to the main thread when you want to update the UI based on a computation done by the worker.

Limited Access to Web APIs

Web Workers don’t have access to all Web APIs that the main thread does. Besides the DOM, they can’t access APIs such as localStorage or the methods provided by window object. This limits the tasks that can be offloaded to a Web Worker.

Complexity of Multithreading

While Web Workers offer the advantage of concurrent execution, they also introduce the complexities of multi-threaded programming into the web environment. Developers need to manage the synchronization between the main and every worker thread, handle potential race conditions, and deal with error handling in a distributed environment. Debugging can also be more challenging with Web Workers due to their isolated execution context.

While Web Workers can greatly improve the performance of a Vue.js application, these advantages come with their own challenges. A careful assessment of the tasks to be offloaded, the data to be processed, and the necessary synchronization can help you navigate these limitations and make the most out of Web Workers.

Conclusion

In this article, we explored Web Workers and their integration within Vue.js. We covered the intricacies of how JavaScript and Web Workers operate, showcasing a practical implementation of a Web Worker in a Vue.js component. In examining the benefits, we highlighted the potential performance enhancements and improved user experience. Despite acknowledging their limitations, including lack of DOM access and communication overhead, we concluded that the effective use of Web Workers can significantly improve the efficiency and interactivity of Vue.js applications.

Originally published at https://dev.to on October 13, 2023.

Optimize Vue With Web Workers was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Build A ChatBot With ChatGPT And React

Onu Daniel Onyebuchi — Wed, 25 Oct 2023 00:15:29 GMT

As AI technology advances, chatbots have become a powerful tool for improving user interactions. By combining ChatGPT with user-friendly frameworks like React, developers can create intelligent and dynamic chatbots that engage users in natural and meaningful conversations. This article will show you how to create an AI chatbot using ChatGPT and React, setting up the development environment, customizing the chatbot’s user interface, and managing responses from the ChatGPT API.

Let’s start with the setup. This involves importing dependencies and installing the tools and software the app will need.

Some tools and software that we will use to build the simple chatbot are:

Node.js and npm: Install Node.js, which includes npm (Node Package Manager), from the official website. npm will be used to manage dependencies and run scripts for the project.
Create a new React App using Vite: Open your terminal and create a new React app by running the command below

npm create vite@latest app -- --template react

Navigate to the app directory using this command in your terminal:

cd app

Then, run:

npm install

Install chat-ui-kit-react: This is a UI kit library for building chat interfaces in React applications. To install it, use the following command:

npm install @chatscope/chat-ui-kit-react

To learn more about the chat-ui-kit-react library, you can read the documentation here

We’ll also require some dependencies that will be used in styling the components. The dependencies will be imported on the App.jsx file. You can find it by

Expanding the app folder.
Clicking on the src folder.
Navigating to App.jsx.
On App.jsx, delete the template and leave only the parent element. This is what the App.jsx file should look like.

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

function App() {
 return (
   <>      
   
 )
}
export default App

Import the following components:

import '@chatscope/chat-ui-kit-styles/dist/default/styles.min.css';
import { MainContainer, ChatContainer, MessageList, Message, MessageInput, TypingIndicator } from '@chatscope/chat-ui-kit-react'

Creating Chat UI

chat-ui-kit-react provides components to create a chat interface. We will build the components that include all our chat functionalities in our App.jsx file.

return (
 <>
   {/* A container for the chat window */}
   
     {/* All components are wrapped in the MainContainer */}
     
       {/* All chat logic will be contained in the ChatContainer */}
       
         {/* Shows all our messages */}
         
       
     
   

 
);

Further styling can be applied by editing the Index.css file or adding inline styles.

Manage Messages State

The MessageList component is used to display all of our various messages. We need to store these messages in an array using useState and initialize it with one message.

// State to store chat messages
const [chatMessages, setChatMessages] = useState([
 {
   message: "Hello, I am ChatGPT!",
   sender: "ChatGPT",
 },
]);

To display these messages in our UI, we can achieve this by mapping over the array and rendering each message.


 {/* Map through chat messages and render each message */}
 {chatMessages.map((message, i) => {
   return ;
 })}
;

For a better layout, we can apply some styling to messages from ChatGPT so that the responses are aligned to the left.


 {/* Map through chat messages and render each message */}
 {chatMessages.map((message, i) => {
   return (
            key={i}
       model={message}
       style={message.sender === "ChatGPT" ? { textAlign: "left" } : {}}
     />
   );
 })}
;

We can view our Chatbot by running this command on the terminal.

npm run dev

Our UI should look like this:

Handling user input

MessageInput component enables users to input messages for processing. Additionally, we can implement a function named handleUserMessage to manage the user’s entered messages. This component should be added after the MessageList component.

Now, let’s create the handleUserMessage function. This function will serve two roles:

Creating a new user object that will contain: i. The message from the user. ii. A description of the user as the sender. iii. Indication of the message direction as outgoing. This means the message will be displayed on the left side of the chat UI.
Updating chat messages with the new user message.

// Function to handle user messages
const handleUserMessage = async (userMessage) => {
 // Create a new user message object
 const newUserMessage = {
   message: userMessage,
   sender: "user",
   direction: "outgoing",
 }; 

// Update chat messages state with the new user message
 const updatedChatMessages = [...chatMessages, newUserMessage];
 setChatMessages(updatedChatMessages);
};

Set Up ChatGPT API

To set up ChatGPT API to process user messages, we can follow these steps:

Obtaining an API key from OpenAI

Visit the OpenAI website and create an account.
Log in to your account and click on your profile name or icon to access the menu.
From the menu, select the ‘View API Keys’ option.
Click on the ‘Create New Secret Key’ button.
Once the API key is generated, copy and paste it somewhere safe. Note: The key will not be displayed again, so store it securely.

Setting up ChatGPT API access

We can store the API key as a variable above the App function.

const OPENAI_API_KEY = "YOUR API KEY"; //Replace with your generated openai api key

Process Message with ChatGPT API

After the handleUserMessage function, we will create an asynchronous function called processUserMessageToChatGPT. This function captures the user’s message, sends it to ChatGPT, and returns a response from ChatGPT. The steps involved are as follows:

Preparing the messages in the required format for the API: Messages are categorized into three roles: User, Assistant, and System. “User” represents messages input by the user, and “Assistant” refers to messages from ChatGPT.

async function processUserMessageToChatGPT(messages) {
 // Prepare the messages in the required format for the API
 let apiMessages = messages.map((messageObject) => {
   let role = "";
   if (messageObject.sender === "ChatGPT") {
     role = "assistant";
   } else {
     role = "user";
   }
   return { role: role, content: messageObject.message };
 });
}

Create a System message for ChatGPT: A system message is a special message that provides instructions or context to the language model before processing user messages. It helps guide the behavior and response of the model during the conversation. For instance, a system message could include instructions like:

“Explain all concepts like Shakespeare.”
“You are a customer support representative for a tech company.” You can improve the system message prompt for specific chatbot use cases across different industries, such as Travel, Technology, etc.

// System message for ChatGPT
const systemMessage = {
 role: "system",
 content: "Explain all concept like a Professor in Biochemistry",
};

Prepare the API request body: This is used as a container for the conversation messages and system instructions, and it is sent to the OpenAI API for processing by the ChatGPT model.

const apiRequestBody = {
 model: "gpt-3.5-turbo",
 messages: [
   systemMessage, // System message should be in front of user messages
   ...apiMessages,
 ],
};

Send the user message to ChatGPT API and return the response.

await fetch("https://api.openai.com/v1/chat/completions", {
 method: "POST",
 // Set the request headers, including the authorization, using the API key.
 headers: {
   Authorization: "Bearer " + OPENAI_API_KEY, // Replace OPENAI_API_KEY with the actual API key.
   "Content-Type": "application/json",
 },
 // Convert the API request body object into a JSON string and send it as the request body.
 body: JSON.stringify(apiRequestBody),
})
 // Once the API response is received, convert it to JSON format.
 .then((data) => {
   return data.json();
 })
 // After converting to JSON, extract the chatbot's response message from the API response.
 .then((data) => {
   // Update the chat messages.
   setChatMessages([
     ...messages,
     {
       message: data.choices[0].message.content,
       sender: "ChatGPT",
     },
   ]);
 });

Note: Remember to include a space after “Bearer” in the Authorization header; otherwise, API calls may fail.

We can now call the processUserMessageToChatGPT function in the handleUserMessage function.

await processUserMessageToChatGPT(updatedChatMessages);

Managing loading states while waiting for the API response

We can set a typing indicator to display while the chatbot is processing a response. Firstly, we’ll create a state to indicate typing and set it to false.

// State to manage the typing indicator of the chatbot
const [isChatbotTyping, setIsChatbotTyping] = useState(false);

In the handleUserMessage function, you can set the indicator to true. This line should be added before calling the processUserMessageToChatGPT function.

// Set the typing indicator for the chatbot
setIsChatbotTyping(true);

Once the response has been received from ChatGPT, within the processUserMessageToChatGPT function, you can set the state to false after updating the chat messages.

// Set the typing indicator to false after getting the response
setIsChatbotTyping(false);

You can display the indicator in the UI when it’s true by utilizing the typingIndicator property.

 // Display a typing indicator when the chatbot is processing a response.
 typingIndicator={
   isChatbotTyping ?  : null
 }
>
 {/* Map through chat messages and render each message */}
 {chatMessages.map((message, i) => {
   return (
     // Render each individual chat message as a  component.
            key={i}
       model={message}
       // Add additional styling to align the chatbot's response to the left.
       style={message.sender === "ChatGPT" ? { textAlign: "left" } : {}}
     />
   );
 })}
;

The Final App.jsx file should look like this:

import { useState } from "react";
import reactLogo from "./assets/react.svg";
import viteLogo from "/vite.svg";
import "./App.css";
import "@chatscope/chat-ui-kit-styles/dist/default/styles.min.css";
import {
 MainContainer,
 ChatContainer,
 MessageList,
 Message,
 MessageInput,
 TypingIndicator,
} from "@chatscope/chat-ui-kit-react";

const OPENAI_API_KEY = "YOUR API KEY";

function App() {
 // State to manage the typing indicator of the chatbot
 const [isChatbotTyping, setIsChatbotTyping] = useState(false);

 // State to store chat messages
 const [chatMessages, setChatMessages] = useState([
   {
     message: "Hello, I am ChatGPT!",
     sender: "ChatGPT",
   },
 ]);

 // Function to handle user messages
 const handleUserMessage = async (userMessage) => {
   // Create a new user message object
   const newUserMessage = {
     message: userMessage,
     sender: "user",
     direction: "outgoing",
   };

   // Update chat messages state with the new user message
   const updatedChatMessages = [...chatMessages, newUserMessage];
   setChatMessages(updatedChatMessages);

   // Set the typing indicator for the chatbot
   setIsChatbotTyping(true);

   // Process user message with ChatGPT
   await processUserMessageToChatGPT(updatedChatMessages);
 };

 // Function to send the user message to ChatGPT API
 async function processUserMessageToChatGPT(messages) {
   // Prepare the messages in the required format for the API
   let apiMessages = messages.map((messageObject) => {
     let role = "";
     if (messageObject.sender === "ChatGPT") {
       role = "assistant";
     } else {
       role = "user";
     }
     return { role: role, content: messageObject.message };
   });

   // System message for ChatGPT
   const systemMessage = {
     role: "system",
     content: "Explain all concept like a Professor in Biochemistry",
   };

   // Prepare the API request body
   const apiRequestBody = {
     model: "gpt-3.5-turbo",
     messages: [
       systemMessage, // System message should be in front of user messages
       ...apiMessages,
     ],
   };

   // Send the user message to ChatGPT API
   await fetch("https://api.openai.com/v1/chat/completions", {
     method: "POST",
     headers: {
       Authorization: "Bearer " + OPENAI_API_KEY,
       "Content-Type": "application/json",
     },
     body: JSON.stringify(apiRequestBody),
   })
     .then((data) => {
       return data.json();
     })
     .then((data) => {
       // Update chat messages with ChatGPT's response
       setChatMessages([
         ...messages,
         {
           message: data.choices[0].message.content,
           sender: "ChatGPT",
         },
       ]);
       // Set the typing indicator to false after getting the response
       setIsChatbotTyping(false);
     });
 }

 return (
   <>
     {/* A container for the chat window */}
     
       
         
           {/* Display chat messages and typing indicator */}
                        typingIndicator={
               isChatbotTyping ? (
                 
               ) : null
             }
           >
             {/* Map through chat messages and render each message */}
             {chatMessages.map((message, i) => {
               return (
                                    key={i}
                   model={message}
                   style={
                     message.sender === "ChatGPT" ? { textAlign: "left" } : {}
                   }
                 />
               );
             })}
           
           {/* Input field for the user to type messages */}
                        placeholder="Type Message here"
             onSend={handleUserMessage}
           />
         
       
     

   
 );
}

export default App;

Your AI ChatBot, with its full functionality, is now complete.

Common Errors and How to Fix Them

Errors may occur during the installation of the chat-ui-kit-react library. You may encounter errors such as:

npm ERR! code 1
npm ERR! path C:\Users\work\Documents\vs code\app\node_modules\esbuild
npm ERR! command failed
npm ERR! command C:\Windows\system32\cmd.exe /d /s /c node install.js
npm ERR! node:child_process:828
npm ERR!     err = new Error(msg);
npm ERR!           ^
npm ERR!
npm ERR! Error: Command failed: C:\Program Files\nodejs\node.exe

Here’s how you can resolve it:

Remove the node modules

rmdir /s /q node_modules

Install the latest npm

npm install -g npm@latest

Finally, reinstall the package

npm install @chatscope/chat-ui-kit-react

Errors may also occur when making requests to the API. This is the documentation on the meaning of the different errors you may encounter.

Conclusion

Setting up the development environment, Creating the chatbot user interface, and handling user messages using the ChatGPT API are vital steps in building an effective chatbot. With the power of AI, chatbots can significantly enhance user interactions and customer service in various industries.

So, go ahead and explore the world of AI chatbots with ChatGPT and React, and unlock new possibilities for seamless and interactive user engagements!

Build A ChatBot With ChatGPT And React was originally published in StackAnatomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

StackAnatomy - Medium

Forever Functional #39 — Workers and Promises

Forever Functional #39 — Workers and Promises

A sample worker

Using workers through messages

Using workers through promises

Using workers with a pool

Conclusion

Forever Functional #38 — Of maps and pipes, chains and nests, and more

Forever Functional #38 — Of maps and pipes, chains and nests, and more

Mapping for other types

Mapping functions

Maps as composition?

Maps as pipes

Conclusion

Forever Functional #40 — Better Error Handling with Monads (Part 1)

Forever Functional #40 — Better Error Handling with Monads (Part 1)

First Step: Defining Containers for all data types

Second Step: Adding more power by using Functors

Third (and last) Step: Get maximum flexibility by using Monads

Functions in monads

Conclusion

Forever Functional #41 — Better Error Handling with Monads (Part 2)

Forever Functional #41 — Better Error Handling with Monads (Part 2)

Null values: “The Billion Dollar Mistake”

Dealing with missing values: the MAYBE monad

Dealing with default values

A realistic example

Dealing with errors: the EITHER monad

Recovering from errors

Dealing with exceptions: the TRY monad

Dealing with future values: Promises

Conclusion

Further Reading

Forever Functional #37 — Can AI do that?

Forever Functional #37 — Can AI do that?

An old question

A simpler (?) question

A paradoxical limit

Conclusion

Forever Functional #36 — D.I.Y. Booleans?

Forever Functional #36 — D.I.Y. Booleans?

Writing our boolean operators

The “not” operator

The “or” operator

The “and” operator

Operators for circuit building

Other operators

Writing conditional statements

Writing our if statements

Writing a while loop

Conclusion

References

In the mood for some questions?

Forever Functional #34 — Maximize JavaScript’s Performance WITHOUT Transducers

Forever Functional #34 — Maximize JavaScript’s Performance WITHOUT Transducers

A first (but not too good) solution

A second (also handcrafted) solution

A third (and more general) solution

A fourth (and simpler) solution

The fifth (and definitive) solution

Summary

Forever Functional #33 — Complex Typing in TypeScript, Part 2

Forever Functional #33 — Complex Typing in TypeScript, Part 2

Checking types — the simple version

Checking types — the full version

Summary

Optimize Vue With Web Workers

Understanding Web Workers

Integrating Web Workers in Vue.js

Create the Worker File

Instantiate and Use the Worker in Your Main Application

Implement a web worker into Vue to create an image blur app

Post messages to the worker and listen for its response.

Demonstration in a Vue component

Clean up and terminate the worker

Benefits of Using Web Workers in Vue.js

Enhanced Performance and Scalability

Improved User Experience

Asynchronous Operations