3 ms·

100%. A lot of new programmers who didn't program back in the day have been used to this idea with abstractions and "clean code" and that causes so much issues

100%. A lot of new programmers who didn't program back in the day have been used to this idea with abstractions and "clean code" and that causes so much issues these days. Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible. A computer program is an instruction set as you rightly said. It is not a long winded story with many "nouns" (objects).

mochaki 3y ago
[dead]
pixl97 3y ago
>t I am trying and how can I make that happen with the fewest lines of instructions as possible Isn't that the compilers job?
- gwbas1c 3y ago
  The compiler doesn't know how to reduce three database round trips into one database round trip. Modern compilers are awesome, but they still can't read your mind to understand your intent and suggest changes that would objectively change the program, but do what your intent is in a much better way. Perhaps someday artificial intelligence could, but I think that is a long ways off.
- ilrwbwrkhv 3y ago
  The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code.
  - chefandy 3y ago
    > The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code. Human-readable is a spectrum. If something can be more human-friendly while being compacted into an equivalent instruction set at compile time, then what is the benefit of writing extremely terse code?
    - ilrwbwrkhv 3y ago
      Less maintenance the fewer lines of code. While it shouldn't be unreadable, it should be succinct. Basically using abstractions sparingly, letting the data flow through the system and not wrapping things within each other are all great ideas. If you are instantiating a bunch of objects, you can simplify things.
      - chefandy 3y ago
        Maybe there are domains/languages/paradigms where using the smallest possible number of lines to achieve a given compiled instruction set really makes things more efficient, but to me it sounds more like code golf. Using 1 very terse line to accomplish the same thing that 3 readable lines can accomplish should require the same exact amount of maintenance but would be much harder to read and modify.
scubbo 3y ago
> Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible This is true for performance-critical code which will be written once and never modified or reviewed. For "living" code - code in a system which will be updated and extended as it is operating - it is crucial to at least pay attention to the human-readability of your code, in order to improve the efficiency of the future developers. Both extremes of the "inscrutable optimization" and "prolix verbosity" spectrum are incorrect - the correct midpoint is a judgement call.
- blindhippo 3y ago
  It's often debated but in my mind, you know you're talking to a "senior" dev when nearly every response they have to a question is "well, it depends..." Every software project is different since software is a physical manifestation and codification of human process. And human process is... messy as all hell and doesn't like to be constrained by a lot of rules no matter how much effort and management goes into things. So, I prefer to advise teams build software that can be replaced easily, however that works. Isolate the points of change, make the system components replaceable (because they will be), but keep mind of where things need to be focused on efficiency and less on abstraction. This applies to a single code file all the way up to large scale distributed systems. In larger orgs, this helps since inevitably we all fall into the trap of Conway's law, and re-orgs inevitably lead to refactoring of systems along new ownership/communication lines. So, the right way to do something will always conform to the unique situations in which a system is developed -- "it depends"/
  - agentultra 3y ago
    I think abstraction is key to efficiency. In order to have efficient systems we need to be able to prove properties of the software we write are correct with regards to our specifications. This is what abstractions do for us: they enable us to think in new semantic layers that are precise in the mathematical sense. This isn’t my idea, I just agree wholeheartedly with Conal Eliot. Resiliency is what we get when we want reliable systems but we cut corners with proving the correctness of the software we write: we add process supervisors, memory managers, tooling, exception handlers, etc: things that all cost us some efficiency in order to make our systems reliable enough to be useful. If we want efficiency, at scale, we need tools (languages really) that allow us to write proofs and generate code from these specifications.

mochaki 3y ago

[dead]

pixl97 3y ago

>t I am trying and how can I make that happen with the fewest lines of instructions as possible Isn't that the compilers job?

gwbas1c 3y ago
The compiler doesn't know how to reduce three database round trips into one database round trip. Modern compilers are awesome, but they still can't read your mind to understand your intent and suggest changes that would objectively change the program, but do what your intent is in a much better way. Perhaps someday artificial intelligence could, but I think that is a long ways off.
ilrwbwrkhv 3y ago
The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code.
- chefandy 3y ago
  > The compilers job is to turn source code into machine code. You are still writing human readable source code. I am not suggesting we start writing everything in numeric machine code. Human-readable is a spectrum. If something can be more human-friendly while being compacted into an equivalent instruction set at compile time, then what is the benefit of writing extremely terse code?
  - ilrwbwrkhv 3y ago
    Less maintenance the fewer lines of code. While it shouldn't be unreadable, it should be succinct. Basically using abstractions sparingly, letting the data flow through the system and not wrapping things within each other are all great ideas. If you are instantiating a bunch of objects, you can simplify things.
    - chefandy 3y ago
      Maybe there are domains/languages/paradigms where using the smallest possible number of lines to achieve a given compiled instruction set really makes things more efficient, but to me it sounds more like code golf. Using 1 very terse line to accomplish the same thing that 3 readable lines can accomplish should require the same exact amount of maintenance but would be much harder to read and modify.

scubbo 3y ago

> Instead the mental model should be how does the computer achieve the thing that I am trying and how can I make that happen with the fewest lines of instructions as possible This is true for performance-critical code which will be written once and never modified or reviewed. For "living" code - code in a system which will be updated and extended as it is operating - it is crucial to at least pay attention to the human-readability of your code, in order to improve the efficiency of the future developers. Both extremes of the "inscrutable optimization" and "prolix verbosity" spectrum are incorrect - the correct midpoint is a judgement call.

blindhippo 3y ago
It's often debated but in my mind, you know you're talking to a "senior" dev when nearly every response they have to a question is "well, it depends..." Every software project is different since software is a physical manifestation and codification of human process. And human process is... messy as all hell and doesn't like to be constrained by a lot of rules no matter how much effort and management goes into things. So, I prefer to advise teams build software that can be replaced easily, however that works. Isolate the points of change, make the system components replaceable (because they will be), but keep mind of where things need to be focused on efficiency and less on abstraction. This applies to a single code file all the way up to large scale distributed systems. In larger orgs, this helps since inevitably we all fall into the trap of Conway's law, and re-orgs inevitably lead to refactoring of systems along new ownership/communication lines. So, the right way to do something will always conform to the unique situations in which a system is developed -- "it depends"/
- agentultra 3y ago
  I think abstraction is key to efficiency. In order to have efficient systems we need to be able to prove properties of the software we write are correct with regards to our specifications. This is what abstractions do for us: they enable us to think in new semantic layers that are precise in the mathematical sense. This isn’t my idea, I just agree wholeheartedly with Conal Eliot. Resiliency is what we get when we want reliable systems but we cut corners with proving the correctness of the software we write: we add process supervisors, memory managers, tooling, exception handlers, etc: things that all cost us some efficiency in order to make our systems reliable enough to be useful. If we want efficiency, at scale, we need tools (languages really) that allow us to write proofs and generate code from these specifications.