6 ms·

I once downloaded a python script, ran it with some input, and got a result. Curious, I opened the script in Emacs, which then opened it into python mode. As is

I once downloaded a python script, ran it with some input, and got a result. Curious, I opened the script in Emacs, which then opened it into python mode. As is my habit, I indented the whole file, which did basic white space changes to it according to python mode. I didn't realize I did this at first, and I saved and exited the script, then played around with it some more. Still got results, everything seemed the same. But when I tried it with the same input as originally, it was a different return result. This took a while to figure out, until I realized that emacs changed the indentation of just one line, because the author had apparently not followed the typical idioms or conventions of indenting python in some way. That merely opening, beautifying, and saving a file could change program output with no errors has turned me off of white space sensitive syntax ever since. Which is partly why OCaml gets some bias from me over Haskell.

mlevental 9y ago
honestly it's bananas. I can't for the life of understand how such a poor form over function decision was ever made by an engineer. the number of bugs (>0) this introduces into production code every year is reason enough (imho the only relevant metric) to prefer braces. are block delimiting braces really that onerous???
- coldtea 9y ago
  Because braces don't introduce bugs? You can just as easily omit braces in a if/for etc statement and have a bug, or close the wrong brace at the wrong point (and also introduce a bug).
  - mlevental 9y ago
    >omit braces so you're saying braceless ifs and fors are bad? yes I agree. > close the wrong brace -/+ 1 flipping the right number of braces to get that kind of bug is much much harder than indenting a block incorrectly
    - avmich 9y ago
      But the requirement for always having brackets is just plain inconvenient for many. Even C doesn't always require brackets.
    - coldtea 9y ago
      >flipping the right number of braces to get that kind of bug is much much harder than indenting a block incorrectly Maybe, but enclosing an additional statement or more in your brace because you visually indented it incorrectly is just as easy as in Python. for (i=0; i<100; i++) { do_this_100_times(); but_this_just_once(); #oops } And if you didn't indent it incorrectly, then it's still possible: for (i=0; i<100; i++) { do_this_100_times(); but_this_just_once(); # oops } whereas in Python it's not: for i in range(100): do_this_100_times() but_this_just_once() # correct indentation takes care of it
  - tigershark 9y ago
    I can upvote you only once sadly..
Tehnix 9y ago
I'm not entirely sure if you are implying that wrong indentation in Haskell will result in programs that compile, but give differing output? I have honestly never seen that happen, and couldn't imagine a piece of code that would compile in either cases. EDIT: 1) as masklinn mentions, the indentation in Python and Haskell works differently. Furthermore, Python can have expressions as top-level, which Haskell cannot, and you can also have if statements with no else in Python, which again, in Haskell you cannot. 2) I know of no formatters for Haskell which will change the semantics, since they all rely on rendering an AST of the code (IIRC). 3) Ocaml is also white-space sensitive, so I don't see the point in the comparison there? 4) You would need to have some pretty contrived code for it to both satisfy the parser and type-check and be wrong logic caused by moving an indentation. Like, you can't do it in a function that's a if-then-else plainly, nor a case-statement. Maybe a where statement, but then you just promoted the function to top-level, which will not be a problem unless it's shadowing something else, for which you'll get a compiler warning. Show me some code, and then I'll consider the point valid, I just can't come up with any examples.
- joeyh 9y ago
  This example is very contrived, but challenge accepted.. main = do let print = putStr . (++ " ") in do print "happy" print "holidays" -- indentation sensitive putStrLn "!" De-indenting the marked line by 2 spaces exposes some scroogey irony. (Note that compiler warnings give a hint about the bad idea in this code, but nested do's can have this problem without warnings also.)
  - avmich 9y ago
    I'm not sure that's what GP meant. I understood what he said as "it's hard to write code which correct in logic, types, and which passes correct beautifier which changes logic", and I'd think this is impossible. The example you gave requires to change logic - because indentation is a part of the logic here.
- gmfawcett 9y ago
  Ocaml isn't whitespace sensitive (other than in the obvious sense, i.e., to separate tokens). You can write a whole module (or series of modules) on a single line if you want to.
Someone 9y ago
You used a buggy beautifier that mishandled some code, and you blame significant whitespace? For that to be valid criticism, it must be particularly hard to write a beautifier for languages with significant whitespace relative to other languages. I don’t think it is. Beautifying C, for example, also can be tricky in the presence of nested comments (potentially of different types) and nested if statements, some without else clauses, some without {}.
- amorphid 9y ago
  That is his point, I think. He doesn't want to be exposed to errors related to whitespace in the code. I feel the same way, and it's the number one reason I avoid Python.
- userbinator 9y ago
  Beautifying C, for example, also can be tricky in the presence of nested comments C comments do not nest.
  - dllthomas 9y ago
    Since C99, you've been able to have end-of-line comments inside a block comment.
- hellofunk 9y ago
  Python and emacs are both popular, and I'm talking about default indent behavior for python in emacs, not some fringe or esoteric plugin for beautifying. If that's buggy, then there's a larger problem in my opinion.
- marcosdumay 9y ago
  Mixing tabs and spaces in Python leads to ambiguities. Actually, in Haskell too, but as the GP said, it is almost impossible that it becomes a problem on practice.
AlexCoventry 9y ago
What did you use to do the indenting?
- hellofunk 9y ago
  Just default emacs indent behavior for python mode.
  - AlexCoventry 9y ago
    C-x h C-M-\? Or just going through hitting tab on every line? If the first, that was a bug in emacs. If the second, that was a predictable result.
    - hellofunk 9y ago
      indent-buffer probably is the emacs command unless python mode overwrites that.
runeks 9y ago
> Which is partly why OCaml gets some bias from me over Haskell. Sounds like you made a mistake, then, because indentation is optional in Haskell: https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit_characters_in_place_of_indentation https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit...
- hellofunk 9y ago
  I have never seen a Haskell dev do this.
  - CatOnTheCouch 9y ago
    Which shows what most people prefer. None the less your concern is more than valid and a real problem. My suggestion would be that the interpreters/compilers of white-space sensitive languages should implement the beautifying operation and call it before code is executed and editors should use this function. We can't expect to not adapt editors to different code styles.
  - Tarean 9y ago
    Simon Peyton Jones, one of the driving forces behind GHC, uses braces.
mbrock 9y ago
In 1965, Peter Landin presented the groundbreaking paper "The Next 700 Programming Languages" at the ACM Programming Languages and Pragmatics Conference in San Dimas. It described a family of languages called ISWIM, with a staggering number of durable inventions. It's widely recognized as the precursor to ML and Haskell. One of the inventions is the "off-side rule" for indentation sensitive parsing. The last section of the paper, after the author's conclusion, is a transcript of the discussion at the conference. The first question is from Naur: Regarding indentation, in many ways I am in sympathy with this, but I believe that if it came about that this notation were used for very wide communication and also publication,you would regret it because of the kind of rearrangement of manuscripts done in printing, for example. You very frequently run into the problem that you have a wide written line and then suddenly you go to the Communications of the ACM and radically, perhaps, you have to compress it. The printer will do this in any way he likes; he is used to having great freedom here and he will foul up your notation. Next, Floyd: Another objection that think is quite serious to indentation is that while it works on the micro-scale—that is, one page is all right—when dealing with an extensive program, turning from one page to the next there is no obvious way of indicating how far indentation stretches because there is no printing at all to indicate how far you have indented. I would like you to keep that in mind. It's a very old discussion.
- avmich 9y ago
  There were problems with printing APL programs - those strange symbols. Or unclosed brackets and quotes. J tried to address these issues, it's ASCII-only - yet J code still looks rather unstructured. This argument may sound like admission of imperfectness of printing process.
- tigershark 9y ago
  Last time that I printed a program to work on it was probably 25 years ago.. I don't really think that it makes any sense at all as of today. And if you are really indenting so much that you can't understand the indentation then it's a clear sign of something wrong in your code.

mlevental 9y ago

honestly it's bananas. I can't for the life of understand how such a poor form over function decision was ever made by an engineer. the number of bugs (>0) this introduces into production code every year is reason enough (imho the only relevant metric) to prefer braces. are block delimiting braces really that onerous???

coldtea 9y ago
Because braces don't introduce bugs? You can just as easily omit braces in a if/for etc statement and have a bug, or close the wrong brace at the wrong point (and also introduce a bug).
- mlevental 9y ago
  >omit braces so you're saying braceless ifs and fors are bad? yes I agree. > close the wrong brace -/+ 1 flipping the right number of braces to get that kind of bug is much much harder than indenting a block incorrectly
  - avmich 9y ago
    But the requirement for always having brackets is just plain inconvenient for many. Even C doesn't always require brackets.
  - coldtea 9y ago
    >flipping the right number of braces to get that kind of bug is much much harder than indenting a block incorrectly Maybe, but enclosing an additional statement or more in your brace because you visually indented it incorrectly is just as easy as in Python. for (i=0; i<100; i++) { do_this_100_times(); but_this_just_once(); #oops } And if you didn't indent it incorrectly, then it's still possible: for (i=0; i<100; i++) { do_this_100_times(); but_this_just_once(); # oops } whereas in Python it's not: for i in range(100): do_this_100_times() but_this_just_once() # correct indentation takes care of it
- tigershark 9y ago
  I can upvote you only once sadly..

Tehnix 9y ago

I'm not entirely sure if you are implying that wrong indentation in Haskell will result in programs that compile, but give differing output? I have honestly never seen that happen, and couldn't imagine a piece of code that would compile in either cases. EDIT: 1) as masklinn mentions, the indentation in Python and Haskell works differently. Furthermore, Python can have expressions as top-level, which Haskell cannot, and you can also have if statements with no else in Python, which again, in Haskell you cannot. 2) I know of no formatters for Haskell which will change the semantics, since they all rely on rendering an AST of the code (IIRC). 3) Ocaml is also white-space sensitive, so I don't see the point in the comparison there? 4) You would need to have some pretty contrived code for it to both satisfy the parser and type-check and be wrong logic caused by moving an indentation. Like, you can't do it in a function that's a if-then-else plainly, nor a case-statement. Maybe a where statement, but then you just promoted the function to top-level, which will not be a problem unless it's shadowing something else, for which you'll get a compiler warning. Show me some code, and then I'll consider the point valid, I just can't come up with any examples.

joeyh 9y ago
This example is very contrived, but challenge accepted.. main = do let print = putStr . (++ " ") in do print "happy" print "holidays" -- indentation sensitive putStrLn "!" De-indenting the marked line by 2 spaces exposes some scroogey irony. (Note that compiler warnings give a hint about the bad idea in this code, but nested do's can have this problem without warnings also.)
- avmich 9y ago
  I'm not sure that's what GP meant. I understood what he said as "it's hard to write code which correct in logic, types, and which passes correct beautifier which changes logic", and I'd think this is impossible. The example you gave requires to change logic - because indentation is a part of the logic here.
gmfawcett 9y ago
Ocaml isn't whitespace sensitive (other than in the obvious sense, i.e., to separate tokens). You can write a whole module (or series of modules) on a single line if you want to.

Someone 9y ago

You used a buggy beautifier that mishandled some code, and you blame significant whitespace? For that to be valid criticism, it must be particularly hard to write a beautifier for languages with significant whitespace relative to other languages. I don’t think it is. Beautifying C, for example, also can be tricky in the presence of nested comments (potentially of different types) and nested if statements, some without else clauses, some without {}.

amorphid 9y ago
That is his point, I think. He doesn't want to be exposed to errors related to whitespace in the code. I feel the same way, and it's the number one reason I avoid Python.
userbinator 9y ago
Beautifying C, for example, also can be tricky in the presence of nested comments C comments do not nest.
- dllthomas 9y ago
  Since C99, you've been able to have end-of-line comments inside a block comment.
hellofunk 9y ago
Python and emacs are both popular, and I'm talking about default indent behavior for python in emacs, not some fringe or esoteric plugin for beautifying. If that's buggy, then there's a larger problem in my opinion.
marcosdumay 9y ago
Mixing tabs and spaces in Python leads to ambiguities. Actually, in Haskell too, but as the GP said, it is almost impossible that it becomes a problem on practice.

AlexCoventry 9y ago

What did you use to do the indenting?

hellofunk 9y ago
Just default emacs indent behavior for python mode.
- AlexCoventry 9y ago
  C-x h C-M-\? Or just going through hitting tab on every line? If the first, that was a bug in emacs. If the second, that was a predictable result.
  - hellofunk 9y ago
    indent-buffer probably is the emacs command unless python mode overwrites that.

runeks 9y ago

> Which is partly why OCaml gets some bias from me over Haskell. Sounds like you made a mistake, then, because indentation is optional in Haskell: https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit_characters_in_place_of_indentation https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit...

hellofunk 9y ago
I have never seen a Haskell dev do this.
- CatOnTheCouch 9y ago
  Which shows what most people prefer. None the less your concern is more than valid and a real problem. My suggestion would be that the interpreters/compilers of white-space sensitive languages should implement the beautifying operation and call it before code is executed and editors should use this function. We can't expect to not adapt editors to different code styles.
- Tarean 9y ago
  Simon Peyton Jones, one of the driving forces behind GHC, uses braces.

mbrock 9y ago

In 1965, Peter Landin presented the groundbreaking paper "The Next 700 Programming Languages" at the ACM Programming Languages and Pragmatics Conference in San Dimas. It described a family of languages called ISWIM, with a staggering number of durable inventions. It's widely recognized as the precursor to ML and Haskell. One of the inventions is the "off-side rule" for indentation sensitive parsing. The last section of the paper, after the author's conclusion, is a transcript of the discussion at the conference. The first question is from Naur: Regarding indentation, in many ways I am in sympathy with this, but I believe that if it came about that this notation were used for very wide communication and also publication,you would regret it because of the kind of rearrangement of manuscripts done in printing, for example. You very frequently run into the problem that you have a wide written line and then suddenly you go to the Communications of the ACM and radically, perhaps, you have to compress it. The printer will do this in any way he likes; he is used to having great freedom here and he will foul up your notation. Next, Floyd: Another objection that think is quite serious to indentation is that while it works on the micro-scale—that is, one page is all right—when dealing with an extensive program, turning from one page to the next there is no obvious way of indicating how far indentation stretches because there is no printing at all to indicate how far you have indented. I would like you to keep that in mind. It's a very old discussion.

avmich 9y ago
There were problems with printing APL programs - those strange symbols. Or unclosed brackets and quotes. J tried to address these issues, it's ASCII-only - yet J code still looks rather unstructured. This argument may sound like admission of imperfectness of printing process.
tigershark 9y ago
Last time that I printed a program to work on it was probably 25 years ago.. I don't really think that it makes any sense at all as of today. And if you are really indenting so much that you can't understand the indentation then it's a clear sign of something wrong in your code.