Write code. Not too much. Mostly functions. • Hacker News Board

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

#181

Post by redisman » Tue, Dec 22, 2020, 4:49 AM UTC

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 nouns of programming though. It’s not really related but I think having an “editor” try to read your text and give you improvement ideas is not “shallow”. The code is there for programmers to read and reason about so optimizing for “easy to load into your brain” code is important too.

let c = ... versus let customer_address = ... can save a lot of sanity throughout the years

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

#182

Post by [deleted] » Tue, Dec 22, 2020, 4:54 AM UTC

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…

[deleted]

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

#183

Post by Ar-Curunir » Tue, Dec 22, 2020, 4:54 AM UTC

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.

useful variable names are absolutely a win though

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

#184

Post by cxr » Tue, Dec 22, 2020, 4:55 AM UTC

slaymaker1907 wrote: post #175

Ma8ee wrote: post #153

Earlier quoted context omitted.

On the other hand, no abstractions is like reading a book where each and every thing is spelled out in outmost detail. Instead of telling you “I’m fuelling the car”, I’ll tell you: “I’m walking to the entrance hall. I’m picking up the car keys. I’m putting on my shoes. I’m putting on my jacket. I’m unlocking the front door ...”. You see where this is going. And here we already assumed that things like “putting on sho…

The one caveat is that I want to easily be able to find out what fuel() is doing. Preferably nothing like car.getService('engine').run('fueling'). Code navigation is very important, preferably doable via ctrl+f since that makes review easier. Most people just use the browser tools for reviewing code and don't actually pull the branch into their IDE.

You're asking for code that passes The Grep Test:

http://jamie-wong.com/2013/07/12/grep-test/

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

#185

Post by ellis-bell » Tue, Dec 22, 2020, 4:57 AM UTC

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…

hah i was taught that style is "pointless"...

it comes from topology, no?

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

#186

Post by bcrosby95 » Tue, Dec 22, 2020, 4:57 AM UTC

ellis-bell wrote: post #180

momokoko wrote: post #69

Earlier quoted context omitted.

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

Incidentally one of the biggest benefits I see of using a text editor like vim / emacs is that it really encourages good code management. It's not to save the ~10 minutes per year in faster key strokes to manipulate your code. It's about the way it shapes your thinking about how you code.

I agree to some extent.

After using Intellij for about 5 years I switched to a less batteries-included code editor (currently doom emacs). I figure if I need an IDE to navigate our code as a senior developer on the project then less experienced ones don't stand much of a chance.

I still use Intellij for refactoring.

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

#187

Post by dathinab » Tue, Dec 22, 2020, 5:00 AM UTC

> In my experience most codebases have a pure functional subset, and I believe writing that subset in a pure-functional style is nearly always a win for the long-term health of the project.

I came to the same conclusion ~1 year ago when writing rust.

It's pretty common to have some "high level" method in rust then you split it up, some small parts go into other maybe private methods but a lot goes into split out functions (through this depends on the task, and sometimes could be made into methods if rust would support partial self-borrows).

The only think which sometimes bothers me with that approach is where to place this split out methods. As long as I don't need their functionality in other places I want them to be keep close to the function because of which they exist. But they are function and not methods so placing them in the `impl` block isn't right. Alternatively making them free functions in the method using them seems better but also isn't quite right as this "blows" up the method...

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

#188

Post by risfriend » Tue, Dec 22, 2020, 5:04 AM UTC

monocasa wrote: post #86

momokoko wrote: post #69

Earlier quoted context omitted.

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

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…

From where I am, there are abstractions coded for APIs in the layers of - topmost API layer, then Business logic and the 3rd DAO layer. Even though there is only one implementation everytime of these layers, this structuring alone has helped maintaining the code so much easier, as everyone even across teams goes by this structure while defining any API. Can't even imagine just coding functions in large codebases without a pre-defined structure, it can become brittle over time.

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

#189

Post by Geminidog » Tue, Dec 22, 2020, 5:05 AM UTC

redisman wrote: post #178

carapace wrote: post #120

Earlier quoted context omitted.

I've been playing with Joy (concatinative, combinator-based) and I have to agree. So far everything I've translated into Joy has been more elegant and easier to understand. Conal Elliott's "Compiling to categories" is one way in: http://conal.net/papers/compiling-to-categories/

Any paradigm can look clean when you’re playing. Work on it for a year and then have management tell you that we must add a feature that breaks your core design because our big client needs it.

Many aspects of a programming language can make it nasty or hard to use under certain contexts. This is something most programmers are aware of through experience.

My point is, that the use of combinators and point free programming formally eliminates organizational technical debt. So for this specific issue, Joy should indeed be better by logic.

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

#190

Post by wruza » Tue, Dec 22, 2020, 5:06 AM UTC

Ma8ee wrote: post #153

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…

On the other hand, no abstractions is like reading a book where each and every thing is spelled out in outmost detail. Instead of telling you “I’m fuelling the car”, I’ll tell you: “I’m walking to the entrance hall. I’m picking up the car keys. I’m putting on my shoes. I’m putting on my jacket. I’m unlocking the front door ...”. You see where this is going. And here we already assumed that things like “putting on sho…

Still lacking good tools in our own toolbox. If ides could expand function calls inline (not a header in a glassbox, but right in code), both worlds could benefit from that. Expand all calls depth 2 and there is a detailed picture. Collapse branches at edit-time based on passed flags/literals and there is your specific path.