What's declarative about telling the machine to transform a sequence into another sequence by applying a procedure to each element?
What's declarative about telling the machine to compute a value from a sequence by iteratively applying a procedure to each element and the value computed so far?
map and reduce aren't function -- they're just higher order operations -- that is operations parameterized by operations.
In the case of javascript, these operations are procedures, making them higher order procedures, rather than higher order functions.
Higher order operations are often used in functional programming styles, but that's because they're convenient, not because they're fundamentally functional programming mechanisms.
Javascript is a procedural language with a generally imperative style of expression.
Declarations in javascript are pretty well limited to variable, function, import and export declarations.
map and reduce aren't function -- they're just higher order operations -- that is operations parameterized by operations.
In the case of javascript, these operations are procedures, making them higher order procedures, rather than higher order functions.
So what do you consider to be the difference between a function and an operation? And a procedure is usually defined as a series of statements that do not return anything. Map and reduce obviously return something.
Higher order operations are often used in functional programming styles, but that's because they're convenient, not because they're fundamentally functional programming mechanisms.
Oh but they are fundamentally functional. Lambda calculus, the very base of functional programming, works by treating everything as a function. Defining anything useful in lambda calculus requires higher order functions. And in untyped lambda calculus everything is a higher-order fuction. :)
JavaScript is considered a multi-paradigm language. Although it's imperative-first it is very much possible writing in the style of functional programming. Although I'm not very much into JavaScript myself, the amount of functional programming that JS developers use seem to have increased very much lately. There are many libraries for it as well, eg. Immutablejs, Rambda.
Operations encompass both functions and procedures.
A function is time-invariant.
Procedures are a series of operations over time, and may include flow-control mechanisms such as return.
I wrote 'higher order operations' rather than 'higher order functions' for a reason.
It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.
(But that's irrelevant, since your reference to lambda calculus came from confusing higher order operation with higher order function)
Certainly you can write procedures that implement functions in javascript -- I am not sure why this is relevant.
Operations encompass both functions and procedures.
A function is time-invariant.
I wrote 'higher order operations' rather than 'higher order functions' for a reason.
Regarding this, there seems to have been a miss on my part. When I was speaking of the functions map and reduce I didn't mean they had to be time-invariant (by time-invariant I assume you mean it follows the mathematical definition of a function, also known as pure or referentially transparent). The word "function" is used so widely in the programming world to just refer to what you call operation. When speaking of time-invariant functions the most common terminology is "pure function" (from what I have seen).
It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.
From what I understand it is a requirement. The lecture you linked was very interesting. I didn't understand all of it. But they use what they call I-structures and M-structures to isolate the side effects and keeping them pure. So in a similar manner to Haskell's IO Monad, but it's not a monad. Either way, it's not the kind of "do IO anywhere" that imperative languages have. Apparently this method should let them model languages with implicit parallelization and they used it to create the language pH (Parallel Haskell), not sure about the state of that language today since this is from the late '90s. But they also lose some benefits of regular lambda calculus when expanding it like that.
I feel like this discussion has reached a point where neither of us is making any progress in convincing the other, so I'm leaving this as my last comment and will not reply any further. Below I linked some more resources on lambda calculus and side effects that I read to get a better understanding of the lecture slides. It was very fun and interesting to read. So thanks for that.
I saw that the lecture you linked was the first result on Google for "lambda calculus side effects". It's not very comprehensive and was hard to understand. Here's a paper that covers some more basic parts first. cs.tufts.edu/~nr/cs257/archive/nea...
Here's the research paper which I believe the lecture is based off. I only read about half of the paper, but it helped me understand the lecture slides. reader.elsevier.com/reader/sd/pii/...
Both papers are by the same researchers and it was pretty much the only resources I found on side effects in lambda calculus.
What's declarative about telling the machine to transform a sequence into another sequence by applying a procedure to each element?
What's declarative about telling the machine to compute a value from a sequence by iteratively applying a procedure to each element and the value computed so far?
map and reduce aren't function -- they're just higher order operations -- that is operations parameterized by operations.
In the case of javascript, these operations are procedures, making them higher order procedures, rather than higher order functions.
Higher order operations are often used in functional programming styles, but that's because they're convenient, not because they're fundamentally functional programming mechanisms.
Javascript is a procedural language with a generally imperative style of expression.
Declarations in javascript are pretty well limited to variable, function, import and export declarations.
So what do you consider to be the difference between a function and an operation? And a procedure is usually defined as a series of statements that do not return anything. Map and reduce obviously return something.
Oh but they are fundamentally functional. Lambda calculus, the very base of functional programming, works by treating everything as a function. Defining anything useful in lambda calculus requires higher order functions. And in untyped lambda calculus everything is a higher-order fuction. :)
JavaScript is considered a multi-paradigm language. Although it's imperative-first it is very much possible writing in the style of functional programming. Although I'm not very much into JavaScript myself, the amount of functional programming that JS developers use seem to have increased very much lately. There are many libraries for it as well, eg. Immutablejs, Rambda.
Operations encompass both functions and procedures.
A function is time-invariant.
Procedures are a series of operations over time, and may include flow-control mechanisms such as return.
I wrote 'higher order operations' rather than 'higher order functions' for a reason.
It's true that lambda calculus is generally functional, but it's not fundamentally required to be so -- consider web.mit.edu/6.827/www/old/lectures... for example.
(But that's irrelevant, since your reference to lambda calculus came from confusing higher order operation with higher order function)
Certainly you can write procedures that implement functions in javascript -- I am not sure why this is relevant.
Regarding this, there seems to have been a miss on my part. When I was speaking of the functions
mapandreduceI didn't mean they had to be time-invariant (by time-invariant I assume you mean it follows the mathematical definition of a function, also known as pure or referentially transparent). The word "function" is used so widely in the programming world to just refer to what you call operation. When speaking of time-invariant functions the most common terminology is "pure function" (from what I have seen).From what I understand it is a requirement. The lecture you linked was very interesting. I didn't understand all of it. But they use what they call I-structures and M-structures to isolate the side effects and keeping them pure. So in a similar manner to Haskell's IO Monad, but it's not a monad. Either way, it's not the kind of "do IO anywhere" that imperative languages have. Apparently this method should let them model languages with implicit parallelization and they used it to create the language pH (Parallel Haskell), not sure about the state of that language today since this is from the late '90s. But they also lose some benefits of regular lambda calculus when expanding it like that.
I feel like this discussion has reached a point where neither of us is making any progress in convincing the other, so I'm leaving this as my last comment and will not reply any further. Below I linked some more resources on lambda calculus and side effects that I read to get a better understanding of the lecture slides. It was very fun and interesting to read. So thanks for that.
I saw that the lecture you linked was the first result on Google for "lambda calculus side effects". It's not very comprehensive and was hard to understand. Here's a paper that covers some more basic parts first.
cs.tufts.edu/~nr/cs257/archive/nea...
Here's the research paper which I believe the lecture is based off. I only read about half of the paper, but it helped me understand the lecture slides.
reader.elsevier.com/reader/sd/pii/...
Both papers are by the same researchers and it was pretty much the only resources I found on side effects in lambda calculus.
That's fine.
I suggest that you go back over the thread and look at the places where your positions have been self-inconsistent, as it may be educational.
Best of luck.