12 ms·

I think most people prefer languages that let them think about the problem they are trying to solve, rather than think about what the macros expand to, or what

by emfle 18y ago

I think most people prefer languages that let them think about the problem they are trying to solve, rather than think about what the macros expand to, or what happens when they call that continuation.

gruseom 18y ago
Sure. Nobody would ever write a macro to solve a problem. No wait: on second thought, I surrender to how completely dumbfounded I am by this comment. I'm calling Kenny...
- emfle 18y ago
  The point is that "requires you to think" is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.
  - gruseom 18y ago
    So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub http://www.google.com/search?q=blub
    - emfle 18y ago
      I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder. No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.
      - gruseom 18y ago
        As far as I can tell, you're talking about your experience of what's easier and harder. Your experience is not "the brain". Certainly if you're habituated to the object-model style of programming, other forms of abstraction may seem weird. The irony here is that twenty years ago, the people making your kind of argument were directing it all against objects. As a side note, treating programming objects as if they were physical objects works as long as there's a good fit between the two. As soon as you need the objects to behave in ways that physical objects don't (and believe me, in any complex OO system, you will), you find yourself tied up in knots that it will take a lot of thinking to extricate yourself from. (Speaking of complexity that isn't intrinsic to the problem...) Not accidentally, the tools that people reach for then tend to be ersatz versions of metaprogramming (reflection, code generation), and Greenspun is off to the races...
      - KirinDave 18y ago
        "I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder." It's not. It's just a matter of practice. Most people find OO modeling natural (even when it is extremely tortured and difficult) because they've acquired a comfort with it born of many hours of practice. You might argue that you're not referring to familiarity with the paradigm, but I think you are, and don't realize it. I assure you that a functional style has equal power to abstract as a OO style. You're right, our brains have a good ability to think of things as sets of objects. But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities.
        emfle 18y ago
        I am familiar with functional programming. In fact, for some reason recursion and higher-order functions always seemed easy to me (unlike pointers and virtual methods), but I think that's a quirk of my brain. Many other people seem to have a lot of trouble with the idea that you can just make a recursive call and trust that it's going to do what it is supposed to. Not me personally, though. But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities. Linguistic processing does require more cognitive effort, especially when it involves something like a macro that can change the context in which it is invoked. For exactly the same reason, most people are more productive with a graphical user interface than with a command-line one. This is directly related to the fact that abstract linguistic processing is more difficult than manipulation of the tangible, physical objects you find in a GUI.
pchristensen 18y ago
Or what happens in that subroutine. Or the performance characteristics of that library. Or the fencepost cases of a loop. Or which exceptions to handle. ...
Hexstream 18y ago
Maybe it's just because I've been using Common Lisp exclusively for a year, but what's so hard about macros? Especially, using them (as opposed to writing them). You don't have to think about how the macro is written or what it's expanding into when you use it, you just have to know the semantics of the macro. "When I pass such and such, it will produce code that evaluates this in that way". Similar to a function or a language primitive right? If you're writing a for loop in Java, do you have to care how it's implemented in the JVM?! As for writing macros: you're writing a function that takes an AST and returns an AST to use as replacement. This function will be called at compile-time to change your nice high-level macro call into lower-level code. There are a couple pitfalls (variable capture, multiple evaluation) but they're always the same and you'll learn about them quickly enough that it will become a sixth sense.
- tokipin 18y ago
  right. to me macros are just a different style of function. i don't see why people would be spooked by them

by emfle 18y ago

gruseom 18y ago

Sure. Nobody would ever write a macro to solve a problem. No wait: on second thought, I surrender to how completely dumbfounded I am by this comment. I'm calling Kenny...

emfle 18y ago
The point is that "requires you to think" is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.
- gruseom 18y ago
  So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me. Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it? http://www.google.com/search?q=blub http://www.google.com/search?q=blub
  - emfle 18y ago
    I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder. No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.
    - gruseom 18y ago
      As far as I can tell, you're talking about your experience of what's easier and harder. Your experience is not "the brain". Certainly if you're habituated to the object-model style of programming, other forms of abstraction may seem weird. The irony here is that twenty years ago, the people making your kind of argument were directing it all against objects. As a side note, treating programming objects as if they were physical objects works as long as there's a good fit between the two. As soon as you need the objects to behave in ways that physical objects don't (and believe me, in any complex OO system, you will), you find yourself tied up in knots that it will take a lot of thinking to extricate yourself from. (Speaking of complexity that isn't intrinsic to the problem...) Not accidentally, the tools that people reach for then tend to be ersatz versions of metaprogramming (reflection, code generation), and Greenspun is off to the races...
    - KirinDave 18y ago
      "I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder." It's not. It's just a matter of practice. Most people find OO modeling natural (even when it is extremely tortured and difficult) because they've acquired a comfort with it born of many hours of practice. You might argue that you're not referring to familiarity with the paradigm, but I think you are, and don't realize it. I assure you that a functional style has equal power to abstract as a OO style. You're right, our brains have a good ability to think of things as sets of objects. But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities.
      - emfle 18y ago
        I am familiar with functional programming. In fact, for some reason recursion and higher-order functions always seemed easy to me (unlike pointers and virtual methods), but I think that's a quirk of my brain. Many other people seem to have a lot of trouble with the idea that you can just make a recursive call and trust that it's going to do what it is supposed to. Not me personally, though. But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities. Linguistic processing does require more cognitive effort, especially when it involves something like a macro that can change the context in which it is invoked. For exactly the same reason, most people are more productive with a graphical user interface than with a command-line one. This is directly related to the fact that abstract linguistic processing is more difficult than manipulation of the tangible, physical objects you find in a GUI.

pchristensen 18y ago

Or what happens in that subroutine. Or the performance characteristics of that library. Or the fencepost cases of a loop. Or which exceptions to handle. ...

Hexstream 18y ago

Maybe it's just because I've been using Common Lisp exclusively for a year, but what's so hard about macros? Especially, using them (as opposed to writing them). You don't have to think about how the macro is written or what it's expanding into when you use it, you just have to know the semantics of the macro. "When I pass such and such, it will produce code that evaluates this in that way". Similar to a function or a language primitive right? If you're writing a for loop in Java, do you have to care how it's implemented in the JVM?! As for writing macros: you're writing a function that takes an AST and returns an AST to use as replacement. This function will be called at compile-time to change your nice high-level macro call into lower-level code. There are a couple pitfalls (variable capture, multiple evaluation) but they're always the same and you'll learn about them quickly enough that it will become a sixth sense.

tokipin 18y ago
right. to me macros are just a different style of function. i don't see why people would be spooked by them