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

191–200 of 362 posts

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

#191

Post by craftinator »

Geminidog wrote: post #117
monocasa wrote: post #86

Earlier quoted context omitted.

Hard same. The best organizational level technique I've found so far is to add the rule of three to code review checklists. An abstraction requires at least three users. Not three callsites, but three distinct clients with different requirements of the abstraction. Obviously it's not a hard rule, and we allow someone to give a reason why they think that it's still a good idea, but forcing a conversation starting with…

Why 3? Rule of three sounds catchy but logically it's just a arbitrary number. Similar to SOLID and KISS, why pick some arbitrary (and also obvious) qualitative features and put it into an acronym and declare it to be core design principles? Did the core design principles just Happen to spell out Solid and Kiss? Did it happen to be Three? Either way, in my opinion, designing an abstraction for 3 clients is actually q…

The rule of 3 is catchy like you say, which means programmers will have a better chance of remembering when it's needed.

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

#192

Post by jim-jim-jim »

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 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 have at it tbh.

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

#194

Post by unityByFreedom »

Geminidog wrote: post #164
unityByFreedom wrote: post #158

Earlier quoted context omitted.

> this means don't even use pure functions in classes. Just use functions. ... so you agree with the author of this post? Also, seems like there is tech debt with point free, you just have it up front rather than putting it off until later.

Depends on the definition of tech debt. Do you mean structural/organizational or readability? If you mean readability then yes, the point free style does not protect you from that imo. But combinators and the point free style does protect you from structural and organizational issues, which is the type of technical debt I'm referring too.

I meant up front you'd need to write more functions than you would when using functions that allow multiple arguments.

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

#196

Post by Geminidog »

craftinator wrote: post #191
Geminidog wrote: post #117

Earlier quoted context omitted.

Why 3? Rule of three sounds catchy but logically it's just a arbitrary number. Similar to SOLID and KISS, why pick some arbitrary (and also obvious) qualitative features and put it into an acronym and declare it to be core design principles? Did the core design principles just Happen to spell out Solid and Kiss? Did it happen to be Three? Either way, in my opinion, designing an abstraction for 3 clients is actually q…

The rule of 3 is catchy like you say, which means programmers will have a better chance of remembering when it's needed.

But a catchy name serves only to be catchy it doesn't serve as justification for the rule actually being correct.

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

#197

Post by unityByFreedom »

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…

Yeah I'm already on board with modular functions and functional programming in general. I was wondering about the point free thing. I agree that's like going vegan.

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

#198

Post by Geminidog »

ellis-bell wrote: post #185
Geminidog wrote: post #162

Earlier quoted context omitted.

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…

hah i was taught that style is "pointless"... it comes from topology, no?

No idea. Does it? Never studied topology.

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

#199

Post by AnimalMuppet »

Geminidog wrote: post #189
redisman wrote: post #178

Earlier quoted context omitted.

Any paradigm can look clean when you’re playing. Work on it for a year and then have management tell you that we must add a feature that breaks your core design because our big client needs it.

Many aspects of a programming language can make it nasty or hard to use under certain contexts. This is something most programmers are aware of through experience. My point is, that the use of combinators and point free programming formally eliminates organizational technical debt. So for this specific issue, Joy should indeed be better by logic.

> My point is, that the use of combinators and point free programming formally eliminates organizational technical debt.

Hardly. It may eliminate certain kinds of technical debt. Pretty sure it won't eliminate all of it. As you said in a parallel post:

> Readability is definitely worse when using this method.

Well, that's a kind of technical debt.

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

#200

Post by dathinab »

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…

The thing about modelling is that it often works on a higher abstraction level then the programming languages provide and that a bunch of (often performance related) thinks are (preferably) not represented in modelling.

This IMHO makes most tools to generate code from models just painful to use.

But I still agree that you have no business programming something which you can't somewhat model in a higher abstraction level.

> SQL is the king of managing data

Hm, not so much IMHO. SQL Is terrible bad at it in some contexts because it's inherently made for a 2d table projection which is (more or less) only joined to larger 2d table projections of data which often in it's nature is neither 2d nor maps well to 2d representations. And while you can extend SQL to support that or work around it with e.g. recursive queries it's not very nice to do at all.

Post reply on HN