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

271–280 of 362 posts

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

#271

Post by mariusmg »

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…

Well, consistency in itself is a good rule to follow. The problem is , if a bad decision was made at the beginning of the project, maintaining consistency despite that is madness.

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

#272

Post by rednafi »

eyelidlessness wrote: post #110
zamalek wrote: post #70

Earlier quoted context omitted.

> Mostly Python these days, but I try to make it clear and easy read. Which is why I enjoy languages that let me do this without getting too hung up on performance. It's curious that you bring up Python, because idiomatic Python (especially where math libs are concerned) seems to vastly favor brevity/one-liners over all else. It's nice to hear that a veteran is favoring clarity.

> idiomatic Python (especially where math libs are concerned) seems to vastly favor brevity/one-liners over all else I can’t speak to math libs, but in my experience with server-side development, Python devs tend to (often even religiously) cite PEP style guides favoring explicitness and verbosity. I think there may have been a shift as Python got a lot of uptake in scientific and ML communities, and I hope that hasn…

I'm someone who came to the server side of things from the scientific Python community. IMO, that community is still learning how to incorporate Python's best practices to cater their very specific needs.

For example, if you're writing a plotting library geared towards data scientists, you're almost forced to pick brevity over verbosity even if that means violating some of Python's core philosophies. Data scientists usually come from non-compsci backgrounds and almost 90% of the codes they write, don't go to production. So, they usually prefer tools that help them get the job done quickly and they write tools following the same philosophy.

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

#273

Post by ritchiea »

What's the difference between writing OO code that depends on internal state and writing a pure function that expects an argument that is a data structure of a specific type (and thus has internal data that could be different)? Is the pure function no longer pure if the argument is a data structure thats complex and the values within the data structure dictate the outcome of the the function? Or is it a pure function because if you pass the same data structure with the same internal values the function will return the same value?

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

#274

Post by ratww »

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.

You still have to test all the 80 lines if they're broken down into multiple functions, so it's something that you have to evaluate on a case-by-case basis.

It might even make it harder to test: if you break a function wrong, then you might end up with a group of functions that only work together anyway.

For example: when you break a big function into 3 smaller ones. If the first acquires a resource (transaction, file) and the third releases it, then it might be simpler to test the whole group rather than each one separately.

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

#275

Post by richeyryan »

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…

I think its a judgement call to be made. Being consistent with a deliberate architectural decision that is actually useful is important. Otherwise you could potentially have a broken window effect where more and more calls leak out of the service layer with the justification being if it was OK in one place why not others? Putting it in the service means that it is ready for any new calls that might be added and future collaborators know there's generally only one place to look for these calls. Now maybe in this situation it would be overkill but with bigger and longer lived the project, the more consistency pays dividends.

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

#276

Post by radmuzom »

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…

It's sad that a perfectly good and neutral comment is getting down-voted without good responses. Just because it does not agree with the "functional programming is the best" trope.

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

#277

Post by nightcracker »

nightcracker wrote: post #244
m45t3r wrote: post #102

> By "functions" here I mean "pure functions". After programming for Clojure for quite a long time (~2 years), I fully share this sentiment. Using pure functions for business logic (and also using simple data structures instead of, say, classes and encapsulation) seems to generally makes the code more simple and maintainable in the long run. > Of course the qualifier is "mostly": this isn't a dogma. Writing a 100% fu…

For years now I've felt the same way about functional v.s. imperative programming, and where functional languages go 'wrong', and what they get right. There are exceptions of course, but I personally feel that there's three main 'kinds' of code: 1. functions that define some input/output relation 2. query methods on data structures 3. modification methods on data structures 4. the bodies of the above functions In a p…

(can't edit anymore but s/three/four/)

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

#278

Post by laputan_machine »

momokoko wrote: post #69
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 don't always need to have n+1 layers in my architecture where all the layers just call the next layer anyway. This is by far the most common thing I’ve seen consistently in especially difficult to maintain codebases. Anecdotal for sure, but number 2 on that list is way behind. Extra abstractions for a future that has yet to happen and abstractions because the IDE makes it easy to click through the layers is the nu…

Without a doubt this is my biggest issue within the software industry. Massive amounts of indirection & abstraction under the guise of 'DRY'.

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

#279

Post by augustk »

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…

John Ousterhout's "A Philosophy of Software Design" is an interesting alternative to Clean Code.

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

#280

Post by UK-Al05 »

tekdude wrote: post #224
abledon wrote: post #210

Earlier quoted context omitted.

Is there a good blogpost/writeup on this idea? I've seen it mentioned before in other threads.... And i agree 100%

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.

Post reply on HN