3 ms·

I would argue not. These paradigms actually encompass other models, and it that sense, they are pragmatic conservative choices (in a sense, "minimal"). You can

I would argue not. These paradigms actually encompass other models, and it that sense, they are pragmatic conservative choices (in a sense, "minimal"). You can program functionally in Python. It doesn't really gets in way of doing that, which cannot be said about functional languages, they are often designed to prevent you programming imperatively. Dynamically typed languages can be understood as having only one type, so it's in a sense a type system that encompasses all the other type systems. For fans of typing, Python added optional type annotations, again, as a very conservative choice. Interpreted - again, it's probably easier to write interpreter than compiler. Once you get into compiling, you have to make some more choices, which Python conservatively forfeits. That is not to say that these choices aren't cultural (for example, most people are more familiar with infix notation, although even here there may be pragmatic reasons - the exactly right amount of parentheses). Just that it tries to encompass various tastes and be conservative about it.

sklogic 11y ago
> it's probably easier to write interpreter than compiler It's not easier. Interpreters are much more complex and much less robust than compilers.
- mdpopescu 11y ago
  I've written a few interpreters during my (almost) 30 years of programming; never a compiler. The thought of 1) machine code generation and 2) optimizations scares me every time.
  - sklogic 11y ago
    > The thought of 1) machine code generation and Don't do it. Compile into a higher level representation and reuse and existing machine code generator (LLVM, even plain C), or compile into a higher level VM with threaded code implementation (Forth and alike). Although even a full compiler with a native codegen is still much simpler than an interpreter. > 2) optimizations scare me every time As if you don't have to optimise in an interpreter. Not to mention that even an unoptimised compiler would produce much faster code than your average "easy" interpreter. Compilation is nothing but a sequence of trivial term rewriting passes. Each can be as simple as you want, doing one trivial thing at a time. Easy to understand, easy to write in a fully declarative way, easy to reason about, easy to debug and maintain. You don't even need a Turing-complete language to do it. And an interpreter is always a pile of convoluted mess, leaking multiple abstractions in between layers (if you're lucky enough to even get any distinct layers at all). I always wondered how people can even compare interpreters to compilers.
    - mdpopescu 11y ago
      Hmm. Interesting way of looking at it ("term rewriting passes"). I'll have to think about it, thanks.
      - sklogic 11y ago
        You may want to take a look at Nanopass: http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf
- loup-vaillant 11y ago
  Über fast JIT virtual machines, maybe. Even bytecode interpreters are likely simpler because while you still have to compile to the bytecode, it is generally simpler and higher level than x86 or ARM assembly. Direct interpreters (based on the AST) are slow, but dead simple. What makes you think interpreters are more complex?
  - sklogic 11y ago
    > Direct interpreters (based on the AST) are slow, but dead simple. Still far too complex, and, what is worse, very convoluted. You cannot split such an interpreter into series of very small and easy to understand steps, it must do everything at once, in a single huge recursive visitor. Compare it to a simple compiler which will rewrite one distinct aspect of a language at a time. Another awful property of interpreters is that you can't strip them away from the runtime, it must be woven into all the parts of the interpreter and cannot be abstracted away. While compiler can be isolated from all the runtime issues which should be implemented separately (or simply reused).
  - Someone 11y ago
    I don't think compilers are easier to write than interpreters, but you should try and find the source code for some of the basic compilers from the eighties. The difference between (lex, parse, execute) and (lex, parse, generate assembly) are very small, if you are willing to forego optimizations. A compiler can even use thenexact same data structures as the interpreter to store variable names and their values, and use subroutines to look up and store values. Fast? No, but it will be faster than that direct interpreter (some Basics of the '80s scanned a linked list to find target lines of goto's and gosub's. If you manage to get rid of that, tight loop can get a lot faster soon)
PuercoPop 11y ago
> You can program functionally in Python. Python doesn't even have closures. > Interpreted Languages are neither interpreted nor compiled. Implementations are.
- tome 11y ago
  > Python doesn't even have closures. So what's this? >>> x = 1 >>> def f(y): return y + x ... >>> f(2) 3 EDIT: Note that my example works even if the definition of x and f appear within the definition of another function. If closed-over variables must be mutable then Haskell doesn't have closures!
  - aidos 11y ago
    Just been reading up on this. Python has sort of read only closures where the free variables are stored against the functions. You can't alter a variable inside the closure like you can in JS. Personally, I don't mind - I'd rather have a better idea of which scopes are changing which information, but I don't think they're considered "true closures." More over here - http://stackoverflow.com/a/23558809/171450 http://stackoverflow.com/a/23558809/171450
    - gte525u 11y ago
      This is incorrect for at least python 3.x I.e., Python 3.4.3 (default, Apr 7 2015, 08:05:21) >>> def mk_generator(initial): ... var = initial ... def increment(count=1): ... nonlocal var ... var += count ... return var ... return increment ... >>> a = mk_generator(3) >>> b = mk_generator(10) >>> a(1) 4 >>> b <function mk_generator.<locals>.increment at 0x1040a7d08> >>> b() 11 >>> b() 12 >>> a(3) 7
  - josteink 11y ago
    Reference to a global, shared variable.
  - espadrine 11y ago
    I believe you are confusing closures with scope. Closures define the set of variables whose lifetime extends the function they are in because of their use in another function. For instance: ;; Function that returns a function that counts even numbers (define (even) (let ((x 0)) (lambda () (set! x (+ x 2)) x))) (define count (even)) (count) ; → 2 (count) ; → 4 In Python: def even(): x = 0 def add(): x += 2 return x return add count = even() count() # → UnboundLocalError: local variable 'x' referenced before assignment That said, Python does support a less convenient style of closures — it works if the variable is a container (such as a list, a dictionary or an object).

sklogic 11y ago

> it's probably easier to write interpreter than compiler It's not easier. Interpreters are much more complex and much less robust than compilers.

mdpopescu 11y ago
I've written a few interpreters during my (almost) 30 years of programming; never a compiler. The thought of 1) machine code generation and 2) optimizations scares me every time.
- sklogic 11y ago
  > The thought of 1) machine code generation and Don't do it. Compile into a higher level representation and reuse and existing machine code generator (LLVM, even plain C), or compile into a higher level VM with threaded code implementation (Forth and alike). Although even a full compiler with a native codegen is still much simpler than an interpreter. > 2) optimizations scare me every time As if you don't have to optimise in an interpreter. Not to mention that even an unoptimised compiler would produce much faster code than your average "easy" interpreter. Compilation is nothing but a sequence of trivial term rewriting passes. Each can be as simple as you want, doing one trivial thing at a time. Easy to understand, easy to write in a fully declarative way, easy to reason about, easy to debug and maintain. You don't even need a Turing-complete language to do it. And an interpreter is always a pile of convoluted mess, leaking multiple abstractions in between layers (if you're lucky enough to even get any distinct layers at all). I always wondered how people can even compare interpreters to compilers.
  - mdpopescu 11y ago
    Hmm. Interesting way of looking at it ("term rewriting passes"). I'll have to think about it, thanks.
    - sklogic 11y ago
      You may want to take a look at Nanopass: http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf
loup-vaillant 11y ago
Über fast JIT virtual machines, maybe. Even bytecode interpreters are likely simpler because while you still have to compile to the bytecode, it is generally simpler and higher level than x86 or ARM assembly. Direct interpreters (based on the AST) are slow, but dead simple. What makes you think interpreters are more complex?
- sklogic 11y ago
  > Direct interpreters (based on the AST) are slow, but dead simple. Still far too complex, and, what is worse, very convoluted. You cannot split such an interpreter into series of very small and easy to understand steps, it must do everything at once, in a single huge recursive visitor. Compare it to a simple compiler which will rewrite one distinct aspect of a language at a time. Another awful property of interpreters is that you can't strip them away from the runtime, it must be woven into all the parts of the interpreter and cannot be abstracted away. While compiler can be isolated from all the runtime issues which should be implemented separately (or simply reused).
- Someone 11y ago
  I don't think compilers are easier to write than interpreters, but you should try and find the source code for some of the basic compilers from the eighties. The difference between (lex, parse, execute) and (lex, parse, generate assembly) are very small, if you are willing to forego optimizations. A compiler can even use thenexact same data structures as the interpreter to store variable names and their values, and use subroutines to look up and store values. Fast? No, but it will be faster than that direct interpreter (some Basics of the '80s scanned a linked list to find target lines of goto's and gosub's. If you manage to get rid of that, tight loop can get a lot faster soon)

PuercoPop 11y ago

> You can program functionally in Python. Python doesn't even have closures. > Interpreted Languages are neither interpreted nor compiled. Implementations are.

tome 11y ago
> Python doesn't even have closures. So what's this? >>> x = 1 >>> def f(y): return y + x ... >>> f(2) 3 EDIT: Note that my example works even if the definition of x and f appear within the definition of another function. If closed-over variables must be mutable then Haskell doesn't have closures!
- aidos 11y ago
  Just been reading up on this. Python has sort of read only closures where the free variables are stored against the functions. You can't alter a variable inside the closure like you can in JS. Personally, I don't mind - I'd rather have a better idea of which scopes are changing which information, but I don't think they're considered "true closures." More over here - http://stackoverflow.com/a/23558809/171450 http://stackoverflow.com/a/23558809/171450
  - gte525u 11y ago
    This is incorrect for at least python 3.x I.e., Python 3.4.3 (default, Apr 7 2015, 08:05:21) >>> def mk_generator(initial): ... var = initial ... def increment(count=1): ... nonlocal var ... var += count ... return var ... return increment ... >>> a = mk_generator(3) >>> b = mk_generator(10) >>> a(1) 4 >>> b <function mk_generator.<locals>.increment at 0x1040a7d08> >>> b() 11 >>> b() 12 >>> a(3) 7
- josteink 11y ago
  Reference to a global, shared variable.
- espadrine 11y ago
  I believe you are confusing closures with scope. Closures define the set of variables whose lifetime extends the function they are in because of their use in another function. For instance: ;; Function that returns a function that counts even numbers (define (even) (let ((x 0)) (lambda () (set! x (+ x 2)) x))) (define count (even)) (count) ; → 2 (count) ; → 4 In Python: def even(): x = 0 def add(): x += 2 return x return add count = even() count() # → UnboundLocalError: local variable 'x' referenced before assignment That said, Python does support a less convenient style of closures — it works if the variable is a container (such as a list, a dictionary or an object).