6 ms·

What I mean is that Python tries hard to find a compromise solution between various ideologies. Whether or not that is an ideology I would leave up to Bertrand

What I mean is that Python tries hard to find a compromise solution between various ideologies. Whether or not that is an ideology I would leave up to Bertrand Russell; I think it isn't. Regarding extensibility, again, there are people who argue against it and have an opposite opinion to Lispers. Python tries to find a middle ground, conservatively. It's not super extensible like Lisp or Forth, but still quite a lot compared to many mainstream languages.

sklogic 11y ago
> there are people who argue against it These are the people who don't know any better, arguing out of ignorance, not from some valid ground. > Python tries to find a middle ground, conservatively. How exactly? I do not see any extensibility features in Python, none at all. Some dirty hacks with rewriting the compiled bytecode in runtime do not count.
- asgard1024 11y ago
  > 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

> there are people who argue against it These are the people who don't know any better, arguing out of ignorance, not from some valid ground. > Python tries to find a middle ground, conservatively. How exactly? I do not see any extensibility features in Python, none at all. Some dirty hacks with rewriting the compiled bytecode in runtime do not count.

asgard1024 11y ago
> 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.