6 ms·

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

by Ma8ee 6y ago

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 shoes” are provided by a standard library. There seems to be two types of programmers: one that can read a line of code like or theCar.fuel() and trust that you in the current context understand enough of what the call does that you can continue reading on the current level of code. This type of programmers don’t mind abstractions even if a function is called in only one place. The other type of programmer must immediately dig into the car.fuel code and make sure she understands that functionality before she can continue. And of course then each and every call becomes a misdirection from understanding the code, and of course for them it is better is everything is spelled out on the same level. I’ve seen quite a bit of code written by the second type of programmers, and if you don’t mind scrolling and don’t mind reading the comment chapter headers (/* here we fuel the car */) instead of all the code itself, it can be reasonably readable. But there’s never comprehensive testing coverage for this kind of code, and there’s usually code for fuelling the car in four different places because programmers 2-4 didn’t have time to read all the old code to see if there was something they could reuse, and just assumed that no one had to fuel the car before since there wasn’t any car.fuel() method.

x0054 6y ago
Not sure why you are down voted, I completely agree.
slaymaker1907 6y ago
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.
- cxr 6y ago
  You're asking for code that passes The Grep Test: http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/
wruza 6y ago
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.
- IggleSniggle 6y ago
  Hmm. There’s a vim sequence to accomplish this that you could macro. But even so, don’t most IDEs give you somewhat more than a glassbox header? I’m almost certain I’ve seen people scrolling and even editing code in the “glassbox” preview pane in VSCode.
  - wruza 6y ago
    Afair, it doesn’t inline and overlaps with the code behind it. If that is not true, it may be closer to it, but my experiments somehow failed to show its benefits over “just open to the right pane”. Maybe I should check its config thoroughly. As a vim user, I’m interested in a method you described, is it handmade :read/%v%yp-like thing or an existing plugin?
IggleSniggle 6y ago
I have had the good fortune to have never worked in a codebase with the characteristics you describe. But I have seen some issues with theCar.fuel(), and that’s generally around mutability and crazy side-effects. I think most of these are pragmatically overcome by adoption of functional paradigms and function composition over inheritance or instance methods.
watwut 6y ago
I agree. This whole discussion prefering long functions seems like advocacy for bad code to me. It is just ... I have seen both types of code and if written by someone else, coffee that at least attempt to segment things into chunks that clearly don't influence each other (functions with local variablea) is massively easier to read.
- IggleSniggle 6y ago
  I think it’s honestly just folks talking past each other because these situations are isolated judgement calls, and some folks feel that // #1, in essence result = a => map => reduce => transform is easier to read and understand, while others feel that // #2, in essence aThing = a => map aggregation = aThing => reduce result => aggregation => transform is easier to read and understand. Folks in camp #1 think camp #2 is creating too much abstraction by naming all the data each step of the way, and camp #2 thinks camp #1 is creating too much abstraction by naming all the functions each step of the way. Really it’s just these two mental modalities butting up against each other, because you will separate your layers in different ways for increased clarity depending on which camp you fall into. What makes things clearer for camp #1 makes things less clear for camp #2, and vice versa. That’s my suspicion anyway: the premise of the discussion is just a little off.
sethammons 6y ago
Then you have an electric car, and you use the fuel method and add a special case for isElectric handling inside. And some other dev uses lamp.fuel since it already handled isElectric internally. But later, we have to differentiate between different types of charging and battery vs constant AC and DC power. Then someone helpfully reorganizes the code and breaks car.fuel because the car does have a battery too. And then ....
- Ma8ee 6y ago
  No, you don’t. And the alternative implementation is that you either go through all code where car is used and add conditionals for all the cases where kind of fuel matters. Or is very common for this kind of programming, just copy the whole car.roadTrip() where fuel is called and to the method electricCar.roadTrip and just change a few lines. Then of course all requirement changes or bug fixes must be done in several places thereafter. My feelings about people that can’t handle abstractions is that they just don’t have had to create or maintain anything complex. Very few real world systems can be kept in ones mind in full.

by Ma8ee 6y ago

x0054 6y ago

Not sure why you are down voted, I completely agree.

slaymaker1907 6y ago

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.

cxr 6y ago
You're asking for code that passes The Grep Test: http://jamie-wong.com/2013/07/12/grep-test/ http://jamie-wong.com/2013/07/12/grep-test/

wruza 6y ago

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.

IggleSniggle 6y ago
Hmm. There’s a vim sequence to accomplish this that you could macro. But even so, don’t most IDEs give you somewhat more than a glassbox header? I’m almost certain I’ve seen people scrolling and even editing code in the “glassbox” preview pane in VSCode.
- wruza 6y ago
  Afair, it doesn’t inline and overlaps with the code behind it. If that is not true, it may be closer to it, but my experiments somehow failed to show its benefits over “just open to the right pane”. Maybe I should check its config thoroughly. As a vim user, I’m interested in a method you described, is it handmade :read/%v%yp-like thing or an existing plugin?

IggleSniggle 6y ago

I have had the good fortune to have never worked in a codebase with the characteristics you describe. But I have seen some issues with theCar.fuel(), and that’s generally around mutability and crazy side-effects. I think most of these are pragmatically overcome by adoption of functional paradigms and function composition over inheritance or instance methods.

watwut 6y ago

I agree. This whole discussion prefering long functions seems like advocacy for bad code to me. It is just ... I have seen both types of code and if written by someone else, coffee that at least attempt to segment things into chunks that clearly don't influence each other (functions with local variablea) is massively easier to read.

IggleSniggle 6y ago
I think it’s honestly just folks talking past each other because these situations are isolated judgement calls, and some folks feel that // #1, in essence result = a => map => reduce => transform is easier to read and understand, while others feel that // #2, in essence aThing = a => map aggregation = aThing => reduce result => aggregation => transform is easier to read and understand. Folks in camp #1 think camp #2 is creating too much abstraction by naming all the data each step of the way, and camp #2 thinks camp #1 is creating too much abstraction by naming all the functions each step of the way. Really it’s just these two mental modalities butting up against each other, because you will separate your layers in different ways for increased clarity depending on which camp you fall into. What makes things clearer for camp #1 makes things less clear for camp #2, and vice versa. That’s my suspicion anyway: the premise of the discussion is just a little off.

sethammons 6y ago

Then you have an electric car, and you use the fuel method and add a special case for isElectric handling inside. And some other dev uses lamp.fuel since it already handled isElectric internally. But later, we have to differentiate between different types of charging and battery vs constant AC and DC power. Then someone helpfully reorganizes the code and breaks car.fuel because the car does have a battery too. And then ....

Ma8ee 6y ago
No, you don’t. And the alternative implementation is that you either go through all code where car is used and add conditionals for all the cases where kind of fuel matters. Or is very common for this kind of programming, just copy the whole car.roadTrip() where fuel is called and to the method electricCar.roadTrip and just change a few lines. Then of course all requirement changes or bug fixes must be done in several places thereafter. My feelings about people that can’t handle abstractions is that they just don’t have had to create or maintain anything complex. Very few real world systems can be kept in ones mind in full.