26 ms·

Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation

Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation as a mandatory part of the language and then remove cruft which is no longer necessary.

silentbicycle 16y ago
I'm not convinced that block structure and indentation are primary readability factors, just noting that Lisp programmers established conventions to address that problem long ago.
- Locke1689 16y ago
  That's fair. I'm not saying Python's way is better or Lisp's way is better. I'm a long-time Python programmer but I'm also working on the Racket code base. I was simply pointing out a difference in philosophy, not taking sides. I mostly believe that the debate is a minor stylistic one and there are trade-offs in both directions. This is fundamentally similar to the way I see arguments for and against Python syntactical whitespace vs. Ruby-esque blocks.
euccastro 16y ago
Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. I'm very familiar with Python and hack occasionally in Scheme. After a really short time, parens really are no problem. They are an asset. In big functions where indentation stops being obvious at a glance (and in smaller ones, what's the problem?), I can more easily see/check the extent of a block in Scheme (with editor paren matching) than in Python. The editor is better able to help me select and operate on such blocks. Moving blocks around (e.g. for refactoring) is easier, faster and feels safer. If I still use Python more often than Scheme it has nothing to do with parens. Much on the contrary, that's one of the reasons I wish I could spend more time in Scheme.
- Locke1689 16y ago
  Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. Because they screwed up? I think indentation like the following should be mandatory across multiple lines: fun_a(long_arg_a, long_arg_b, long_arg_c)
  - euccastro 16y ago
    And does that remove the need for parentheses? ;) Because actually, it gets more complicated than that. Sometimes it makes more sense to say: def open_window(x, y width, height, resizable=True, caption="") Without parens, is x, y a tuple or two separate arguments? And do I want to remember that? Also, what's inside the parens could have been a generator expression, which could have been conceivably partitioned in more than one sensible way, and which could have subexpressions with parens or brackets itself. Sounds contrived? I do it all the time and it often looks and reads just fine. I'm not arguing against your indentation rule, which is the one I use, and not even against the proposal of making it mandatory (although I'm not sure that in the heat of refactoring I'd appreciate the unnecessary SyntaxErrors), but about the point that making it mandatory would make parens unnecessary.
    - Locke1689 16y ago
      True, although Haskell does show we can do function application without excessive parentheses. I think you're definitely right about Python, though. Fundamentally, Python is still a procedural, block style language. If it were written in the same functional style as Lisp it would probably be just as complex.
      - silentbicycle 16y ago
        The ML and APL families also do function application without excessive parens. I don't think Lisp's grouping rules are complex. There are a few functions with special grouping, particularly let and cond, but anybody doing real programming in Lisp gets used to them pretty quickly. (Lisp is hardly the only language with special cases in its syntax!) User-added functions seldom have elaborate nesting schemes, or at least have a damned good reason.

silentbicycle 16y ago

I'm not convinced that block structure and indentation are primary readability factors, just noting that Lisp programmers established conventions to address that problem long ago.

Locke1689 16y ago
That's fair. I'm not saying Python's way is better or Lisp's way is better. I'm a long-time Python programmer but I'm also working on the Racket code base. I was simply pointing out a difference in philosophy, not taking sides. I mostly believe that the debate is a minor stylistic one and there are trade-offs in both directions. This is fundamentally similar to the way I see arguments for and against Python syntactical whitespace vs. Ruby-esque blocks.

euccastro 16y ago

Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. I'm very familiar with Python and hack occasionally in Scheme. After a really short time, parens really are no problem. They are an asset. In big functions where indentation stops being obvious at a glance (and in smaller ones, what's the problem?), I can more easily see/check the extent of a block in Scheme (with editor paren matching) than in Python. The editor is better able to help me select and operate on such blocks. Moving blocks around (e.g. for refactoring) is easier, faster and feels safer. If I still use Python more often than Scheme it has nothing to do with parens. Much on the contrary, that's one of the reasons I wish I could spend more time in Scheme.

Locke1689 16y ago
Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. Because they screwed up? I think indentation like the following should be mandatory across multiple lines: fun_a(long_arg_a, long_arg_b, long_arg_c)
- euccastro 16y ago
  And does that remove the need for parentheses? ;) Because actually, it gets more complicated than that. Sometimes it makes more sense to say: def open_window(x, y width, height, resizable=True, caption="") Without parens, is x, y a tuple or two separate arguments? And do I want to remember that? Also, what's inside the parens could have been a generator expression, which could have been conceivably partitioned in more than one sensible way, and which could have subexpressions with parens or brackets itself. Sounds contrived? I do it all the time and it often looks and reads just fine. I'm not arguing against your indentation rule, which is the one I use, and not even against the proposal of making it mandatory (although I'm not sure that in the heat of refactoring I'd appreciate the unnecessary SyntaxErrors), but about the point that making it mandatory would make parens unnecessary.
  - Locke1689 16y ago
    True, although Haskell does show we can do function application without excessive parentheses. I think you're definitely right about Python, though. Fundamentally, Python is still a procedural, block style language. If it were written in the same functional style as Lisp it would probably be just as complex.
    - silentbicycle 16y ago
      The ML and APL families also do function application without excessive parens. I don't think Lisp's grouping rules are complex. There are a few functions with special grouping, particularly let and cond, but anybody doing real programming in Lisp gets used to them pretty quickly. (Lisp is hardly the only language with special cases in its syntax!) User-added functions seldom have elaborate nesting schemes, or at least have a damned good reason.