4 ms·

> These are the people who don't know any better, arguing out of ignorance, not from some valid ground. That's very unfair. Let's take Lisp-style macros. There

> These are the people who don't know any better, arguing out of ignorance, not from some valid ground. That's very unfair. Let's take Lisp-style macros. There are good arguments against macros in programming languages. For example, keeping the amount of primitives small and core language simple. I don't agree with these arguments (I am pro-macros), but it's not just ignorance. > I do not see any extensibility features in Python, none at all. Not sure what you mean, but macros are not the only way to extend a programming language. One particularly common method is called "functions" (if you have ever coded in assembler, you will know what luxury that is). Then you have classes, operator overloading, metaclasses, decorators, native C interface, AST parser in the standard library.. Not sure what more, aside from macros, you could want regarding extensibility. Python is more extensible than C and Java, which are the most common programming languages in use.

dragonwriter 11y ago
> Let's take Lisp-style macros. There are good arguments against macros in programming languages. For example, keeping the amount of primitives small and core language simple. Wait, that's the argument for including Lisp-style macros as a primitive feature of the language: by doing that, you reduce the number of primitives needed, keeping the number of primitives small and the core language simple. With macros, you can have fewer primitive control structures in the core language, and build other control structures that are desired on top of the existing ones + macros. So, while there may be arguments for keeping macros out of programming langauges, the one you've presented is, instead, pretty much the main argument for having Lisp-style macros.
- asgard1024 11y ago
  I don't want to get into this discussion, because, as I said, I disagree with these arguments; I just wanted to point out they exist and are valid. Anyway, I already outlined the argument in another of my comments, where I talk about set theory and integrals - the "axiomatic" primitives are different bunch than "useful" primitives. So trying to keep language small may lead to different decisions based on which primitives you want to keep. So for instance (as a simple example) map and filter can be built with recursion, but why bother with learning how to do it, if I can just call them from the standard library? (Or in case of Python, use generator comprehension.) Another example would be complaint below, that Python doesn't have proper closures. Valid complaint or not, Python has classes, and you can pretty much build one from the other.
  - sklogic 11y ago
    > they exist and are valid. Uhm, no, so far not a single valid non-straw-man argument against macros. It's important to mention that macros do not affect the rest of the language design choices in any way whatsoever. The underlying language can be literally anything, macros can be added on top of any imaginable combination of design decisions. In case of a python-like language, see Converge, for example.
    - asgard1024 11y ago
      > It's important to mention that macros do not affect the rest of the language design choices in any way whatsoever. I think you're wrong. It affects how people use the language, and how the community develops around it, and other things. Perhaps if people would use macros as a sort of last resort thing, then it wouldn't matter, but from my experience, they don't. It's probably most visible in the Forth community - every implementation of Forth is subtly different from the others, and by design! Chuck Moore even said that the Forth standard goes against the very idea of Forth. I now work on a large codebase in language with macros (SAS), and while it's powerful, it also causes problems; the code where any calculation can take place during compilation is harder to read, sometimes, and they cannot be easily translated to other language, for example. The truth is, the programming community moved from macros, which are powerful and easy to implement, to other abstractions, less powerful but more specific to problems that people usually face (such as OOP). Many languages from 70s and 80s had macros, but today it's not so common. This transition is a little bit similar to transition from imperative to functional style, which will probably happen in the future.
      - sklogic 11y ago
        > It affects how people use the language, and how the community develops around it, and other things. It affects the use (in very positive way), but does not affect the design. But, what is true, is that a majority of people using macros do not understand how to do it properly and do not follow the right discipline. What is needed is to promote such discipline instead of spreading lies that "macros are dangerous". And no, there is a very strong trend back to metaprogramming at the moment: Julia, C++, D, Clojure, Rust, all that stuff. All the other methods of implementing abstractions (OOP and the other pathetic things) have a very pronounced maximum of the level of abstraction, while there is no limit when metaprogramming is used to implement hierarchies of eDSLs.

dragonwriter 11y ago

> Let's take Lisp-style macros. There are good arguments against macros in programming languages. For example, keeping the amount of primitives small and core language simple. Wait, that's the argument for including Lisp-style macros as a primitive feature of the language: by doing that, you reduce the number of primitives needed, keeping the number of primitives small and the core language simple. With macros, you can have fewer primitive control structures in the core language, and build other control structures that are desired on top of the existing ones + macros. So, while there may be arguments for keeping macros out of programming langauges, the one you've presented is, instead, pretty much the main argument for having Lisp-style macros.

asgard1024 11y ago
I don't want to get into this discussion, because, as I said, I disagree with these arguments; I just wanted to point out they exist and are valid. Anyway, I already outlined the argument in another of my comments, where I talk about set theory and integrals - the "axiomatic" primitives are different bunch than "useful" primitives. So trying to keep language small may lead to different decisions based on which primitives you want to keep. So for instance (as a simple example) map and filter can be built with recursion, but why bother with learning how to do it, if I can just call them from the standard library? (Or in case of Python, use generator comprehension.) Another example would be complaint below, that Python doesn't have proper closures. Valid complaint or not, Python has classes, and you can pretty much build one from the other.
- sklogic 11y ago
  > they exist and are valid. Uhm, no, so far not a single valid non-straw-man argument against macros. It's important to mention that macros do not affect the rest of the language design choices in any way whatsoever. The underlying language can be literally anything, macros can be added on top of any imaginable combination of design decisions. In case of a python-like language, see Converge, for example.
  - asgard1024 11y ago
    > It's important to mention that macros do not affect the rest of the language design choices in any way whatsoever. I think you're wrong. It affects how people use the language, and how the community develops around it, and other things. Perhaps if people would use macros as a sort of last resort thing, then it wouldn't matter, but from my experience, they don't. It's probably most visible in the Forth community - every implementation of Forth is subtly different from the others, and by design! Chuck Moore even said that the Forth standard goes against the very idea of Forth. I now work on a large codebase in language with macros (SAS), and while it's powerful, it also causes problems; the code where any calculation can take place during compilation is harder to read, sometimes, and they cannot be easily translated to other language, for example. The truth is, the programming community moved from macros, which are powerful and easy to implement, to other abstractions, less powerful but more specific to problems that people usually face (such as OOP). Many languages from 70s and 80s had macros, but today it's not so common. This transition is a little bit similar to transition from imperative to functional style, which will probably happen in the future.
    - sklogic 11y ago
      > It affects how people use the language, and how the community develops around it, and other things. It affects the use (in very positive way), but does not affect the design. But, what is true, is that a majority of people using macros do not understand how to do it properly and do not follow the right discipline. What is needed is to promote such discipline instead of spreading lies that "macros are dangerous". And no, there is a very strong trend back to metaprogramming at the moment: Julia, C++, D, Clojure, Rust, all that stuff. All the other methods of implementing abstractions (OOP and the other pathetic things) have a very pronounced maximum of the level of abstraction, while there is no limit when metaprogramming is used to implement hierarchies of eDSLs.