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

Write code. Not too much. Mostly functions.

brandons.me

Post reply on HN
Print view View original

71–80 of 362 posts

Re: Write code. Not too much. Mostly functions.

#71

Post by lmm »

modeless wrote: post #5
83457 wrote: post #2

And functions should be no bigger than your head.

This is my least favorite programming advice. Splitting functions for no reason other than "it's too long" is a bad practice. https://news.ycombinator.com/item?id=25263488

That advice should be understood in the same way as "sentences should be no longer than a few dozen words" or "paragraphs should be no longer than a few lines". Of course adding a line break at an arbitrary point in a long paragraph doesn't make it better. But a solid wall of text is a red flag.

Re: Write code. Not too much. Mostly functions.

#72

Post by chiefalchemist »

> At the risk of stretching the analogy, maybe the equivalent is "code only those things that people at a junior level would recognize for what they do".

Spot on. And I would add: Keeping in mind that junior level person could be under excessive stress. Perhaps something has failed. Perhaps they are looking at that section of code for the first time.

Context matters. It affects readability, comprehension, and understanding.

Straightforward > Cleverness

Re: Write code. Not too much. Mostly functions.

#73

Post by brundolf »

formerly_proven wrote: post #60

Major deja-vu moment for me. I've been carrying that headline around (as a quote) for a few months at least as an expression of a sentiment I've had for years, and thought I've seen it in a few places (and on HN), yet Google only shows me this blog as a source (which obviously isn't possible and almost feels like gaslighting). Does someone have an older reference for this?

I (the author) and another person independently thought of it in the comments of an article a couple months ago: https://news.ycombinator.com/item?id=25501263

Re: Write code. Not too much. Mostly functions.

#74

Post by Chris_Newton »

dcolkitt wrote: post #57
nomel wrote: post #44

Earlier quoted context omitted.

> well composed with enough, but too many, functions. In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks. > As I get older my code gets a little more verbose I've seen too many of my previous projects die right when I moved on. Now I tend…

I disagree. I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function. That more than anything is what kills readability, because context switching imposes a huge cognitive load. Isolating layers of abstraction almost always means small, isolated, single-purpose functions.

I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function.

I agree up to a point, but I find this kind of separation a little… idealistic? I prefer the principle that any abstraction should hide significantly more complexity than it introduces.

At the level of system design, there probably are some clearly defined layers of abstraction. I’d agree that mixing those is rarely a good idea.

But at the level of individual functions, I have too often seen numerous small functions broken out for dogmatic reasons, even though they hid relatively little complexity. That coding style tends to result in low cohesion, and I think the cost of low cohesion in large programs is often underestimated and can easily outweigh the benefit of making any individual function marginally simpler. If you’re not careful, you end up trading a little reduction in complexity locally for a big increase in complexity globally.

Re: Write code. Not too much. Mostly functions.

#75

Post by brundolf »

whoisthemachine wrote: post #53

Great post. I would even go as far as to amend your last comment to be closer to its inspiration: > Code only those things that your grandparents would have coded Software has been around long enough that some people's grandparents were coding, but due to the limitations of many of the systems at the time, functional, simple programs were often the craziest they could get.

My impression of early coding (could be wrong) is that you mostly couldn't afford to write in functional terms, because you had to carefully manage things like memory usage. Assembly, at least, is about as far from FP as you can get

Re: Write code. Not too much. Mostly functions.

#76

Post by lmm »

brundolf wrote: post #36
zzzeek wrote: post #32

this post seems like a graphically appealing way of just making the usual "FP is better" argument, except without any other actual argument other than "In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the long-term health of the project." in my experience I've seen codebases that are entirely object oriented where we…

> this post seems like a graphically appealing way of just making the usual "FP is better" argument I would rephrase it as "FP is a better default". A big part of my thesis is that dogmas tend to have shortcomings, which contrasts with the stereotypical "FP is better" literature. > in my experience I've seen codebases that are entirely object oriented where we are writing methods, not functions, or codebases that use…

Using an IO monad first is putting the cart before the horse, unless your business problem is fundamentally about IO. If you want to be able to express the business logic as functions then you need to use monads to encapsulate the complex parts of the implementation (or you'll end up with an ad-hoc, informally specified, bug ridden implementation of half of them), and once you're comfortable with them you'll probably find them useful for giving you explicit-but-not-too-verbose control over IO as well.

Re: Write code. Not too much. Mostly functions.

#77

Post by cbetti »

cerved wrote: post #39
bob1029 wrote: post #11

I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…

wiring pure functions decouples processing from data. I find this encourages developing well defined models naturally as well as making the model much more agile and malleable

With enough stack space you don't need to decouple your data from your pure functions at all ;-)

Re: Write code. Not too much. Mostly functions.

#78

Post by brundolf »

centimeter wrote: post #61

This article is absolute garbage. It’s embarrassing that it got this high on the front page. It has zero information. It’s a paean to smug, unconsidered mediocrity. Not only is the premise of the tenuous analogy likely completely wrong (the preponderance of evidence suggests eating “mostly plants” is, in fact, anywhere from bad to terrible for you, depending on your choice of plants), but the way in which it’s presen…

In the HN FAQ, under "Are reposts okay?"

> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.

https://news.ycombinator.com/newsfaq.html

Usually you have to get lucky with the right time of day for something to actually take off the way it would otherwise (before it falls too far down "new"). Sometimes the staff will even email you asking if you can repost a link that "should have" taken off, but didn't because of bad timing. Personally I limit myself to three tries on posts I've spent time writing that haven't yet gotten out of the single digits.

Re: Write code. Not too much. Mostly functions.

#79

Post by abledon »

momokoko wrote: post #69
serial_dev wrote: post #17

I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…

>I don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway. This is by far the most common thing I’ve seen consistently in especially difficult to maintain codebases. Anecdotal for sure, but number 2 on that list is way behind. Extra abstractions for a future that has yet to happen and abstractions because the IDE makes it easy to click through the layers is the nu…

> Can I see exactly enough on this page to know what it does? Not more, not less

Is there some book/website/SO post that tries to drive this piont home? Bascialyl some web resource I can link to other programmers to explain the value of coding as such.

Re: Write code. Not too much. Mostly functions.

#80

Post by brundolf »

andreareina wrote: post #66
brundolf wrote: post #45

Earlier quoted context omitted.

I think there are monads that are reasonably intuitive - Promises, Option types, etc (I know promises are ~technically~ not monads). It's mainly the practice of incorporating state into a stateless language and all the weirdness that entails that's the problem, in my view (so, specifically the IO monad)

> (I know promises are ~technically~ not monads) Do you mean promises in general, or the concrete implementation in js? I've got it in my head that promises the pattern are monadic, but js stuffs it (e.g. by up by making .then() automatically flatten if the callback also returns a promise)

That sounds right. I'm not exactly sure
Post reply on HN