5 ms·

Lisp macros are really cool. Programming is not satisfying to me without a similar feature. But, most people are happy with just typing and copy pasting stuff

Lisp macros are really cool. Programming is not satisfying to me without a similar feature. But, most people are happy with just typing and copy pasting stuff around. They don't care. I've shown them before and after macro refactoring code comparisons and they just stare blankly, they don't see the point. They code stuff like this on a daily basis: Var stuff() As Stuff stuff.Add(New Stuff("foo")) stuff.Add(New Stuff("bar")) stuff.Add(New Stuff("baz")) And they really don't have a problem with it :)

zasdffaa 4y ago
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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
jstimpfle 4y ago
Macros are the wrong tool here (as in most situations). A macro will only expand to the same bad code. What you want is a function that can do everything what's done on a single line here. For slightly more complex cases, use a list to iterate over and call the function. That will replace (number of lines) function calls by a single one.
- TurboHaskal 4y ago
  Huh, just for clarification, the code I wrote was never intended to be something that was meant to be abstracted away with a macro.
LanceH 4y ago
Twenty years ago when I was trying to explain macros to fellow Java programmers I would say, "what if Java didn't have try/catch/finally, could you add it?" I guess in some theoretical way you could, but the answer is not really. Then I would show them how to use a simple macro I had written for sql statements that would turn a block of statements into a transaction: (sql-tran (statements) (commit) (rollback)) I would point out that only the commit or rollback expressions would execute. It also generated symbols so that these could be nested. At the end of the day, you get code that looks like: (transfer-money amount from-account to-account) and it really feels like cheating because it's all wrapped up in transactions and handles errors without having to see that splattered across the code. Even as a beginner in Lisp I had more and easier code reuse than I've had in any language before or since.
user3939382 4y ago
There's a more abstract/meta-level strategy or philosophy at the heart of this issue that I feel I've progressively gotten more wisdom on. IMHO: DRY has trade-offs like everything else. Code that is very new, maybe built to satisfy business requirements that are still fuzzy, and shifting around a lot, can result in perfectly DRY code returning a net negative cost/benefit. As your requirements solidify and the code matures, the net benefit of DRY code increases, often at a super-linear rate. Going back to your example, I'd say go ahead and copy and paste if and when that strategy fits the scenario, and with the consciousness that you're taking on planned tech debt.
- anamax 4y ago
  I've found more success with DRY2x, that is, it's okay to repeat myself once, but when I run into something three times (second repeat), it's worth of some attention.

zasdffaa 4y ago

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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.

jstimpfle 4y ago

Macros are the wrong tool here (as in most situations). A macro will only expand to the same bad code. What you want is a function that can do everything what's done on a single line here. For slightly more complex cases, use a list to iterate over and call the function. That will replace (number of lines) function calls by a single one.

TurboHaskal 4y ago
Huh, just for clarification, the code I wrote was never intended to be something that was meant to be abstracted away with a macro.

LanceH 4y ago

Twenty years ago when I was trying to explain macros to fellow Java programmers I would say, "what if Java didn't have try/catch/finally, could you add it?" I guess in some theoretical way you could, but the answer is not really. Then I would show them how to use a simple macro I had written for sql statements that would turn a block of statements into a transaction: (sql-tran (statements) (commit) (rollback)) I would point out that only the commit or rollback expressions would execute. It also generated symbols so that these could be nested. At the end of the day, you get code that looks like: (transfer-money amount from-account to-account) and it really feels like cheating because it's all wrapped up in transactions and handles errors without having to see that splattered across the code. Even as a beginner in Lisp I had more and easier code reuse than I've had in any language before or since.

user3939382 4y ago

There's a more abstract/meta-level strategy or philosophy at the heart of this issue that I feel I've progressively gotten more wisdom on. IMHO: DRY has trade-offs like everything else. Code that is very new, maybe built to satisfy business requirements that are still fuzzy, and shifting around a lot, can result in perfectly DRY code returning a net negative cost/benefit. As your requirements solidify and the code matures, the net benefit of DRY code increases, often at a super-linear rate. Going back to your example, I'd say go ahead and copy and paste if and when that strategy fits the scenario, and with the consciousness that you're taking on planned tech debt.

anamax 4y ago
I've found more success with DRY2x, that is, it's okay to repeat myself once, but when I run into something three times (second repeat), it's worth of some attention.