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

131–140 of 362 posts

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

#131

Post by eyelidlessness »

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?

That’s not what I took from it, but even if that’s what was meant, I think I’d have the same reaction. In terms of abstraction implementations, a class is just a different expression of the same idea of encapsulation.

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

#132

Post by runald »

nomel wrote: post #44
bitexploder wrote: post #37

Earlier quoted context omitted.

As I get older my code gets a little more verbose and a little less idiomatic to the language I am writing. I’ve been writing code, starting with C, since 95. Mostly Python these days, but I try to make it clear and easy read. Mostly for myself. Future me is always happy when I take the time to comment my overarching goals for a piece of code and make it clean and well composed with enough, but not too many, function…

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

If you are comparing reading code with reading books, then surely you have read books that have unfamiliar words that you have to lookup the definition, and then you might have to recursively lookup the unfamiliar words in the definition as well. Then when you internalized the sub-definitions, then you return to what you were reading and have a better understanding.

The difference between code and books is that programmers can freely and naturally define functions. I wonder if some people complaining about too many functions never actually learned how to read code in the first place.

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

#133

Post by dragonwriter »

eyelidlessness wrote: post #130
m45t3r wrote: post #122

Earlier quoted context omitted.

I didn't say anything about types, but we use plumatic/schema as a "type system". It is not ideal (for once, it is checked at runtime instead of build time, so we only check types during tests and requests, otherwise the impact would be too great). It is not ideal, but it works and keeps our sanity.

Yeah something like that is essential in a dynamic language. To be honest though I don’t think I could go back to runtime-only type checking and having to write those tests where a compiler tests so much automatically.

> where a compiler tests so much automatically

Compilers don't necessarily check anything. Static analysis tools (including static type checkers) check things, and some compilers also include static analysis tools. But static analysis tools are often available beyond whatever a compiler provides.

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

#135

Post by brundolf »

Matheus28 wrote: post #121
cjohnson318 wrote: post #116

So, I have a question. I have a kind of serial number, and different systems expect slightly different formats. One system likes dashes, one doesn't, one system likes an extra two digits, while another system likes an extra four numbers. Should I write around n(n-1)/2 pure function converters between n systems? Or one class with n methods? (If you're curious, I'm talking about oil well API numbers. It's not rocket sc…

If you REALLY have to use all these different formats, I'd have one canonical one used everywhere in your app, and 2n methods to convert to different ones at api boundaries.

I'd have one canonical one used everywhere, and 2n pure functions to convert at API boundaries. By making them pure functions you guarantee (or at least suggest by convention; depending on your language's type system) that those conversions will have no side-effects. As methods, you can never be sure as the caller whether there will be ramifications to calling them in new places.

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

#136

Post by tonymet »

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…

I recommend using more than sql tables for data modeling

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

#137

Post by shakow »

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…

IME, the limitations of this recommendation appear when one needs to combine multiple functions taking multiple arguments, some being fixe and some other not.

Although they are mostly syntactic, they hamper the readability of the resulting code.

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

#138

Post by rajangdavis »

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.

I could be wrong, but I take it to mean that the function shouldn't necessarily depend on the arguments that are passed in. Rather, you focus on a set of procedures that are independent of the number of arguments and can act on them.

I think it's similar to the concept of Variadic functions(https://en.wikipedia.org/wiki/Variadic_function)

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

#139

Post by yowlingcat »

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…

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

I'm with you here...

> The actual solution to the above problem is to use point free combinators as much as possible in your code.

You lost me here. Perhaps if you're working in a problem space with high complexity, little ambiguity and hard performance requirements (fairly rare in my experience), you might get mileage here.

Otherwise, functional programming techniques are somewhat orthogonal to Conway's law. Point-free combinators don't stop new information about customers from completely altering your domain model, business logic and how your data is stored at rest.

I think it's helpful to realize that some of the root causes of bit-rot in a codebase are more closely tied to not fully knowing what was going to evolve into ahead of time, which in and of itself isn't a bad thing. However, it means that it's a failure mode that is independent and often out of the hands of the engineer writing the code -- functional programming idioms or not.

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

#140

Post by trylist »

bob1029 wrote: post #101
FpUser wrote: post #26

Earlier quoted context omitted.

>"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 agree with this part assuming that graphics and video along with the words are allowed. >"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 prob…

I think you may underestimate the potential scope of a domain model and the capabilities of SQL. It is certainly math. That is actually the incredible part. That its all just math underneath 20 different joins which express a very complex and meaningful view of the domain facts. I challenge anyone to present a problem domain which cannot be meaningfully represented in terms of tables in a database. I would prefer if…

Hierarchies are possible with an RDBMS, but I'd suggest it's the wrong tool to model them with, unless they're static of course. Really any graph that can't be encoded in the table relationships themselves.
Post reply on HN