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

161–170 of 362 posts

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

#161

Post by quantified »

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…

It has been shown over and over to be a good number for this purpose.

You don't design the abstraction for 3 different clients as often as you abstract it from code used by 3 different clients.

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

#162

Post by Geminidog »

unityByFreedom wrote: post #125
Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

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 OOP is basically the same exact thing with a bit of scope around it:

  class B()
     x = 1
     addSomething(y) = y + x
     divideSomething ...
     b = 3
Now addSomething can never be used without taking x=1 and everything inside B with it. It is less modular as a result.

A combinator is like this:

  addSomething(x,y) = x + y
fully modular and not tied to state.

The point free style is a bit long to explain. Another poster brought up readability and now I think I went too far with it as a recommendation, it's like going vegan basically if you employ that style. Just stick to combinators and you get 99% of the same benefits.

Suffice to say the point free style eliminates the usage of all variables in your code. You are building just pipelines of pure logic without any state.

When you get rid of state as much as possible, your logic will not have any dependencies on state, and thus will generally be free of technical debt caused by logic being tied to dependencies.

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

#163

Post by redisman »

jrott wrote: post #147
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…

> 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. This is so true. The worst code that I've dealt with is the code that requires jumping to a ton of different files to figure out what is going on. It's usually easier to decompose a pil…

My experience has been that spaghetti is almost always in the real world mostly overly abstract and poorly thought out abstractions. You know you get a stack trace and you end up on a journey in the debugger for 5 hours trying to find any actual concrete functionality.

Compared to someone writing inline functions that do too much, the wasted brain hours don’t even come close

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

#164

Post by Geminidog »

unityByFreedom wrote: post #158
Geminidog wrote: post #149

Earlier quoted context omitted.

I agree with you. Readability is definitely worse when using this method. It doesn't mean it can't be circumvented with good naming. Overall though this method basically solves the problem with technical debt I described above. The root of all dependencies come from free variables. So if you get rid of free variables and turn your functions into combinators, then all your logic is modular. If you get rid of all varia…

> 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.

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

#165

Post by eyelidlessness »

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…

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.

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

#166

Post by basicneo »

Geminidog wrote: post #113

I'll take it one step further. Don't just write pure functions. Write point free combinators. Have you guys ever wondered why no matter how much care or planning you use to organize your code when you begin a project, some time down the line you will always encounter a situation where the organizational scheme you chose is less than ideal or even flat out wrong? It's a sort of inevitable technical debt that occurs. T…

Any justification for that?

IME, the point free style is aesthetic.

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

#167

Post by deeviant »

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…

> 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...

Where did you get that information, foster farms? Or are you defining "mostly plants" to be a diet that consists solely of green skittles?

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

#168

Post by valenterry »

AntiImperialis2 wrote: post #62

The closing line of the article: > Use the primitives that are there, when possible. Write what is simple, and natural, and human. I agree with this very much, but most of this article doesn't support this statement. Let's start with the statement it is based on. > Eat food. Not too much. Mostly plants. Michael Pollan is great but the human way is definitely not what Michael Pollan suggests. No human tribe ate that w…

> Functional programming originates in mathematics, which is also very human... but as complexity grows, it's not as human as you'd like it to be. A lot of humans struggle with complicated functional programming code, which is why it is not as popular.

I agree, but I wouldn't say people struggle with "functional programming code", they rather struggle with the concept in general. In that sense, functional programming is like higher mathematics: it's a great tool to solve many problems in a very efficient way, but it's also difficult to learn and everyone of us reaches a level where they can't advance anymore at some point. Some sooner and some later.

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

#169

Post by nx7487 »

pineconewarrior wrote: post #106
nx7487 wrote: post #50

Earlier quoted context omitted.

> In my experience, code with too many functions is more difficult to grok than spaghetti code. In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.

It's easy to say ugh, but we juniors are more than willing to learn "the right way". This is the hardest part for me. I get anxiety about it and it slows me down. How do I apply this to taking over someone else's 4 year old Magento project? We're out here doing our best, and sometimes our learning environments are in that context.

I am a junior developer too. Questions like this are better suited to your manager. Mine gives me constructive feedback at regular intervals, and I also reflect on my own work and look at other people's work.

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

#170

Post by Scarbutt »

ZephyrBlu wrote: post #51
earthboundkid wrote: post #33

> Bad programmers worry about the code. Good programmers worry about data structures and their relationships. — Linus Torvalds

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

My take is that bad programmers represent information as data as an afterthought.
Post reply on HN