>Yes, but that's beside the point. I said "style", not "paradigm". The basic structure, not the totality of the thing. I don't know what CS researchers would think of this distinction, but it seems convenient to have in practice.

CS researchers would say you don't know what you're talking about. Your "style" actually made things worse. You can follow the paradigm IN javascript and make your code more concise and better. Your points are true about writing an interpreter but they are not applicable in the javascript case and most cases as well. The CS term you are looking for is "Sugar". There is no sugar in javascript for compose thus it it slightly more awkward to do functional or concatenative programming in javascript than say haskell.

The pipeline operator is sugar for something that is close to compose... However it is still very convenient to simply define a compose function even without sugar for concatenative programming in javascript.

>You can use a functional style in Javascript without insisting on pure immutability throughout your entire project

Functional programming IS immutable programming the two are one and the same. Where it gets a little iffy is "pure" functional programming and "impure" functional programming. That's usually just referring to IO. Again, you don't know what you're talking about.

When you use the map or reduce you are not doing functional programming as a paradigm nor as a style. You're simply using a function. Map exists in functional programming as a higher order function, it also exists in procedural programming as a higher order function because Map can be implemented with a for loop which is a procedural primitive.

>The better option would've been not to use a stack at all, and illustrate it with integers, as you've done here. But you'd still need some way to manage multiple variables to use a concatenative idiom to compute 2x^y.

A stack isn't even relevant. You did nothing by introducing it except introducing how to do things in a more complicated way.

Dual parameters are handled in lambda calculus through currying. It's even easier in javascript as javascript supports recursion. Again you don't know what you are talking about.

  function timesTwo(x){
       return x * 2;
  }

  function xToYPower(x){
       function result(y){
            return y === 0? 1 : x*result(y-1);
       }
       return result
  }
  
  // ex: 3^2 ===> xToYPower(3)(2)
 
  function compose2(g, h){
       return x => g(h(x));
  }

  const x = 3;
  const y = 5;
  console.log(compose2(times2, xToYPower(x))(y))
  //2*(3^5)

  // pipeline syntax shown below; 
  //my mistake in the earlier comment, I thought pipeline was the 
  // compose operator. It is not... it is actually the apply operator. Which with a 
  //little modification can be used as compose or similarly to compose. 
  
  console.log(y |> xToYPower(x) |> timesTwo);

See? Concatenative programming in javascript. And it's not less convenient.

Haskell is the idiomatic language for typed functional/concatenative programming. This is what it looks like:

  timesTwo :: Int -> Int
  timesTwo x = 2 * x

  xToTheY :: Int -> Int -> Int
  xToTheY _ 0 = 1
  xToTheY x y = x * (xToTheY (y - 1))

  result = let x = 3
               y = 5
             in (timesTwo . (xToTheY x))(y)
  
  main = println result

  // - the "." is the compose operator. It is this operator that spawns the name
  //     "point free programming" and is the main "sugar" feature used for 
  //      concatenative programming
  // - haskell curries functions with multiple parameters automatically, hence 
  //      (xToTheY x) returns a function that that accepts y and will apply y to x 
  //      to get x^y. 

which is essentially the same thing just with more "sugar" but you can see that it's not a huge step up from javascript.

> It would be possible to rewrite that code to use an immutable stack, but for the purpose of illustration - specifically, illustrating that there isn't currently a good way to write in a concatenative style in Javascript

There is a good way, like I just showed you above. It's not that far from haskell which is THE definitive language for these styles of programming.

I'm not even an advocate for javascript. (TBH I ate the language). So you can see here that what I'm saying is unbiased.

>Not a bootcamper - even worse, I work in a warehouse

Don't worry it's not worse. It's the same. Bootcamps literally teach you everything you can get off the internet in a very superficial way. Anyone can learn javascript bootcamp or not. Get better and get off javascript.