this post was submitted on 03 Sep 2026
34 points (92.5% liked)

Programming

28403 readers
264 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
34
Beyond Lambdas: Raising the Abstraction Level of Functional Code (adamtornhill.substack.com)
submitted 5 days ago by codeinabox@programming.dev to c/programming@programming.dev
15 comments fedilink hide all child comments
top 15 comments
sorted by: hot top controversial new old
[–] folekaule@lemmy.world 22 points 5 days ago (6 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.

[–] theherk@lemmy.world 12 points 5 days ago (1 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.

[–] folekaule@lemmy.world 4 points 5 days ago (1 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.

[–] Feyd@programming.dev 4 points 5 days ago (1 children)

Yeah there is some overhead with a function call

Not necessarily, since compilers can inline functions as an optimization

[–] folekaule@lemmy.world 2 points 5 days ago (1 children)

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.

[–] Feyd@programming.dev 4 points 5 days ago

Yup just wanted any newbie types scrolling by to not take that as something that is always true, when writing in most compiled languages it is completely up to the compiler.

[–] NotSteve_@lemmy.ca 8 points 5 days ago

That sounds like the evil mirror of my one former professor who limited function length to 8 lines of code in assignments

[–] atzanteol@sh.itjust.works 3 points 4 days ago

I never trust a programmer who has any "strict rules".

[–] cosmicrose@lemmy.blahaj.zone 6 points 5 days ago (1 children)

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.

[–] Womble@piefed.world 5 points 5 days ago

Honestly, as long as the functions you are creating are pure and reasonably named, I think its pretty much always a win to wrap any coherent operation up into one.

[–] rockSlayer@lemmy.blahaj.zone 5 points 5 days ago (1 children)

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

[–] syklemil@discuss.tchncs.de 1 points 5 days ago

Yeah, there are some examples out of "clean code" that are absolutely ludicrous on the "tons of tiny functions" end.

I'd also say letting map/filter and other common operations show is entirely fine.

[–] Ardyssian@sh.itjust.works 2 points 5 days ago* (last edited 5 days ago)

I think the at least twice thing comes from Avoiding Hasty Abstractions (AHA) rule / convention, as a counter / caveat to DRY

[–] monomon@programming.dev 2 points 3 days ago* (last edited 3 days 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.

[–] gandalf_der_13te@feddit.org 4 points 5 days ago

you can also just add comments i guess. but yeah, both would work fine.