Hacker News new | past | comments | ask | show | jobs | submit login

>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.




>Functional programming IS immutable programming the two are one and the same.

Yes, and many imperative languages allow you to use, in an idiomatic manner, a functional style that avoids mutable state, even though these languages aren't designed around the functional paradigm, and don't require you to adhere purely, in the colloquial sense that means "strictly" or "completely" but has fewer letters, to it. And the reason for this is that people have taken ideas from languages that were designed to be functional rather than imperative.

If you want to bring up map and reduce, what's their genealogy? Did the imperative world get the idea from ALGOL? Maybe they did, but I'd be surprised.

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

It still isn't great. To avoid stepping outside the paradigm, you have to be willing to curry every function that needs multiple parameters. And I don't know what that recursion is doing there - presumably I don't know what I'm talking about again, but it seems to me that the entire body of `xToYPower` could be replaced with `return y => x y`.


>If you want to bring up map and reduce, what's their genealogy? Did the imperative world get the idea from ALGOL? Maybe they did, but I'd be surprised.

Genealogy is that it's a pattern from the functional world. It's usually unused in procedural languages because they have special syntax for it like the for loop. However there is no restriction to implement map using a for loop. Therefore it is not part of the paradigm similar to how using functions in a procedural language does not mean you are doing functional programming from a stylistic perspective.

>To avoid stepping outside the paradigm, you have to be willing to curry every function that needs multiple parameters

For compose yes you are correct, it has to be done.

>And I don't know what that recursion is doing there

The recursion is doing x^y. That is the meaning of the function name.

  2^3 = 8
  3^2 = 9
  xToY(2)(3) = 8
  xToY(3)(2) = 9
>but it seems to me that the entire body of `xToYPower` could be replaced with `return y => x y`

x y with a space inbetween looks like a syntax error. I don't think it will even run.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: