Owen writes:

"OK, so in the JavaScript world, how does one inch forward toward functional? I 
don't want to be so functional as some of the extremes. Curring all the way to 
one arg functions?"


I'm not sure what properties of JavaScript you care about.  If it is just the 
operational part of being able to run in a web browser, there are languages 
like Fay (a subset of Haskell) that compile to JavaScript.


FP is something you can do in incremental ways in many languages.  Even though 
I use a mostly-FP style in R (or Common Lisp or Python or Julia or Fortran 
2008), in my mind it is isn't _really_ FP unless there is strong typing and an 
mandatory requirement of purity.   Currying, IMO, is something that is easier 
to use with languages that have strong typing and type inference because the 
transformations between function signatures is natural to inspect in those 
environments.  (It is quite common in Haskell to get complex, even surprising 
types by automatic type inference.)   Currying is nice, in contrast to 
closures, because it is deliberate and localized; one can capture a lot in 
lexical scope and a lambda may not be easy to convert into a non-anonymous 
function -- you may not be clear on what you are capturing in the closure and 
why.   Also currying has a nice intuition of progressively reducing the degrees 
of freedom of a function as that information becomes available.


The philosophy of languages like Haskell, F#, Mercury, etc. is to make working 
code more likely just by virtue of getting it past the compiler.   Instead of 
dynamic typing, the compiler uses logical inference to figure out what types 
make sense when they are not provided.  This gives the similar brevity as 
dynamic typing but with many more internal consistency checks.


I write a lot of R, and for simple things dynamic typing is fine.  But, as soon 
as I start using it for more complex things in a production context, any minor 
mistake can cost a lot of wasted CPU time.   For me, there's a point at which I 
want the cognitive support that static typing affords.   And of course static 
typing gives code generation more information to work with, which usually leads 
to faster code.


Haskell (GHCI) still has a REPL interpreter-like interface, so it is not fair 
to say that experimentation is not possible as it is in JavaScript.


Marcus

________________________________
From: Friam <friam-boun...@redfish.com> on behalf of Owen Densmore 
<o...@backspaces.net>
Sent: Friday, August 11, 2017 9:42:15 PM
To: The Friday Morning Applied Complexity Coffee Group
Cc: Wedtech
Subject: Re: [FRIAM] Classes, Complexity, and Functional Programming – Kent C. 
Dodds – Medium

On Fri, Aug 11, 2017 at 10:30 AM, Marcus Daniels 
<mar...@snoutfarm.com<mailto:mar...@snoutfarm.com>> wrote:
"I know, I know, functional programming is as fun as hitting your head with a 
brick."

It is fun!

​That's great to hear, too much is NOT fun in programming!​

If I have a project that isn't FP, I make it into an FP project because it is 
the right thing to do.

​OK, so in the JavaScript world, how does one inch forward toward functional? I 
don't want to be so functional as some of the extremes. Curring all the way to 
one arg functions?

The article says performance may be an issue.

The chief appeal for me is the Self-like objects only, no classes. But the lack 
of centrality may just as hard to navigate as the over-tight, stateful class 
approach.

   -- Owen​


On Fri, Aug 11, 2017 at 10:30 AM, Marcus Daniels 
<mar...@snoutfarm.com<mailto:mar...@snoutfarm.com>> wrote:

"I know, I know, functional programming is as fun as hitting your head with a 
brick."


It is fun!


"It is a bit scary letting go of "central control" Classes provide, very human. 
I mean, who's *boss*?"


The caller is the boss.  With FP you know that arguments are all read-only.

This gives you unambiguous dataflow and you know when parallelism can be done 
because the arguments just tell you.


let c = f(a)


..can run at once with..


let d = g(a)


..but not with..


let e = h(a,c)


Also "=" here isn't assignment, it is equality.


If I have a project that isn't FP, I make it into an FP project because it is 
the right thing to do.


Marcus



________________________________
From: Friam <friam-boun...@redfish.com<mailto:friam-boun...@redfish.com>> on 
behalf of Owen Densmore <o...@backspaces.net<mailto:o...@backspaces.net>>
Sent: Friday, August 11, 2017 10:19:05 AM
To: Wedtech; Complexity Coffee Group
Subject: [FRIAM] Classes, Complexity, and Functional Programming – Kent C. 
Dodds – Medium

​I know, I know, functional programming is as fun as hitting your head with a 
brick.

But this article does a nice job of showing how functional programming is very 
Self-like:
  ​​
https://me
​​
dium.com/@kentcdodds/classes-complexity-and-functional-programming-a8dd86903747<http://dium.com/@kentcdodds/classes-complexity-and-functional-programming-a8dd86903747>

​It's objects and functions all the way down, and for me the best is no `this`.

It is a bit scary letting go of "central control" Classes provide, very human. 
I mean, who's *boss*?

Do any of us *use* functional programming?

   -- Owen​


============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

Reply via email to