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

351–360 of 362 posts

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

#351

Post by smaddox »

UK-Al05 wrote: post #280
tekdude wrote: post #224

Earlier quoted context omitted.

From John Carmack: http://number-none.com/blow/blog/programming/2014/09/26/carm...

That's a for a specific case of high performance code and removing duplicated work. Referencing carmwack always has to be in the context of high performance code. Even carmack himself has started like functional code. Which normally leads you down small pure functions.

No, that is not for a specific case of high performance... It's for the non-specific case of keeping the code clear, understandable, and bug-free. The style was chosen for these reasons, not because it is more performant. It just happens to also be more performant than the layers of indirection that also harm understandability.

For a procedural code base, avoid subprocedures that are only called once.

For a pure functional codebase, e.g. Haskell, locally-scoped single-use functions can be beneficial.

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

#352

Post by smaddox »

kvothe_ wrote: post #107
abledon wrote: post #68

Earlier quoted context omitted.

> It's like trying to read a book with each sentence reference a different page. Yes!!! I've been trying to teach Juniors that if the function itself has 4 levels of abstraction, even if the names are readableFunctionThatDoesXwithYSideEffect ..... it is harder to understand, Ctrl+clicking downards into each little mini-rabbit -hole. Just keep the function as a 80-liner, not a 20-liner with 4 levels of indirection w/…

I think you may find it difficult to test an 80 liner... There is way too much happening.

Breaking an 80 line function into to 8x 10 line functions does not necessarily make it easier to test. Most of the time it just adds unit testing busy work, for no clear benefit. This becomes more clear if you imagine you wanted to test every possible input. Splitting the function in 8ths introduces roughly 8x the work, if each new function has the same number of possible input states. The math is more complicated in the general case, so you have to evaluate it on a case-by-case basis. Also, if you're trying to isolate a known bug, it might be beneficial to split the function and test each part in isolation.

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

#353

Post by roguas »

ludocode wrote: post #63
ZephyrBlu wrote: post #51

Earlier quoted context omitted.

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.

I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc. I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.

Variable names are the only thing that can reasonably guide you in time of need. Thinking that variable names are not all that important is not a good take.

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

#354

Post by mbrodersen »

cjfd wrote: post #249

I agree with the sentiment that things should be made as simple as possible. The sine function really has no reason to be anything besides a function. I am not sure, though, that writing the simplest thing possible results in mostly pure functions. In my experience programming is mostly about managing a state. My programming jobs have generally been about tracking what the state of some other piece of hardware and/or…

I recommend watching this talk:

“The Value of Values” https://www.infoq.com/presentations/Value-Values/

It explains what the difference is between state and value and why most (almost all) programs actually have very little state and can be written mostly stateless. It was a big eye opener for me.

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

#356

Post by lenkite »

KronisLV wrote: post #252
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 recently ran into the very same thing. Instead of creating a Spring service to call a repository for data retrieval, i instead called the repository directly, because there was just a single method that needed to be implemented for read-only access of some data. And yet, a colleague said that there should "always" be a service, for consistency with the existing codebase (~1.5M SLoC project). Seeing as the project i…

Yep consistency truly matters, since its likely this won't be the only need for data retrieval and everyone doing their own special thing means the code becomes an unreadable, in-consistent mess that cannot fit in anyones heads and development velocity slows to a crawl.

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

#357

Post by lenkite »

wxd2351 wrote: post #289
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 definitely agree, I've realized that most programming languages store data in a hierarchy (structs within structs) which you then "query" in a very static way with the "." operator. Normalizing data and storing it relationally seems way more flexible for a lot of use cases which is why most databases are relational and not hierarchical. However, I've tried to figure out how to actually store and query data relation…

Could try something like Apache Arrow https://arrow.apache.org/docs/cpp/tables.html

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

#358

Post by Geminidog »

shakow wrote: post #346
Geminidog wrote: post #332

Earlier quoted context omitted.

Yeah technically it's not point free. But technically nothing can truly be point free just like nothing can ever be truly purely functional. In purely functional programming your IO and state has to live somewhere just like how your points in point free programming still have to exist on the function call. A function that takes multiple arguments introduces extra points to your program similar to introducing extra IO…

Don't get me wrong, I rather agree with you on the conceptual side of things; I just wish there was a pretty syntax to do it practically. As you mention them, pipes, for instance, get close to that, and e.g. Elixir uses them to a great result. However, it requires unambiguous priority of the arguments and cooperation & discipline from the librairies authors, so that piping follow the intuitive (and hopefully unambigu…

I wasn't talking about Unix pipes. Apologies. I meant actual pipes. Like sewage piping.

Reread my pipe example but imagine a 2D diagram of physical pipes instead. This is the physical analog of the point free style and the origin of the term when used in unix. The diagram should get around the problem that is caused by the point free style (aka Unix piping) when you use text to represent the concept. In fact this is one of the few times where graphical representations of programming is clearly superior to text.

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

#359

Post by amw-zero »

Geminidog wrote: post #315
amw-zero wrote: post #299

Earlier quoted context omitted.

That doesn’t solve any problem that I have (or anyone has) encountered.

You’re completely right. I’m talking about Technical debt arising from organizational flaws and issues and your statement made me realize this concept doesn’t exist. Nobody has ever dealt with this form of technical debt ever in the history of existence. You’re right, everything I said is completely wrong. I’m not a biased person so I admit when I’m wrong. Also note that this post is not sarcastic. I am 100% serious…

I was talking about your proposed solution, not the problem itself. Point free code does not inherently solve any problems, and it certainly doesn't solve the entire notion of technical debt.

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

#360

Post by Geminidog »

amw-zero wrote: post #359
Geminidog wrote: post #315

Earlier quoted context omitted.

You’re completely right. I’m talking about Technical debt arising from organizational flaws and issues and your statement made me realize this concept doesn’t exist. Nobody has ever dealt with this form of technical debt ever in the history of existence. You’re right, everything I said is completely wrong. I’m not a biased person so I admit when I’m wrong. Also note that this post is not sarcastic. I am 100% serious…

I was talking about your proposed solution, not the problem itself. Point free code does not inherently solve any problems, and it certainly doesn't solve the entire notion of technical debt.

I could say the same for your statement. It doesn't solve any problems. You stated a point and you need to prove your point.

I could just say everything you say is completely and utterly wrong and leave it at that.

Post reply on HN