DEV Community: Jon Randy 🎖️

JavaScript Abuse: Pipelining Functions

Jon Randy 🎖️ — Thu, 09 Jul 2026 08:09:04 +0000

DISCLAIMER: Do NOT use this in production code. It's just a fun idea (full of potential danger) that could lead to something more useful...

Okay, so we're going to make the following JS code work, even though it doesn't look like it should:

const addOne = x => x + 1
const half = x => x / 2
const result = addOne[half][Math.floor](4)
console.log(result) // 2

const nums = [3, 4, 5]
console.log(nums.map(half[addOne])) // [2.5, 3, 3.5]

How? Through the magic of JS features that you:

Have always been told (weirdly) to avoid: type coercion
Know about, but can't think of a use for: Symbols

Regular viewers who've seen previous episodes such as 'Metho', 'Turboprop', and 'Ranger' will probably have a fairly good idea of how we're going to achieve this...

The Goal

For the pipelining to work, essentially all we need is to make the following true:

f[g] = x => g(f(x))

For ANY two functions f and g:
- The function f must have a method named with g.
- That method should be another function that is g composed with f.

If we can achieve this, we can essentially make a pipeline of as many functions as we like.

The Solution

Below is one way to achieve what we want. Please ask in the comments if there's anything you don't understand:

// JS will attempt to coerce a function to a string when
// we attempt to use it as a property accessor on another function.
// We can hijack that process to perform our magic

Function.prototype[Symbol.toPrimitive] = function (hint) {
  // retain as much 'normal' coercion behaviour as we can
  if (hint === "number") return NaN
  if (hint === "default") return this.toString()

  // store a reference to the function being coerced - for later use
  const fn = this

  // create a unique symbol to use as the method key
  const token = Symbol()

  // create a unique method on the Function prototype
  Object.defineProperty(Function.prototype, token, {
    configurable: true,
    // use a getter so we have access to the target function (this)
    // when creating the method to return
    get() {
      // remove the method when used - single use only
      delete Function.prototype[token]
      // the method itself - our composed function x => g(f(x))
      return x => fn(this(x))
    }
  })

  // self cleanup for stray tokens left behind from coercions
  // that could occur outside of an intended pipeline
  queueMicrotask(() => {
    delete Function.prototype[token]
  })

  // return the symbol we 'named' the method with - so it is
  // immediately invoked
  return token
}

References (MDN):

Why is This Dangerous?

This is obviously dangerous and/or flaky for a number of reasons:

We're adding properties to language-level prototypes. This is generally a pretty bad idea, but we're adding properties keyed with Symbols so not risking collisions. However, there's still no guarantee this will not cause issues.
Anything relying on coercion of functions to string primitives could well be trashed as we've modified the standard behaviour.
It's not optimised - many identical functions will be recreated again and again.
It will almost certainly have issues pipelining functions that use this, although I'm not even sure what functionality one would expect in that case.

How Could it be Made Safer/Better?

The main way it could be made safer would probably be to mark or subclass pipelineable functions in some way - so that we could leave standard function behaviour intact. The problem with this is that we'd probably lose the nice syntax or, at the very least, end up with something less elegant.

A way to improve it might be to assign the intermediate functions meaningful names constructed from the names of the pipelined functions - might be nice in stack traces.

Why do this?

Why not? 😀

Far too many Packers and Packer-type thinking in software development and education. We need more Mappers! Which are you? #webdev #softwaredevelopment #programming https://beautiful-programmers-stone.netlify.app/chapter-1#mappers-and-packers

Jon Randy 🎖️ — Sun, 28 Jun 2026 06:35:09 +0000

beautiful-programmers-stone.netlify.app

Function Names in JS Can't Contain Spaces, Right?

Jon Randy 🎖️ — Wed, 24 Jun 2026 11:28:13 +0000

WRONG!

Despite the widespread belief that function names in JavaScript MUST follow the same rules as identifiers - this is not actually true. Sure, when you use the function keyword to define a function then the name you give in the code must follow the naming rules for identifiers i.e. cannot start with a number, cannot contain spaces, can only use certain characters etc. However, it IS perfectly possible for the name of the function to contain spaces - or any other character. A function's name can actually be ANY string at all.

OK... Explain?

When you use the function keyword, the name you provide is used as the function's identifier and is ALSO used to set the name property of the created function - i.e. the function's name. That identifier is then used (scoped) in one of two ways depending on whether you are doing function declaration or function expression. The important thing here is that the function's identifier and the function's name happen to be the same, but are actually two different things. The fact that the language syntax mandates an identifier name here means that most of the time the function's name appears to be following the same rules... but it doesn't have to! There are other ways to set the name of a function:

Using Object.defineProperty - AFTER function creation A function's name property is defined with { writable: false, configurable: true} - so we cannot set it directly by assigning our value to the property, but we can define it as follows:

  function myFunc() {}
  Object.defineProperty(myFunc, 'name', { value: 'my custom name 😛'})
  console.log(myFunc.name) // 'my custom name 😛'

Using a property name trick - DURING function creation We can set the name at creation time without a separate step by use a computed property name trick, which leverages how JS infers names for object methods and functions:

  const name = 'my dynamic 🎉 name';
  const fn = { [name]: function() {} }[name];
  console.log(fn.name); // "my dynamic 🎉 name"

But This is Just a Trick That's Useless?

You might think that, but it's actually used in many libraries - usually for making nice names to appear in stack traces (most modern JS engines will use a function's name property to refer to the function).

Oh, and JavaScript actually already makes functions with names containing spaces... and you've probably already used this feature without knowing it:

function myFunc() {
    console.log('Hello')
}
const func2 = myFunc.bind({})

console.log(myFunc.name) // 'myFunc'
console.log(func2.name) // 'bound myFunc'

Yes, a function created by using bind has a name containing a space.

The most interesting and fun projects to build are always the one ones with little to no practical use, and I thoroughly recommend building them 👍

Jon Randy 🎖️ — Fri, 01 Aug 2025 16:36:59 +0000

"We are destroying software" - https://antirez.com/news/145

Jon Randy 🎖️ — Thu, 13 Feb 2025 02:18:35 +0000

@ben The spam is still bad on the site. Any progress on solving this?

Jon Randy 🎖️ — Wed, 22 Jan 2025 11:15:40 +0000

Don't do this. Please. It's going to be even harder to discover decent content on here 😞

Jon Randy 🎖️ — Wed, 13 Nov 2024 00:56:55 +0000

LLMs are Bullshitters 🐮💩

Jon Randy 🎖️ — Sat, 15 Jun 2024 07:17:13 +0000

Just read a great paper on LLMs. I strongly suggest reading it, but here's the conclusion:

Investors, policymakers, and members of the general public make decisions on how to treat these machines and how to react to them based not on a deep technical understanding of how they work, but on the often metaphorical way in which their abilities and function are communicated. Calling their mistakes ‘hallucinations’ isn’t harmless: it lends itself to the confusion that the machines are in some way misperceiving but are nonetheless trying to convey something that they believe or have perceived. This, as we’ve argued, is the wrong metaphor. The machines are not trying to communicate something they believe or perceive. Their inaccuracy is not due to misperception or hallucination. As we have pointed out, they are not trying to convey information at all. They are bullshitting.

Calling chatbot inaccuracies ‘hallucinations’ feeds in to overblown hype about their abilities among technology cheerleaders, and could lead to unnecessary consternation among the general public. It also suggests solutions to the inaccuracy problem which might not work, and could lead to misguided efforts at AI alignment amongst specialists. It can also lead to the wrong attitude towards the machine when it gets things right: the inaccuracies show that it is bullshitting, even when it’s right. Calling these inaccuracies ‘bullshit’ rather than ‘hallucinations’ isn’t just more accurate (as we’ve argued); it’s good science and technology communication in an area that sorely needs it.

ChatGPT is bullshit | Ethics and Information Technology

Recently, there has been considerable interest in large language models: machine learning systems which produce human-like text and dialogue. Applications of these systems have been plagued by persistent inaccuracies in their output; these are often called “AI hallucinations”. We argue that these falsehoods, and the overall activity of large language models, is better understood as bullshit in the sense explored by Frankfurt (On Bullshit, Princeton, 2005): the models are in an important way indifferent to the truth of their outputs. We distinguish two ways in which the models can be said to be bullshitters, and argue that they clearly meet at least one of these definitions. We further argue that describing AI misrepresentations as bullshit is both a more useful and more accurate way of predicting and discussing the behaviour of these systems.

link.springer.com

One Byte Explainer: Recursion

Jon Randy 🎖️ — Thu, 13 Jun 2024 07:52:02 +0000

This is a submission for DEV Computer Science Challenge v24.06.12: One Byte Explainer.

Explainer

To understand recursion, see here.

How to Calculate the Nth Fibonacci Number

Jon Randy 🎖️ — Wed, 03 Apr 2024 08:50:27 +0000

Okay, lets dive straight into the code...

const fib = n =>
  Math.floor((((1 + 5**.5)/2)**n - ((1 - 5**.5)/2)**n)/5**.5)

Explanation here.

The Rise of Tech Bloggers Relying on Generative AI

Jon Randy 🎖️ — Wed, 14 Feb 2024 06:27:02 +0000

In the ever-evolving landscape of online content creation, the utilization of generative AI has become increasingly prevalent, especially among tech bloggers. These bloggers, driven by various motivations, are turning to AI to automate the process of generating articles without thoroughly reviewing or fact-checking the content. While some may view this trend as a shortcut or an attempt to keep up with the fast-paced nature of digital media, it raises questions about the integrity and authenticity of information shared within the tech community.

The allure of using generative AI for content creation is multifaceted. For some, it boils down to sheer laziness. The convenience of inputting a few prompts and receiving a fully-formed article within minutes can be irresistible, particularly when faced with deadlines or a lack of motivation. In a world where time is of the essence, the appeal of cutting corners can be tempting, albeit at the expense of quality and accuracy.

Furthermore, peer pressure plays a significant role in motivating tech bloggers to embrace AI-generated content. In an era where online presence and engagement metrics reign supreme, bloggers may feel compelled to churn out content at a rapid pace to maintain relevance and visibility within their respective communities. The fear of being left behind or overshadowed by competitors drives many to adopt AI as a means of keeping up with the relentless demand for fresh content.

Moreover, there's an underlying reluctance among some bloggers to admit their own limitations or gaps in knowledge. By relying on generative AI, they can mask their deficiencies and project an image of expertise without investing the time and effort required for in-depth research and analysis. This desire to maintain a facade of competence, coupled with the pressure to produce content consistently, leads many bloggers down the path of AI reliance, regardless of the ethical implications.

However, the consequences of this trend extend beyond individual motivations. The unchecked proliferation of AI-generated content poses a threat to the credibility and reliability of information disseminated within the tech community. Articles produced without human oversight are prone to errors, inaccuracies, and biases inherent in the training data used by the AI models. As a result, readers are exposed to misinformation that can perpetuate misconceptions, mislead decision-making, and erode trust in online sources.

In response to these concerns, it's essential for tech bloggers to exercise responsibility and diligence in their content creation processes. While AI can be a valuable tool for streamlining workflows and enhancing productivity, it should never serve as a substitute for human judgment and critical thinking. Bloggers must prioritize quality over quantity, taking the time to review and verify the accuracy of their content before publishing it for public consumption.

Furthermore, transparency is paramount in maintaining trust and credibility with audiences. Bloggers who leverage AI should disclose their use of automated tools and acknowledge the limitations inherent in AI-generated content. By being open and honest about their processes, bloggers can foster a culture of accountability and integrity within the tech blogging community.

Ultimately, the decision to rely on generative AI for content creation is a reflection of broader societal trends towards automation and digitalization. While the allure of efficiency and convenience may be enticing, it's imperative for tech bloggers to uphold ethical standards and prioritize the accuracy and integrity of the information they share. By doing so, they can ensure that their contributions to the tech discourse are meaningful, impactful, and worthy of audience trust and respect.

...and, yes - #abotwrotethis

😉

Misconceptions About Closures

Jon Randy 🎖️ — Wed, 27 Sep 2023 06:38:09 +0000

The two biggest (and unfortunately widespread) misconceptions about closures:

A closure is a special type of function that has access to its surrounding scope ❌

This is entirely wrong for two reasons:

Closures are not functions
ALL functions have access to their surrounding (lexical) scope*

To create a closure, you need to nest functions ❌

Again, entirely wrong - nesting of functions is irrelevant! Whenever a function is created, an associated closure is also created.

So, what is a closure?

From MDN:

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state

The closure allows the function to access the state in which it was created.

As a simplified visual:

*Except for functions created with new Function(...) which form closures with the global scope