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

231–240 of 362 posts

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

#231

Post by enneff »

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…

The React model is actually superb at managing state. It makes you explicitly acknowledge it directly, and codifies it either with properties or useState. In practice it's a fantastic model, as it does let you write "mostly functions" as the article suggests, but you can't have a UI without state, so it's great that they make it easy to handle.

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

#232

Post by enneff »

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 grandfather wrote BASIC programs for the TRS-80, so I'm not sure I would necessarily agree with that sentiment. :)

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

#233

Post by njanirudh »

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…

Unfortunately modern coding interview and general culture has made it a "technical know how d measuring contest".

I have seen juniors use all data structures and design patterns regardless of it actually fits correctly or not

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

#234

Post by [deleted] »

eyelidlessness wrote: post #103
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…

I’m curious why three call sites isn’t sufficient. Any time I find I have three instances of the same non-trivial logic, I immediately think of whether there’s a sensible function boundary around it, and whether I can name it. If I can, it’s a good candidate. Obviously for trivial logic that’s less appealing. And obviously all the usual abstraction caveats (too many options or parameters are a bad sign, etc) apply. T…

[deleted]

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

#235

Post by bcrosby95 »

plasticchris wrote: post #129
eyelidlessness wrote: post #103

Earlier quoted context omitted.

I’m curious why three call sites isn’t sufficient. Any time I find I have three instances of the same non-trivial logic, I immediately think of whether there’s a sensible function boundary around it, and whether I can name it. If I can, it’s a good candidate. Obviously for trivial logic that’s less appealing. And obviously all the usual abstraction caveats (too many options or parameters are a bad sign, etc) apply. T…

Abstraction here likely means more than a function - maybe something like an interface base class?

Probably. When talking about object oriented programs, "abstraction" is oftentimes used as a placeholder for "abstract class" as opposed to a "concrete class". You can see this at play when talking about the SOLID principles and when you get to the "D" part people want to turn every class into an interface because it says you must "depend upon abstractions, not concretions".

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

#236

Post by anchpop »

brundolf wrote: post #218
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.

I use hooks because they cut down on boilerplate, not because I'm trying to pretend a component is just a function.

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

#237

Post by mjfisher »

gcpwnd wrote: post #92
dcolkitt wrote: post #57

Earlier quoted context omitted.

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.

Yes context switching is a huge cognitive load. Abstractions enforce context switching.

The primary motivating reason to have abstractions in the first place is to prevent context switching - i.e. you shouldn't have to think about networking code while you're writing business logic.

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

#238

Post by felixyz »

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.

This talk is an excellent, very accessible introduction to point free style and some of its tradeoffs:

"Point-Free or Die: Tacit Programming in Haskell and Beyond" by Amar Shah

https://www.youtube.com/watch?v=seVSlKazsNk

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

#239

Post by atoav »

redisman wrote: post #150
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…

I think setting hard limits on design is a good thing. Creativity needs limits. If your limits can imply something about your desired design goals then that’s a good synergy. It also forces the engineers to think more about design rather than fall back on their goto pattern that may or may not fit the problem. Especially junior and mid level engineers might not have good heuristics on is their design any good or is i…

I think a good programmer should have an "intuition" whether it is worth to build an abstraction for something or not. If in doubt don't do it.

If in hindsight your intuition fooled you constantly, adjust it.

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

#240

Post by atoav »

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 think functions are a good enough abstraction for many things. A few years ago I tended to make everything a class in Python. Nowadays I rarely need more than functions. Learning Rust made me realize just how arbitrary my aesthetical ideas about code where. When I tried to go the class based object oriented route in Rust it failed spectacularly because I was unable to navigate the maze of ownership in no time. Once I let go of these ideas everything became incredibly straightforward. The spell has been broken.

That being said I think module borders have become more important to me. Keep seperated what is meant to be seperated.

Post reply on HN