29
Beyond Lambdas: Raising the Abstraction Level of Functional Code (adamtornhill.substack.com)
submitted 2 months ago by to c/programming@programming.dev
14 comments fedilink hide all child comments

top 13 comments

sorted by: hot top controversial new old
[–] 21 points 2 months ago (12 children)

I once, many years ago, worked with a programmer who had a strict rule of not introducing any functions unless the block of code was used at least twice.

Every code base they were the main developer on had source files thousands of lines long with if-statements nested to the 9 levels of hell.

We worked mostly in Perl and Deplhi (Pascal). Reading old code was... interesting. It's wild when your Perl code is more readable than your Pascal.

I'm happy to say I don't work with them anymore.

So yeah, break things into functions and name your functions and variables sensibly. Your future self will thank you.

  • permalink
  • fedilink
  • source
  • hideshow 12 child comments
    •
  • [–] 11 points 2 months ago (4 children)

    Not making functions unnecessarily is a pretty good rule, but like all rules, it can be ignored for good reasons. Strict adherence to any rule (in programming) is fraught.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 2 months ago (3 children)

    Yeah there is some overhead with a function call, but for our use case (low-traffic web and batch jobs) that wasn't a big deal. And the rest of their code wasn't exactly tuned for performance either.

    Yes, it was the dogmatic approach to it that was the most infuriating.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [+] 4 points 2 months ago (2 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 months ago (1 child)

    Yes, but Perl 5 did not, except for constant functions. Either way, the effect of that was outweighed by several orders of magnitude by the rest of the WTFs in that code.

    All that is a bit beside the point I was trying to make, which is write readable code.

    Use your own judgement to find a balance between readability and performance. Use profiling tools to find hotspots where performance is a concern and optimize those. Base your practices on evidence not dogma.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
    load more comments (1 reply)
  • [–] 5 points 2 months ago (1 child)

    I mean, that's a reasonable rule of thumb, but there are definitely limits. It seems that they chose to follow the rule regardless of practicality. Helper functions are nice and good. Almost as good as recursion. Recursive helper functions are nicer and gooder

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 5 points 2 months ago (1 child)

    I can agree with this, mostly. More recently I’ve been trying to become aware of how much knowledge I’m encapsulating within functions, preferring to hide more stuff in them rather than less, and avoiding shallow functions that just, say, wrap a single line just passing along the arguments. I’ve realized over my career that I’d prefer a longer function that I can just read straight through rather than jump between a bunch of shallow functions trying to piece things together.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
    • [–] 2 points 2 months ago*

    Yes and no. I find short lambdas easier to read. In lisp you have flet, labels, which allows you to name the elements without introducing external functions.

    But of course there are cases where the proposed is useful, e.g. for reuse. I can imagine applyModifiers could be called in more than one place.

    Anyway, upvoted because it's an interesting discussion.

  • permalink
  • fedilink
  • source
    •