3 ms·

>Obviously, the cognitive burden becomes greater and greater the more definitions you need to jump through. Who says the cognitive burden is lowered just becau

>Obviously, the cognitive burden becomes greater and greater the more definitions you need to jump through. Who says the cognitive burden is lowered just because of adjacency? If you have to keep N variables in mind, its about the same if they're at current depth or 1 level deep. To me the most evil form of DRY is when you get functions calling functions with arguments that are just passthrough. If a function only uses an argument to call a subfunction, it's a sign that those functions should be decoupled and better orchestrated.

adam_arthur 6y ago
I've found the problem of "too many abstractions" fairly common in functional programming contexts... though not saying it's inherent to the paradigm. Usually it manifests in having tens or hundreds of tiny, stateless functions, with very little logic in each one. There's a common line of thinking about this being "good" because you can "mathematically" prove the correctness of a function, and thus can ignore its implementation. But abstraction is only a big win when the abstraction is easily and widely understood. When you create a one off, ad hoc abstraction its purpose is not going to be obvious to the reader off the bat. The important thing is that the total "api surface area" within your context is low, and each function/abstraction has sufficient meaning. There's a sweet spot where you can fit most of the local functions in your head, without having to constantly re-read to remember the purpose of a given function. Naming is quite important to this end.
hinkley 6y ago
A single level of pass-through may indicate a boundary between two modules. Two layers of pass-through means you have two abstractions talking to each other, which is not good. I'm removing some of these from our code right now. The hard thing to remember about code is, nobody gives a shit about your code when everything is working. Nobody is poring over it basking in your magnificence. If they're looking at your code, it's because something is wrong. So they're looking for wrong things, and they don't know where the wrong thing is. So they're looking at every code smell they see along the way doing a probability calculation. Your ornate clever code causes them to dump important state, such as "why am I looking at this code in the first place?". In the case of argument passing, we're all familiar with argument transposition. I have to check you haven't done it. If you rename variables, I have to watch for that too. If you have a stack of empty methods just ferrying arguments around, you've multiplied the surface area I have to think about.
- maerF0x0 6y ago
  > nobody gives a shit about your code when everything is working So true until the executives are all like "Your team is not performing / low velocity" we're moving your job/team to $CHEAP_COUNTRY

adam_arthur 6y ago

I've found the problem of "too many abstractions" fairly common in functional programming contexts... though not saying it's inherent to the paradigm. Usually it manifests in having tens or hundreds of tiny, stateless functions, with very little logic in each one. There's a common line of thinking about this being "good" because you can "mathematically" prove the correctness of a function, and thus can ignore its implementation. But abstraction is only a big win when the abstraction is easily and widely understood. When you create a one off, ad hoc abstraction its purpose is not going to be obvious to the reader off the bat. The important thing is that the total "api surface area" within your context is low, and each function/abstraction has sufficient meaning. There's a sweet spot where you can fit most of the local functions in your head, without having to constantly re-read to remember the purpose of a given function. Naming is quite important to this end.

hinkley 6y ago

A single level of pass-through may indicate a boundary between two modules. Two layers of pass-through means you have two abstractions talking to each other, which is not good. I'm removing some of these from our code right now. The hard thing to remember about code is, nobody gives a shit about your code when everything is working. Nobody is poring over it basking in your magnificence. If they're looking at your code, it's because something is wrong. So they're looking for wrong things, and they don't know where the wrong thing is. So they're looking at every code smell they see along the way doing a probability calculation. Your ornate clever code causes them to dump important state, such as "why am I looking at this code in the first place?". In the case of argument passing, we're all familiar with argument transposition. I have to check you haven't done it. If you rename variables, I have to watch for that too. If you have a stack of empty methods just ferrying arguments around, you've multiplied the surface area I have to think about.

maerF0x0 6y ago
> nobody gives a shit about your code when everything is working So true until the executives are all like "Your team is not performing / low velocity" we're moving your job/team to $CHEAP_COUNTRY