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

211–220 of 362 posts

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

#211

Post by dathinab »

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

I can't really agree to this. Through without questions there are always things you should not split out.

Splitting a functions which consists of multiple logical steps is most times a good idea because it makes testing much simple and tends to show you where you accidentally had subtle cross-cutting concerns or unintended cross-talk between sub-domains (domains in sense of modelling, not http).

What is important is to properly name functions (and if you can't you probably shouldn't write that function).

Also it's important to learn how to live with abstraction, i.e. to reason about code wrt. a specific problem without needing to jump into the implementations about every function /method it calls.

Through the later point is much easier with a reasonable use-full type system. And with this I mean useful for abstraction without making abstraction to hard and without allowing to many unexpected things. Languages like rust or scala have such a type system (as long as you don't abuse it) but e.g. C++ fails this even through it has a powerful type system.

At least this are is opinion.

And without question if you can't cleanly split something out, then don't split it out. If you can split it out but not name it reasonable either your understanding it lacking or it should never have been split out.

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

#212

Post by brundolf »

sameerds wrote: post #193

I know my request might be off-topic ... the original article is from a blog that does not export an RSS/Atom feed. I am looking for recommendations for a service which can let me scrape a feed by guessing the structure of the articles.

I've thought about implementing RSS for it at some point, good to know somebody has interest in that. In the meantime I tried to keep the HTML semantic, so hopefully you're able to find a way to scrape it!

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

#213

Post by darksaints »

Geminidog wrote: post #162
unityByFreedom wrote: post #125

Earlier quoted context omitted.

Can you describe that in simpler terms? I read the wiki and the Python example seems to suggest writing functions that take a single argument.

It's pretty simple. x = 1 addSomething(y) = y + x The above is not a combinator. addSomething relies on the line x = 1 and is forever tied to it. You cannot reuse addSoemthing without moving x = 1 with it. Therefore addSomething is not modular. This is the root of organizational technical debt. When logic depends on external factors it cannot be reorganized or moved. This is also a big argument against OOP because OO…

The downside to taking that combinator approach too dogmatically is that passing all state as parameters can get extra unwieldy, because now a simple change in data schema can result in you refactoring every single function call.

This dilemma has a name: The Expression Problem. A decent summary can be found here.

https://wiki.c2.com/?ExpressionProblem

Functional programming is an amazing paradigm for most domains. However, some domains will take a seasoned functional programmer and make them want to jump off a cliff. UI programming, game programming, and simulation programming are some examples where pure functional approaches have never made a dent, and for good reason.

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

#214

Post by hinkley »

tomrod wrote: post #19
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…

What if code is needed to explore the problem domain? There is utility in discovery, especially for analysts/data scientists who tend to write a surprising amount of code.

To do that, you need to be willing to delete code you worked hard on. Lots of people aren't good at that.

And some think asking your boss if it's okay is a good idea, (spoilers: they'll say no). That is just a way to pass blame for a decision you can't stomach.

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

#215

Post by jim-jim-jim »

modeless wrote: post #209
jim-jim-jim wrote: post #192

Earlier quoted context omitted.

I thought I hated small functions too, til I realized I just hated scrolling. The moment it's off my screen, it's out of my head. Assuming you just need helper functions for f(), compare int f(int x) { return g(h(x)); } int g(int x) { return ... } int h(int x) { return ... } to f = g . h where g = ... h = ... Turns out my language choice was the problem, not over-abstraction. If you can fit it all on one screen, then…

The logical conclusion of this line of thinking is APL or K. Some people swear by it. I admit terseness is appealing for solo coding, and I loathe the bloat of Java etc, but when taken to the extreme terseness starts being a problem for collaboration.

I think you're right about those langs and collaboration; all the procedures are right there in front of you, but you gotta keep track of the data shape in your head. Just as much work as scrolling page-spanning functions imo.

That's what makes point-free Haskell such a sweet spot for me: terse, symbollic control flow and nice combinators, but types to guide you. I try to use it as a better J.

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

#216

Post by IggleSniggle »

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.

Here’s some counter-argument psuedo-code:

    // v1, mixing layers of abstraction
    x = a if exists, else first()
    y = b if exists, else second()
    result = third(x,y)

    // v2, abstraction
    result = getResult(a,b)
In v1, we have the semantics of x and y, so we understand that a “result” is obtained through the acquisition of x and y. Whether we need to understand this is a judgement call. But v2 opens a different “failure to understand” modality: “getResult” is so blackboxed that the only thing it really accomplished is indirection, without improving readability.

I love Clean Code, but I think it sometimes prematurely favors naming a new function and the resultant indirection.

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

#217

Post by quacker »

abernard1 wrote: post #108
ZephyrBlu wrote: post #96

Earlier quoted context omitted.

I have a contrary view on code style. If there's no semblance of consistency to the code you write, how can you possibly formulate a consistent and sensible architecture? The style itself is inconsequential, but no consistent style is a red flag to me.

> how can you possibly formulate a consistent and sensible architecture? Similar arguments could be made about actual architecture: "If you can't have well-designed and consistent houses, how can you possibly have a well-designed city?" The best architectures I've seen, by far, had the worst code. Code is not a systemic level issue. The way the pieces fit together is. A sad fact of good architectures is they actually…

Yes. For example, a distributed system composed of various microservices, where the microservices can use different code styles, different programming languages, be maintained by different teams, etc.

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

#218

Post by brundolf »

gfxgirl wrote: post #174

I find it interesting that React ignores this advice about pure functions. From the react docs import React, { useState } from 'react'; function Example() { // Declare a new state variable, which we'll call "count" const [count, setCount] = useState(0); return ( You clicked {count} times setCount(count + 1)}> Click me ); } It's clear "Example" will be called every time it's rendered yet "useState" is NOT "pure". Some…

Yeah, I tend to agree (and this is why I don't like hooks). I'll write pure functional components all day, but if I need to introduce state, I'm going to use a class component and just acknowledge that state as state and not try to pretend it's still just a function.

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

#219

Post by IggleSniggle »

dathinab wrote: post #187

> 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. I came to the same conclusion ~1 year ago when writing rust. It's pretty common to have some "high level" method in rust then you split it up, some small parts go into other maybe private methods but a lot goes into split out func…

This is a problem you will face regardless. It is fundamentally a code organization problem and faces all the problems that other organizational problems face. Which is to say, the best you can hope for is to have a reliable way of generating the report you need when you need it.

Which for me suggests that it doesn’t really matter which way you do it, as long as you 1) dogmatically adhere to doing it the same way every time and 2) have the tooling to effectively manage the downsides of your choice.

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

#220

Post by eyelidlessness »

Geminidog wrote: post #176
eyelidlessness wrote: post #165

Earlier quoted context omitted.

So basically, use functions but limit your use of closures? As in define your functions to be dependent only on parameters and not surrounding scope (even if the surrounding scope is immutable/pure)? If that’s the lesson, I’m all for it, with the exception of fully local closures that are used more for expressiveness than standalone functionality.

>So basically, use functions but limit your use of closures? Not limit, terminate the use all together along with classes because methods in classes are basically closures. >I’m all for it, with the exception of fully local closures that are used more for expressiveness than standalone functionality. Sure I can agree with this... formally though. When you write a local closure you are preventing it from ever being re…

I think we’re mostly in agreement. I’m a little looser than your absolute in practice, but I apply the same principles. Where I’m looser is basically an allowance for closures as a simple expression (and where languages with more expressiveness may not require a closure). If any local logic becomes more complex than that, I’m quick to parameterize it and move it out to its own function.
Post reply on HN