[FRIAM] Classes, Complexity, and Functional Programming – Kent C. Dodds – Medium

Sat Aug 12 01:05:06 EDT 2017

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-bounces at redfish.com> on behalf of Owen Densmore <owen at 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 <marcus at snoutfarm.com<mailto:marcus at 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 <marcus at snoutfarm.com<mailto:marcus at 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-bounces at redfish.com<mailto:friam-bounces at redfish.com>> on behalf of Owen Densmore <owen at backspaces.net<mailto:owen at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20170812/79a3a5f9/attachment.html>