Leaving Python for JavaScript

Post by gknoy » Thu, Sep 07, 2017, 5:26 PM UTC

pseudalopex wrote: post #67

gknoy wrote: post #62

Earlier quoted context omitted.

If you want more than a one-line lambda, however, you're in for a rough time, and need to go the route of def foo(): # ... four lines here ... modified = map(foo, items)

What's rough about giving a function a name?

Naming things is one of the hard things in computer science. :) Anonymous functions, when appropriate, let us avoid having to think about that.

For example, `f` is a refactoring of an anonymous function:

    function f (item) {
      return {
        // foo properties
      }
    }
    const fooItems = values.map(item => f)

Imagine that you have to map over several different collections of items, and generating the lists `foo`, `bar`, and `baz`. You have to either name the functions we pass to map `f`, `g`, and `h` (which I bet our reviewers would hate), or `fooMapFunc`, `barMapFunc`, `bazMapFunc`. It just pollutes the namespace that I have to keep in my head, because I have to wonder "is this used somewhere else?".

Moreover, is it _more readable_ to define the helpers first, and then the collections that are made by using them, or to define the pairs (fooMapFunc, fooItems) in sequence? This could easily be felt one way or the other, and both are valid, but leads to code review holy wars. "I feel this is more readable / I feel exactly opposite".

For comparison, the anonymous version of this similar operation:

    const fooItems = values.map((item) => {
      return {
        // foo properties
      }
    })

    const barItems = values.map((item) => {
      return {
        // bar properties
      }
    })

    const bazItems = values.map((item) => {
      return {
        // baz properties
      }
    })

In this case, the anonymous function is clearly not usable anywhere else, so it's easier to be sure that it's something one can change, and completely removes the chance of holy war over readability of whether to define helper functions together or with their collection.

Post by pseudalopex » Thu, Sep 21, 2017, 9:32 AM UTC

gknoy wrote: post #111

pseudalopex wrote: post #67

Earlier quoted context omitted.

What's rough about giving a function a name?

Naming things is one of the hard things in computer science. :) Anonymous functions, when appropriate, let us avoid having to think about that. For example, `f` is a refactoring of an anonymous function: function f (item) { return { // foo properties } } const fooItems = values.map(item => f) Imagine that you have to map over several different collections of items, and generating the lists `foo`, `bar`, and `baz`. Yo…

Naming things is hard because names represent abstractions. Complex abstractions are hard to get right and hard to summarize; widely-used abstractions and names are hard to change.

A nested function is a simple abstraction in a narrow scope. Both the abstraction and the name are easy to change, so the name only has to describe what the function does now. When that's hard, it's often because the function does too much, does too little, or belongs somewhere else. Likewise, people arguing about the organization of inner functions is usually a sign the outer function should be refactored. Anonymous functions are appropriate when names would be almost redundant, not when coming up with a name is hard.

My editor can show me where a function is used; it can't summarize what a function does. Either way, you have to find where "fooItems" is used to know if you can modify the function.

Conversion functions are very easy to name ("itemToFoo"). Idiomatic Python would just use a loop:

    foo_items = []
    for item in values:
        foo_items.append({
            # foo properties
        })

Re: Leaving Python for JavaScript

Re: Leaving Python for JavaScript