5 ms·

This isn't even a macro thing, it just needs trivial use of procedures/methods, and I too have worked with people that are fine copying much larger chunks of co

This isn't even a macro thing, it just needs trivial use of procedures/methods, and I too have worked with people that are fine copying much larger chunks of code around rather than make a new function, and I just don't understand it. It's neater, safer and faster to encapsulate it, and they still don't.

dgb23 5y ago
There are so many things I usually have to do before code organization and abstraction. Figure out how to go from A to B, find out if I really want B, find out if I need to pull this apart into more steps, try variations, read docs to see if there are things that might help me etc. I find it almost always better to write dumb code like this until I it does what it needs doing. It's much more straight forward, in a very literal sense, to find suitable abstraction and compression from there. DRY is about knowledge representation, not about repetition or boilerplate. Solving the former first in a good way lays the foundation for solving the latter, which can then be done with more powerful abstraction tools such as macros.
- tangjurine 5y ago
  I liked abstractions until I had to keep undoing them partially because I didn't perfectly understand the problem I was trying to solve... That's when I would feel the dumbest programming - undoing what was supposed to be me being smart. I think I read somewhere that the worst code comes from the wrong abstractions.
  - zasdffaa 5y ago
    Yeah, write unclever code then refactor. Unless you know the domain well don't try to get smart upfront. I do this repeatedly, pushing the abstraction layer higher on each rewrite. I rarely start out with the abstraction first. [Edit: as the abstraction starts to take shape, it feels 'right' and 'elegant' not at all forced] > I think I read somewhere that the worst code comes from the wrong abstractions. I'd say no, it comes from cut & paste :) seriously
- zasdffaa 5y ago
  > I find it almost always better to write dumb code like this until I it does what it needs doing Same! Then I abstract. But others never get past cut & paste. > DRY is about knowledge representation, not about repetition or boilerplate err, isn't it exactly about not repeating yourself? I mean, for the ultimate aim of representing the thing better, don't repeat it everywhere, ergo encapsulate?
  - dgb23 5y ago
    From the Pragmatic Programmer (coined/popularized the term DRY): "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" To contrast: Data especially can be very repetitive, say you have a bunch of configurations of somewhat similar things, or you have records that represent purchases at a given time of a thing by someone, they will tend to look very similar, maybe even almost the same DRY is not about reducing this kind of repetition, because this is just like it should be. Sure, you might want to generate/automate repetitive things or compress them into something more readable and so on, but that's not what DRY is about. Ultimately it is a form of normalization and decoupling. Ideally you want your code to be in a state so when you change things there is as little coordination required as possible.
    - cestith 5y ago
      DRY really isn't about compressing the data on which your code operates. It's about reducing the number of times your code coordinates the same knowledge about those operations across its text. If you add a field to a record and have to edit the code more than a couple of places to deal with that, you're repeating yourself. If you repeat yourself, those different parts of the code are not only more work to understand and to change, but are more likely to diverge from one another as they are edited in slightly different directions.
    - anamax 5y ago
      > Ultimately it is a form of normalization Yes! Every piece of information that is in two or more places is wrong in at least one of them. That's as true of code as it is of data.
zelphirkalt 5y ago
It can be attributed to one of the following (non-exhaustive list): Lack of experience and knowledge, lack of motivation or work ethics, lack of time to make things neat, lack of care to write readable code, lack of understanding what elegant code is.

dgb23 5y ago

There are so many things I usually have to do before code organization and abstraction. Figure out how to go from A to B, find out if I really want B, find out if I need to pull this apart into more steps, try variations, read docs to see if there are things that might help me etc. I find it almost always better to write dumb code like this until I it does what it needs doing. It's much more straight forward, in a very literal sense, to find suitable abstraction and compression from there. DRY is about knowledge representation, not about repetition or boilerplate. Solving the former first in a good way lays the foundation for solving the latter, which can then be done with more powerful abstraction tools such as macros.

tangjurine 5y ago
I liked abstractions until I had to keep undoing them partially because I didn't perfectly understand the problem I was trying to solve... That's when I would feel the dumbest programming - undoing what was supposed to be me being smart. I think I read somewhere that the worst code comes from the wrong abstractions.
- zasdffaa 5y ago
  Yeah, write unclever code then refactor. Unless you know the domain well don't try to get smart upfront. I do this repeatedly, pushing the abstraction layer higher on each rewrite. I rarely start out with the abstraction first. [Edit: as the abstraction starts to take shape, it feels 'right' and 'elegant' not at all forced] > I think I read somewhere that the worst code comes from the wrong abstractions. I'd say no, it comes from cut & paste :) seriously
zasdffaa 5y ago
> I find it almost always better to write dumb code like this until I it does what it needs doing Same! Then I abstract. But others never get past cut & paste. > DRY is about knowledge representation, not about repetition or boilerplate err, isn't it exactly about not repeating yourself? I mean, for the ultimate aim of representing the thing better, don't repeat it everywhere, ergo encapsulate?
- dgb23 5y ago
  From the Pragmatic Programmer (coined/popularized the term DRY): "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" To contrast: Data especially can be very repetitive, say you have a bunch of configurations of somewhat similar things, or you have records that represent purchases at a given time of a thing by someone, they will tend to look very similar, maybe even almost the same DRY is not about reducing this kind of repetition, because this is just like it should be. Sure, you might want to generate/automate repetitive things or compress them into something more readable and so on, but that's not what DRY is about. Ultimately it is a form of normalization and decoupling. Ideally you want your code to be in a state so when you change things there is as little coordination required as possible.
  - cestith 5y ago
    DRY really isn't about compressing the data on which your code operates. It's about reducing the number of times your code coordinates the same knowledge about those operations across its text. If you add a field to a record and have to edit the code more than a couple of places to deal with that, you're repeating yourself. If you repeat yourself, those different parts of the code are not only more work to understand and to change, but are more likely to diverge from one another as they are edited in slightly different directions.
  - anamax 5y ago
    > Ultimately it is a form of normalization Yes! Every piece of information that is in two or more places is wrong in at least one of them. That's as true of code as it is of data.

zelphirkalt 5y ago

It can be attributed to one of the following (non-exhaustive list): Lack of experience and knowledge, lack of motivation or work ethics, lack of time to make things neat, lack of care to write readable code, lack of understanding what elegant code is.