These are chat archives for ramda/ramda

8th
Oct 2017
Michael Hurley
@buzzdecafe
Oct 08 2017 01:30 UTC
^^^ :+1:
Kurt Milam
@kurtmilam
Oct 08 2017 09:00 UTC
@CrossEye I find the solution I linked earlier significantly more readable than the chunked solution:
const archPathEq = pathEq( ['config', 'osarch'] )

const getSteamappVdfLaunch =
  ( { steamPlatform, arch } ) =>
    o( either( find( both( pathEq( [ 'config', 'oslist' ] )
                                 ( steamPlatform )
                         ) 
                         ( either( archPathEq( undefined ) )
                                 ( archPathEq( arch ) )
                         )
                   )
             )
             ( head )
     )
     ( values )
Adam Szaraniec
@mimol91
Oct 08 2017 09:22 UTC

Is it possible to write it in another way

const createPlayer = (player, position) => ({player, position})

const createPlayerItems = (playersCount, positionName) =>
    R.times(
       () => createPlayer(null, positionName),
       playersCount
   );

I dont like this () => createPlayer I know that I could use always but I feel better w/o it.

Kurt Milam
@kurtmilam
Oct 08 2017 09:30 UTC
The chunked solution contains 45% more non white space characters than the less chunked one, for instance (at 319 vs 221). Not a big deal for a single, small code snippet, but that's a significant difference when multiplied over a larger code base.
Kurt Milam
@kurtmilam
Oct 08 2017 09:35 UTC
@mimol91 Here's an option:
const times_ = flip( times )
const createPlayer =
  player => position => ( { player, position } )

const createPlayerItems =
  playersCount =>
    o( times_( playersCount ) )
     ( createPlayer( null ) )
Adam Szaraniec
@mimol91
Oct 08 2017 10:05 UTC
thanks!
Kurt Milam
@kurtmilam
Oct 08 2017 10:05 UTC
:+1:
Kurt Milam
@kurtmilam
Oct 08 2017 11:28 UTC
The chunked solution also misses a case that my original solution handles. It's not clear to me whether that case needs to be handled, but if I remove support for that case (matching the chunked solution's functionality exactly in that respect), the the shorter non chunked solution only contains 164 non white space characters. In other words, the chunked solution contains almost twice (196%) as many characters as the adjusted non chunked one.
const getSteamappVdfLaunch =
  ( { steamPlatform, arch } ) =>
    o( either( find( both( pathEq( [ 'config', 'oslist' ] )
                                 ( steamPlatform )
                         ) 
                         ( pathEq( ['config', 'osarch'] )
                                 ( arch )
                         )
                   )
             )
             ( head )
     )
     ( values )
Kurt Milam
@kurtmilam
Oct 08 2017 11:35 UTC
I've discussed this with others in the channel, but I'm coming to believe more and more strongly that what I refer to as 'premature abstraction' in the form of giving names to composed or partially applied functions that will not be used more than once in the code base (hats off to @JAForbes for having motivated my thinking about the subject) is something of an anti pattern for several reasons. First, I think one should avoid practically doubling the number of non white space characters unless that doubling brings with it significant advantages.
Second, in my experience, premature abstraction can obscure actual reusable patterns. In other words, it's possible to abstract the wrong patterns, thereby obscuring the patterns that would really be useful to abstract.
Kurt Milam
@kurtmilam
Oct 08 2017 11:41 UTC
Third, naming things is costly. It's costly at the time of naming (as the developer tries to come up with a name that they hope will clearly convey what the named thing is/does to their future selves and to other developers on the team. It can also carry a longer term cost if the name doesn't (and in my experience this is often the case), with 100% clarity to everyone who reads it at any point in the future, describe what the thing is/does.
If the name isn't 100% clear, future developers will need to switch context, leaving the actual function they're working on to look at the body of the named function elsewhere in the code.
Fred Daoud
@foxdonut
Oct 08 2017 11:54 UTC
@kurtmilam word :100:
Rick Medina
@rickmed
Oct 08 2017 20:06 UTC
@kurtmilam :+1: In the context of fp, I think of "premature abstraction" as related to parametric polymorphism (there are whole discussions about it), though.
Scott Sauyet
@CrossEye
Oct 08 2017 22:16 UTC
@kurtmilam: I'm completely on the other side of this. I made my suggestion because I found I couldn't comfortably read yours. As much as I like LISP, I've never been happy with LISP-style indentation, especially in other languages. I'm very happy with naming intermediate functions, even if they're only used once, especially when I have modules or some other technique to reduce their scope. I'm never very concerned with character count, especially "non white space characters."
You're absolutely right that this missed a case. But to fix it, I know immediately what small named function needs to be altered. That's one reason I like naming these functions.
But as always, de gustibus non est disputandum. It's always nice to see a variety of solutions.
Kurt Milam
@kurtmilam
Oct 08 2017 23:21 UTC
@CrossEye my mention of 'non white space characters' was a shorthand way to point out that your solution is twice as long as mine by character count if we ignore white space, and I think that's one reasonable objective measure of the complexity of the code. Another (perhaps more meaningful) would be a count of words in each solution. By my count, my solution contains 18 words as opposed to 38 in yours. Here's mine with less LISPy formatting. In this format, my solution has fewer lines of code than yours, as well (5 vs 8):
const getSteamappVdfLaunch = ({steamPlatform, arch}) =>
  o(either(find(both(pathEq(['config', 'oslist'], steamPlatform),
                     pathEq(['config', 'osarch'], arch))),
           head),
    values)
Kurt Milam
@kurtmilam
Oct 08 2017 23:27 UTC
It's not my intention to pick on you or criticize you. It's just an issue I've put some thought into recently, and one I'm interested in discussing, especially with those who are, as you say, "completely on the other side of this."