Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #32225 > unrolled thread

Two quick question regarding FP (Functional Programming)

Back to article view | Back to comp.lang.javascript

Contents

  Two quick question regarding FP (Functional Programming) justaguy <lichunshen84@gmail.com> - 2017-01-20 19:00 -0800
    Re: Two quick question regarding FP (Functional Programming) Scott Sauyet <scott@sauyet.com> - 2017-01-21 19:16 +0000
      Re: Two quick question regarding FP (Functional Programming) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-21 14:43 -0800
        Re: Two quick question regarding FP (Functional Programming) justaguy <lichunshen84@gmail.com> - 2017-01-21 18:04 -0800
          Re: Two quick question regarding FP (Functional Programming) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-21 22:06 -0800
            Re: Two quick question regarding FP (Functional Programming) justaguy <lichunshen84@gmail.com> - 2017-01-22 06:32 -0800
              Re: Two quick question regarding FP (Functional Programming) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-22 11:58 -0800
            Re: Two quick question regarding FP (Functional Programming) "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-01-22 22:31 +0100
              Re: Two quick question regarding FP (Functional Programming) Scott Sauyet <scott.sauyet@gmail.com> - 2017-01-25 18:22 -0800
                Re: Two quick question regarding FP (Functional Programming) "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-01-26 12:19 +0100
                  Re: Two quick question regarding FP (Functional Programming) Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-01-26 12:51 +0100
      Re: Two quick question regarding FP (Functional Programming) justaguy <lichunshen84@gmail.com> - 2017-01-21 18:03 -0800
        Re: Two quick question regarding FP (Functional Programming) "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2017-01-22 11:06 -0800

#32225 — Two quick question regarding FP (Functional Programming)

Based on Scott Sauyet's recommendation of two books, I've started to read "Mostly Adequate Guide", now, I have two questions.
(a) Is there something sort of online library that you can simply point to tools for FP such as lodash?  If so, for one thing, one does not need to install them.
(b) In his chapter 5 about Composition, he claimed FP has the advantage of "Pointfree" vs. "Not Pointfree" but the example he quoted seems to suggest, the latter actually is easier to read, I really don't see its benefit and maybe because I don't know FP. Besides, he also added, "Pointfree" is a double-edged sword.  Your thoughts?

In addition, I'm dying to take a look at some FP JavaScript code that effectively solves some REAL world problem. To me, this type of learning is most impactful.

Thanks.

[toc] | [next] | [standalone]

#32239

justaguy wrote:

> Based on Scott Sauyet's recommendation of two books, I've started to
> read "Mostly Adequate Guide", now, I have two questions.

> (a) Is there something sort of online library that you can simply point
> to tools for FP such as lodash?  If so, for one thing, one does not need
> to install them.

Almost any such library with a certain level of maturity will document 
how you can install them or use them through CDNs.  Lodash's download 
section [1] points to one CDN, but it is available on others.  Ramda's 
installation section [2] points to two, but it's also available on 
others.  This is partly because some CDNs (for instance wzrd [3]) auto-
publish Node modules on CDNs.  If you're using them on the server side in 
Node.js, then these will all be available with an `npm install` and a 
`require('library-name')`.


> (b) In his chapter 5 about Composition, he claimed FP has the advantage
> of "Pointfree" vs. "Not Pointfree" but the example he quoted seems to
> suggest, the latter actually is easier to read, I really don't see its
> benefit and maybe because I don't know FP. Besides, he also added,
> "Pointfree" is a double-edged sword.  Your thoughts?

Let's assume you understand the meanings of `map`, a function, which for 
our purposes transforms one list to another by applying a function to 
each member, and `square`, a function which transforms one number to 
another by multiplying it by itself.  Now you need a function which 
transforms a list of of numbers to another list of numbers by squaring 
each member.  You could write it like this:

    function squareAll(nbrs) {
      return map(square, nbrs)
    }

Or with the simplified arrow function syntax of ES2015:

    const squareAll = nbrs => map(square, nbrs)

A points-free version would look like this:

    const squareAll = map(square)

In the language Haskell, where function application is delineated not 
with parentheses but with space separation, and where declaration 
keywords like `const` are unnecessary, this would be written as

    squareAll = map square

That's extremely elegant; every token used adds meaning to the definition.

But the points-free Javascript is not too far off, adding only `const`, `
(`, and `)`.  If we look at the arrow-function version, we add a number 
of additional tokens on top of those: `nbrs`, `=>`, `,`, and `nbrs`, and 
the other version, while removing `const`, adds `function`, `(`, `nbrs`, 
`)`, `{`, `return`, `,`, `nbrs`, and `}`.  (Note that the "points" in 
"points-free" does not refer to all these tokens, but only to the uses of 
`nbr` in this case.)  

The main idea is that this points-free definition can often make it very 
clear what is going on without the distraction of names.  Was `nbrs` the 
right choice?  Should it be `list`?  `array`?  `nbrList`?  It is about 
how functions act on your data, not on the data itself, and especially 
not on what you choose to name that data in a particular instance.

This is not universally helpful, though.  As functions get more complex, 
using arrow functions for parts of your definitions may make them easier 
to understand.  There is no universal prescription.  Points-free coding 
is a useful tool to have in your toolbox.  The only thing it will grant 
you is additional readability.  If it's not doing that, then don't use it.


> In addition, I'm dying to take a look at some FP JavaScript code that
> effectively solves some REAL world problem. To me, this type of learning
> is most impactful.

I would suggest looking through some real-world projects that use such 
libraries then.  The NPM page for Ramda [4] has a list of other projects 
that are dependent upon it [5].  With 1800+ projects to look at, 
something there might interest you.  (Lodash has 20 times as many 
dependents, BTW, but lodash is mostly used in more imperative settings, 
so finding the places where its used in its functional guise might be 
more tricky.)  You might also look to the dependents for Sanctuary [6], 
which is related to Ramda, but takes a more principled stand.  However 
there are only a handful of such dependencies there.



  [1]: <https://lodash.com/#download-links>
  [2]: <http://ramdajs.com/#installation>
  [3]: <https://wzrd.in/>
  [4]: <https://www.npmjs.com/package/ramda>
  [5]: <https://www.npmjs.com/browse/depended/ramda>
  [6]: <https://www.npmjs.com/browse/depended/sanctuary>

[toc] | [prev] | [next] | [standalone]

#32241

Scott Sauyet wrote:
> justaguy wrote:
> > [...]
> > (b) In his chapter 5 about Composition, he claimed FP has the advantage
> > of "Pointfree" vs. "Not Pointfree" but the example he quoted seems to
> > suggest, the latter actually is easier to read, I really don't see its
> > benefit and maybe because I don't know FP. Besides, he also added,
> > "Pointfree" is a double-edged sword.  Your thoughts?

> [...]

> The main idea is that this points-free definition can often make it very 
> clear what is going on without the distraction of names.  Was `nbrs` the 
> right choice?  Should it be `list`?  `array`?  `nbrList`?  It is about 
> how functions act on your data, not on the data itself, and especially 
> not on what you choose to name that data in a particular instance.

About 5 years ago I was really big on this approach. This is a very large topic and I don't think I could do it justice in a short post. I've moved on from this style and paradigm for reasons I won't go into now (time constraints), but some of the resources that were useful for me at the time you can see below. There is more, but the general idea is that when you follow point-free style (Function-Level programming [4]) you tend to evolve towards a the idea of manipulating an ambient stack where the arguments reside, which leads you out of "Functional" as well as "Function-Level" programming and into what is referred to as "Concatenative" programming [5] or "Tacit" programming [6].

The community around these paradigms you can find here: 
<http://concatenative.org>

The group that (used to?) be active is here:

<https://groups.yahoo.com/neo/groups/concatenative/conversations/messages>

I don't know how long this will last though now that Yahoo has been sold...

[1] "An informal tutorial on Joy" <http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html>
[2] "Pointfree" <https://wiki.haskell.org/Pointfree>
[3] "Constructing a Calculus of Programs" <http://www.kestrel.edu/home/people/meertens/publications/papers/Constructing_a_calculus_of_programs.pdf>
[4] <https://en.wikipedia.org/wiki/Function-level_programming>
[5] <https://en.wikipedia.org/wiki/Concatenative_programming_language>
[6] <https://en.wikipedia.org/wiki/Tacit_programming>

[toc] | [prev] | [next] | [standalone]

#32249

On Saturday, January 21, 2017 at 5:43:50 PM UTC-5, Michael Haufe (TNO) wrote:
> Scott Sauyet wrote:
> > justaguy wrote:
> > > [...]
> > > (b) In his chapter 5 about Composition, he claimed FP has the advantage
> > > of "Pointfree" vs. "Not Pointfree" but the example he quoted seems to
> > > suggest, the latter actually is easier to read, I really don't see its
> > > benefit and maybe because I don't know FP. Besides, he also added,
> > > "Pointfree" is a double-edged sword.  Your thoughts?
> 
> > [...]
> 
> > The main idea is that this points-free definition can often make it very 
> > clear what is going on without the distraction of names.  Was `nbrs` the 
> > right choice?  Should it be `list`?  `array`?  `nbrList`?  It is about 
> > how functions act on your data, not on the data itself, and especially 
> > not on what you choose to name that data in a particular instance.
> 
> About 5 years ago I was really big on this approach. This is a very large topic and I don't think I could do it justice in a short post. I've moved on from this style and paradigm for reasons I won't go into now (time constraints), but some of the resources that were useful for me at the time you can see below. There is more, but the general idea is that when you follow point-free style (Function-Level programming [4]) you tend to evolve towards a the idea of manipulating an ambient stack where the arguments reside, which leads you out of "Functional" as well as "Function-Level" programming and into what is referred to as "Concatenative" programming [5] or "Tacit" programming [6].
> 
> The community around these paradigms you can find here: 
> <http://concatenative.org>
> 
> The group that (used to?) be active is here:
> 
> <https://groups.yahoo.com/neo/groups/concatenative/conversations/messages>
> 
> I don't know how long this will last though now that Yahoo has been sold...
> 
> [1] "An informal tutorial on Joy" <http://www.kevinalbrecht.com/code/joy-mirror/j01tut.html>
> [2] "Pointfree" <https://wiki.haskell.org/Pointfree>
> [3] "Constructing a Calculus of Programs" <http://www.kestrel.edu/home/people/meertens/publications/papers/Constructing_a_calculus_of_programs.pdf>
> [4] <https://en.wikipedia.org/wiki/Function-level_programming>
> [5] <https://en.wikipedia.org/wiki/Concatenative_programming_language>
> [6] <https://en.wikipedia.org/wiki/Tacit_programming>

"About 5 years ago I was really big on this approach.", is there any change of heart at present?

[toc] | [prev] | [next] | [standalone]

#32251

justaguy wrote:

> "About 5 years ago I was really big on this approach.", is there any change of heart at present?

Yes.

[toc] | [prev] | [next] | [standalone]

#32252

On Sunday, January 22, 2017 at 1:07:01 AM UTC-5, Michael Haufe (TNO) wrote:
> justaguy wrote:
> 
> > "About 5 years ago I was really big on this approach.", is there any change of heart at present?
> 
> Yes.

If you don't mind my asking, why?

[toc] | [prev] | [next] | [standalone]

#32257

justaguy wrote:
Michael Haufe (TNO) wrote:
> > justaguy wrote:
> > 
> > > "About 5 years ago I was really big on this approach.", is there any change of heart at present?
> > 
> > Yes.
> 
> If you don't mind my asking, why?

Basically I came to the same conclusions as discussed by Anton van Straaten [1] plus some others relating to perspective. This is all off-topic for the group though, so I don't want to continue down that rabbit hole in this context, unless someone is willing to come up with a way to relate it to JS more directly...



[1] <http://lambda-the-ultimate.org/node/900#comment-8723>

[toc] | [prev] | [next] | [standalone]

#32258

"Michael Haufe (TNO)" <tno@thenewobjective.com> wrote on 22 Jan 2017 in
comp.lang.javascript: 

> justaguy wrote:
> 
>> "About 5 years ago I was really big on this approach.", is there any
>> change of heart at present? 
> 
> Yes.

Still do not understand what is so "quick" about these questions. 



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32352

Evertjan wrote:

> Still do not understand what is so "quick" about these questions. 

No one said the *answers* were quick!

  -- Scott

[toc] | [prev] | [next] | [standalone]

#32353

Scott Sauyet <scott.sauyet@gmail.com> wrote on 26 Jan 2017 in 
comp.lang.javascript:

> Evertjan wrote:
> 
>> Still do not understand what is so "quick" about these questions. 
> 
> No one said the *answers* were quick!

Quite, but ...

I still do not understand what is so "quick" about these questions.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#32354

On 26/01/2017 12:19, Evertjan. wrote:
> Scott Sauyet <scott.sauyet@gmail.com> wrote on 26 Jan 2017 in
> comp.lang.javascript:
>
>> Evertjan wrote:
>>
>>> Still do not understand what is so "quick" about these questions.
>>
>> No one said the *answers* were quick!
>
> Quite, but ...
>
> I still do not understand what is so "quick" about these questions.

My understanding of using "quick" in a question is that I am expecting a 
short answer. Sometimes I want to be sure if I am on a right path before 
I dig deeper. But that's me.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/ - Accessibility linting tool

[toc] | [prev] | [next] | [standalone]

#32248

On Saturday, January 21, 2017 at 2:18:16 PM UTC-5, Scott Sauyet wrote:
> justaguy wrote:
> 
> > Based on Scott Sauyet's recommendation of two books, I've started to
> > read "Mostly Adequate Guide", now, I have two questions.
> 
> > (a) Is there something sort of online library that you can simply point
> > to tools for FP such as lodash?  If so, for one thing, one does not need
> > to install them.
> 
> Almost any such library with a certain level of maturity will document 
> how you can install them or use them through CDNs.  Lodash's download 
> section [1] points to one CDN, but it is available on others.  Ramda's 
> installation section [2] points to two, but it's also available on 
> others.  This is partly because some CDNs (for instance wzrd [3]) auto-
> publish Node modules on CDNs.  If you're using them on the server side in 
> Node.js, then these will all be available with an `npm install` and a 
> `require('library-name')`.
> 
> 
> > (b) In his chapter 5 about Composition, he claimed FP has the advantage
> > of "Pointfree" vs. "Not Pointfree" but the example he quoted seems to
> > suggest, the latter actually is easier to read, I really don't see its
> > benefit and maybe because I don't know FP. Besides, he also added,
> > "Pointfree" is a double-edged sword.  Your thoughts?
> 
> Let's assume you understand the meanings of `map`, a function, which for 
> our purposes transforms one list to another by applying a function to 
> each member, and `square`, a function which transforms one number to 
> another by multiplying it by itself.  Now you need a function which 
> transforms a list of of numbers to another list of numbers by squaring 
> each member.  You could write it like this:
> 
>     function squareAll(nbrs) {
>       return map(square, nbrs)
>     }
> 
> Or with the simplified arrow function syntax of ES2015:
> 
>     const squareAll = nbrs => map(square, nbrs)
> 
> A points-free version would look like this:
> 
>     const squareAll = map(square)
> 
> In the language Haskell, where function application is delineated not 
> with parentheses but with space separation, and where declaration 
> keywords like `const` are unnecessary, this would be written as
> 
>     squareAll = map square
> 
> That's extremely elegant; every token used adds meaning to the definition.
> 
> But the points-free Javascript is not too far off, adding only `const`, `
> (`, and `)`.  If we look at the arrow-function version, we add a number 
> of additional tokens on top of those: `nbrs`, `=>`, `,`, and `nbrs`, and 
> the other version, while removing `const`, adds `function`, `(`, `nbrs`, 
> `)`, `{`, `return`, `,`, `nbrs`, and `}`.  (Note that the "points" in 
> "points-free" does not refer to all these tokens, but only to the uses of 
> `nbr` in this case.)  
> 
> The main idea is that this points-free definition can often make it very 
> clear what is going on without the distraction of names.  Was `nbrs` the 
> right choice?  Should it be `list`?  `array`?  `nbrList`?  It is about 
> how functions act on your data, not on the data itself, and especially 
> not on what you choose to name that data in a particular instance.
> 
> This is not universally helpful, though.  As functions get more complex, 
> using arrow functions for parts of your definitions may make them easier 
> to understand.  There is no universal prescription.  Points-free coding 
> is a useful tool to have in your toolbox.  The only thing it will grant 
> you is additional readability.  If it's not doing that, then don't use it.
> 
> 
> > In addition, I'm dying to take a look at some FP JavaScript code that
> > effectively solves some REAL world problem. To me, this type of learning
> > is most impactful.
> 
> I would suggest looking through some real-world projects that use such 
> libraries then.  The NPM page for Ramda [4] has a list of other projects 
> that are dependent upon it [5].  With 1800+ projects to look at, 
> something there might interest you.  (Lodash has 20 times as many 
> dependents, BTW, but lodash is mostly used in more imperative settings, 
> so finding the places where its used in its functional guise might be 
> more tricky.)  You might also look to the dependents for Sanctuary [6], 
> which is related to Ramda, but takes a more principled stand.  However 
> there are only a handful of such dependencies there.
> 
> 
> 
>   [1]: <https://lodash.com/#download-links>
>   [2]: <http://ramdajs.com/#installation>
>   [3]: <https://wzrd.in/>
>   [4]: <https://www.npmjs.com/package/ramda>
>   [5]: <https://www.npmjs.com/browse/depended/ramda>
>   [6]: <https://www.npmjs.com/browse/depended/sanctuary>

Much appreciated.

Regarding loadsh CDN, this is its URL,
https://www.jsdelivr.com/projects/lodash
I assume these are extremely intelligent people, but are they nuts?  I mean,
they have 
lodash.core.min.js
then
lodash.core.js
the names suggest they are either or

and similar problems for other files

They should really list them with Options such as 
Option A
file1
file2
...
fileN

Option B
...


Not sure if the following is complete:
https://cdn.jsdelivr.net/lodash/4.17.4/lodash.core.js
https://cdn.jsdelivr.net/lodash/4.17.4/lodash.fp.js
https://cdn.jsdelivr.net/lodash/4.17.4/lodash.js
https://cdn.jsdelivr.net/lodash/4.17.4/mapping.fp.js

Then, would file loading sequence matter?  
Should lodash.js be the very first one?

I don't mean to complain, but I hope they can think from user perspective.

[toc] | [prev] | [next] | [standalone]

#32256

justaguy wrote:
> 
> Regarding loadsh CDN, this is its URL,
> https://www.jsdelivr.com/projects/lodash
> I assume these are extremely intelligent people, but are they nuts?  I mean,
> they have 
> lodash.core.min.js
> then
> lodash.core.js
> the names suggest they are either or

It's a social convention. They are the same thing, one just happens to be minified for optimizing file size

> Not sure if the following is complete:
> https://cdn.jsdelivr.net/lodash/4.17.4/lodash.core.js
> https://cdn.jsdelivr.net/lodash/4.17.4/lodash.fp.js
> https://cdn.jsdelivr.net/lodash/4.17.4/lodash.js
> https://cdn.jsdelivr.net/lodash/4.17.4/mapping.fp.js
> 
> Then, would file loading sequence matter?  
> Should lodash.js be the very first one?

The above links are from a 3rd party delivery service. It would be wiser for you to look at the official site to determine proper usage: <https://lodash.com/>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web