Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small functions considered harmful

medium.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Small functions considered harmful

#71

Post by agentultra »

jerf wrote: post #50
agentultra wrote: post #44

It seems like the author's idea of the term abstraction is limited to substituting procedures with functions (or worse, class methods). The claims that "all abstractions leak" and that adherence to DRY makes code "hard to follow" is what gives me this impression. This line of thinking happens if you think of code in procedural terms. And if your sense of abstraction is to hide procedural side-effects behind function…

Arguably lambda, monad, etc. are generalizations, not abstractions: http://www.emu.edu.tr/aelci/Courses/D-318/D-318-Files/plbook... Abstractions that don't leak aren't abstractions, as the essense of abstraction is the simplification and removal of detail. Monad is a generalization of a pattern seen in many places, so it doesn't have to "leak".

I don't think I'd argue with that.

To take the idea to its conclusion is that one can build abstractions on these building blocks. It's typical for software I write to be built up from small functions. The abstractions happen as higher-order functions build up to the domain level language until the implementation meets its specification.

A rather well-defined abstraction I admire is the OSI model [0]. A software system that emulates this model, built from solid generalizations like lambda and higher-order functions tend to be quite strong in the sense that reasoning about them can be done in isolation from layers below or above.

Procedural code, if not well contained and isolated, easily loses this ability and requires the programmer to enumerate the decision tables in their head and all of the possible effects that could be caused by different inputs... such a waste of time. I've been there, done that. Not for me. I like small functions as long as I have ways of composition by means of higher-order functions.

Re: Small functions considered harmful

#72

Post by jdmichal »

whack wrote: post #25

During my earlier years, I would get into all types of dogmatic debates, such as "DRY-considered-harmful" or "small-functions-considered-harmful" . With experience, I've realized that such abstract debates are generally pointless. Any principal can lead to bad results when taken to an extreme, or badly implemented. Thus leading to people declaring that-principal-considered-harmful , swinging the pendulum to the oppos…

I think it's more likely that your "great programmers" simply understand the difference between the same functionality and accidentally similar functionality. The latter is where you have two use cases that are very similar, so you spend all this time deduplicating. Then one of the use cases changes... The correct response would be to duplicate the code again, because the two use cases are no longer similar. In reality, they should have never been combined in the first case. They weren't the same; they were only accidentally similar.

But instead what you usually see is minor tweaks to the common functions. Pass in a flag here, tweak the inputs there, add an if statement over yonder... And before you know it, it's all a terrible tangled mess that is full of branches and technical debt. The two use cases have the same functions, but don't even follow the same branches within the functions.

Re: Small functions considered harmful

#73

Post by emn13 »

whack wrote: post #25

During my earlier years, I would get into all types of dogmatic debates, such as "DRY-considered-harmful" or "small-functions-considered-harmful" . With experience, I've realized that such abstract debates are generally pointless. Any principal can lead to bad results when taken to an extreme, or badly implemented. Thus leading to people declaring that-principal-considered-harmful , swinging the pendulum to the oppos…

Isn't what you're saying kind of exactly the point of the article in the first place? The conclusion even explicitly points out that the aim was not to actually claim small functions are harmful(!), but rather that the converse - small functions are good - isn't inherently true either.

And while the article doesn't make fully concrete examples, it does propose the outlines of a few; enough to get across a meaningful message (to me). Also; arguments that lean on concrete example are more at risk of attacking strawmen precisely because a concrete example can be flawed in irrelevant ways that obscure the underlying principles. Not that I'm opposed to examples - just that most examples are almost necessarily simplifications, and choosing a sourcecode simplification is not categorically different or better than choosing a pseudocode or diagram simplification.

Re: Small functions considered harmful

#74

Post by geezerjay »

jacalata wrote: post #41
coroxout wrote: post #2

I find a lot to agree with here. It's all very conceptually neat and (if you're lucky) easy to read from the top down, where you enter one function and read off a list of other functions which are called in order. But then if you look into any of those other functions they also call more functions and so on, several levels deep. And when you have to debug someone else's code because the data after function 15 of 17 i…

Wouldn't the compromise be unit testing?

> Wouldn't the compromise be unit testing?

I agree. Unit testing is done to ensure that all components work exactly as they are expected to work. If any component fails to work but developers only notice it "because the data after function 15 of 17 isn't quite right" then it appears that something is very wrong with the way those units are being tested.

Re: Small functions considered harmful

#75

Post by agentultra »

emn13 wrote: post #67
jerf wrote: post #50

Earlier quoted context omitted.

Arguably lambda, monad, etc. are generalizations, not abstractions: http://www.emu.edu.tr/aelci/Courses/D-318/D-318-Files/plbook... Abstractions that don't leak aren't abstractions, as the essense of abstraction is the simplification and removal of detail. Monad is a generalization of a pattern seen in many places, so it doesn't have to "leak".

I kind of agree with you (I think), but I'd present (or think) about it differently to avoid terminological squabbling. More specifically: I'm skeptical of the distinction that your referenced article attempts to introduce between generalizations and abstractions: that distinction feels after the fact, trying to retconn into existence some classification that just isn't that clearcut. Regardless of what's correct ter…

Thank you for posting this.

We see this a fair bit in formal methods of software construction. I can write a specification that proves that given a precondition a particular state will eventually result in a consequent state. The model is mathematically sound but it doesn't state when that transition will occur or how long it will take. And for the purposes of the specification it is likely not important!

The level of detail that is important should be deliberately chosen. A specification of a distributed system can choose to abstract away the details of the TCP protocol while still proving that the properties we do care about, consistency perhaps, are maintained.

Re: Small functions considered harmful

#76

Post by BeetleB »

shados wrote: post #21
Denzel wrote: post #20

Earlier quoted context omitted.

Clean Code can be harmful? Or the person dogmatically applying the advice? Martin warns against such blind dogmatism. He even goes so far as to explain the thought process behind most of his recommendations so that one may consider whether the rule applies or not. On balance, Clean Code does far more good than it does bad. I have yet to see these dogmatic Clean Coders blindly applying Martin's advice. Not in industry…

> I have yet to see these dogmatic Clean Coders blindly applying Martin's advice. You're lucky. I've seen it plenty of time. In one extreme case we even had to let go a perfectly (formerly) competent dev after he read that book and went crazy (yeah, seriously).

I've always found people who read his book to be more dogmatic than Martin and anything in that book. They usually speak in absolutes, and cite the book when challenged. Then I go point out his blog posts where Martin is more nuanced. I believe his book also has a number of disclaimers as well (I have not read it myself).

Overall, I agree with quite a few of his "principles". Just don't apply them blindly.

Re: Small functions considered harmful

#78

Post by jcelerier »

whack wrote: post #25

During my earlier years, I would get into all types of dogmatic debates, such as "DRY-considered-harmful" or "small-functions-considered-harmful" . With experience, I've realized that such abstract debates are generally pointless. Any principal can lead to bad results when taken to an extreme, or badly implemented. Thus leading to people declaring that-principal-considered-harmful , swinging the pendulum to the oppos…

"Considered Harmful" Essays Considered Harmful: http://meyerweb.com/eric/comment/chech.html

Re: Small functions considered harmful

#79

Post by hbt »

>>> If you have to spend effort into looking at a fragment of code to figure out what it’s doing, then you should extract it into a function and name the function after that “what”.

Fowler is right about smaller functions and OP misinterpreted his statement.

This is what Fowler means https://gist.github.com/hbt/3e71146454a2d6388338af1d76394a13

Abstract the fragment of code in a function, keep it within the function until you need it elsewhere and do not pollute needlessly the API with functions that are poorly named and used one time only.

Re: Small functions considered harmful

#80

Post by Denzel »

mdpopescu wrote: post #64
Denzel wrote: post #49

Earlier quoted context omitted.

I'd be interested to see what his code looked like and how the code reviews progressed before firing him. I think these discussions are important, however, we must ground them in a concrete reality. That's what I appreciated about Clean Code, it was grounded in addressing real live code. And the reader is able to choose whether they agree with the conclusions or not. With that said, all too often, like in this articl…

I don't know Go, but your example looks absolutely beautiful. On the other hand, I'm one of those "smaller than that" people :) I mean, I am ashamed that I left the time-to-string function in [1] too long. It could definitely be split up (and I find value in that, I just haven't had time / a reason to revisit that code). [1] https://github.com/mdpopescu/public/blob/master/SocialNetwor...

Thank you, I really appreciate that.

I understand exactly how I feel. I think your way of attacking it is the right way -- pragmatism. You realize it can be improved/split but (1) you haven't had time, (2) there's been no reason to revisit the code, and (3) it's serving its purpose. That makes sense to me.

It takes time. Time and many passes to refactor code. The idea being that as a developer becomes more experienced: the amount of time and the number of passes should begin to decrease. At least that's the idea.

Post reply on HN