<p>I'm not aware of any language other than Python that uses indentation to denote code blocks. To me, it seems like the simplest way to indicate blocks, and it also encourages proper formatting by making code not work if it is not indented properly. I would expect it to be more widely used; are there drawbacks that I'm missing?</p>

<language-comparison><syntax><whitespace><indentation>
What are the drawbacks of using indentation for code blocks?
CC BY-SA 4.0
2023-05-17T20:41:38.953Z
Scala 3 lets you use both indentation and braces, so you can experience the worst of both worlds!
user
CC BY-SA 4.0
2023-07-19T13:08:14.160Z
Makefiles, although not a programming language, also use indentation.
gerrit
CC BY-SA 4.0
2023-05-16T17:39:45.010Z
Haskell, occam, ABC, and various markup and data serialisation languages also use significant indentation.
Adám
CC BY-SA 4.0
2023-05-16T17:45:51.207Z
Scala can use indentation instead of braces
Seggan
CC BY-SA 4.0
2023-05-16T20:27:50.897Z
Not a programing language but YAML is another one
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T21:22:37.990Z
Ambiguity if newlines/indentation break for some reason
CPlus
<h1>Source code size</h1>
<p>For interpreted languages, where the source needs to be sent over the Internet, like JavaScript, source code size is incredibly important. Having the option to just remove all white-space without losing meaning can save a lot of bandwidth in these cases.</p>

CC BY-SA 4.0
2023-05-16T18:29:29.597Z
2023-05-17T12:32:47.387Z
2023-05-17T12:32:47.387Z
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T08:00:51.407Z
I'm not aware of anything over (at least) the past decade that sends the JS code ***not*** gzipped. Yes, minifiers are often employed to reduce the size of the code, however, like @PeterMortensen says, the whitespace should compress extremely well. Minifiers do remove whitespace but they produce more value by converting other parts of the code.
VLAZ
CC BY-SA 4.0
2023-05-18T08:04:59.803Z
It's true compression will take out most of the bytes from the indentation but not all of them. It still makes a difference for big source files
mousetail 'he-him'
CC BY-SA 4.0
2023-05-17T11:22:08.190Z
But it also compresses extremely well(?). Representable by a few bits. And repeats (low entropy).
Peter Mortensen
<p>There is more than one way to define layout-sensitive programming languages, where indentation matters. The Python way is different from the Haskell way, which is different from the F# way... For reference see Michael Adams's <a href="https://michaeldadams.org/papers/layout_parsing/LayoutParsing.pdf" rel="noreferrer">Principled Parsing for Indentation-Sensitive Languages</a></p>
<p><strong>For Python in particular</strong>, one of the biggest drawbacks of significant indentation is that <strong>lambdas cannot contain statements</strong>.</p>
<pre><code># Not allowed!
f = lambda x:
      if x: 
       print(&quot;hi&quot;)   
</code></pre>
<p>The reason for this is that Python ignores any indentation between parenthesis or brackets. This is how Python allows us to write multi-line expressions:</p>
<pre><code>x = (1 + 
   2 + 
   3 )
</code></pre>
<p>Which Python treats as if you had written everything in the same line:</p>
<pre><code>x = (1 + 2 + 3)
</code></pre>
<p>This means that expressions in Python cannot contain anything that cares about indentation. In particular, lambda expressions, cannot contain statements such as <code>if</code> or <code>while</code>, because those statements need indentation.</p>

CC BY-SA 4.0
2023-05-16T22:25:54.050Z
2023-05-19T21:27:46.620Z
2023-05-19T21:27:46.620Z
hugomg
CC BY-SA 4.0
2023-07-04T19:28:34.853Z
`fn()=>`Lambdas can not contain statements in PHP either even though it has bracket indentation. I don't think this choice is linked to the indentation system
mousetail 'he-him'
CC BY-SA 4.0
2023-10-19T13:00:06.633Z
@mousetail It's very much related to the use of indentation for blocks. See [this other Q&A](https://langdev.stackexchange.com/q/1395/89).
kaya3
CC BY-SA 4.0
2024-02-21T17:37:33.483Z
Thanks for the reference! Really useful for understanding how Haskell and Python parses indentations.
ximo
<h1>Awkward code pasting</h1>
<p>Copying/Cutting and pasting code becomes less than trivial, since the new location may need less or more indentation. An IDE that's aware of the language in use may be able to help with this, but plain text editors cannot.</p>
<p>In addition, various potential pasting destinations fail to preserve whitespace, e.g. comments on Stack Overflow, and messages on Zoom. Facebook and other sites often do not preserve whitespace, so it becomes harder to discuss code examples with others online.</p>
<p>On various forums, inexperienced users tend to paste in their code without putting it in a code block, so as usual with HTML, any amount of consecutive whitespace gets stripped down to a single space, completely altering the meaning of the code.</p>
<p>Finally, some languages, like Python, make the situation even worse than it could be because code blocks are not variable scopes. Moving a block of code means that any variables that are logically &quot;local&quot; to that block don't always hygienically move with it. JavaScript also has this problem without significant whitespace, but the combination in Python is particularly problematic.</p>

CC BY-SA 4.0
2023-05-16T17:42:27.287Z
2023-05-18T05:40:58.423Z
2023-05-18T05:40:58.423Z
Adám
CC BY-SA 4.0
2023-05-18T01:41:21.110Z
Also, often on forums, people paste in their code without putting it in a code block, so as usual with HTML, the double spaces get stripped, removing the indentation. It's annoying when people do this but people do what they do.
naffetS
CC BY-SA 4.0
2023-05-16T17:43:48.567Z
So the idea is that you can copy the code, test it, then fix indentation if it works? The fact that indentation needs to be fixed when copying is one of the things that I see as a benefit of significant whitespace because it avoids incorrect indentation.
Someone
CC BY-SA 4.0
2023-05-16T17:51:11.423Z
@Someone Yes, or simply leave the indentation dirty, for a quick one-off or because it doesn't bother.
Adám
CC BY-SA 4.0
2023-05-16T17:58:47.343Z
Why don't you combine this with your other answers? 1-line answers are highly frowned upon in many SE sites, and here you have 3 sentences across 2 answers :)
Nike Dattani
CC BY-SA 4.0
2023-05-16T18:02:17.940Z
@NikeDattani because they are not connected in any way.
Adám
CC BY-SA 4.0
2023-05-16T18:17:45.100Z
They are connected because they're answers to the question :)
Nike Dattani
CC BY-SA 4.0
2023-05-16T21:08:20.880Z
Also worth adding that pasting code into e.g. comments on Stack Overflow, Facebook or other sites often does not preserve whitespace, so it becomes harder to discuss code examples with others online.
kaya3
CC BY-SA 4.0
2023-05-17T00:44:07.323Z
Just as an additional comment about this, Python makes the situation even worse than it could be because code blocks are not variable scopes. Moving a block of code means that any variables that are logically "local" to that block don't always hygienically move with it. JavaScript also has this problem without significant whitespace, but the combination in Python is a potential source of landmines.
Pseudonym
CC BY-SA 4.0
2023-10-18T18:10:43.433Z
Editors for languages with more restricted syntax than C can auto-format copy/pasted code so that indentation will match program semantics, allowing a programmer to look at the indentation and confirm that things are correct.  Having indentation auto-adjust to match other syntactic markers is more robust than having it be syntactically significant in and of itself.
supercat
CC BY-SA 4.0
2023-10-20T15:57:58.360Z
I run into this problem when pasting into the Python REPL. Along with the fact that it treats blank lines as closing all nesting levels, so you can't paste code with whitespace.
Barmar
CC BY-SA 4.0
2023-11-13T10:58:52.240Z
"An IDE that's aware of the language in use may be able to help with this, but plain text editors cannot."  I'm pretty sure plenty of text editors allow you to change indentation of multiple lines at once.  No one in the right mind will be coding in frigging Notepad.
Oskar Skog
CC BY-SA 4.0
2023-11-28T14:43:01.257Z
Coding in Notepad is quite common, as far as I know.
Someone
<h1>Writing a book</h1>
<p>Writing a book with code blocks in this language will be difficult, because between two pages, if a code block is cut in half, readers will have a hard time to figure out how many indentations the second page starts with.</p>

CC BY-SA 4.0
2023-05-16T17:54:25.700Z
2023-05-17T00:16:51.707Z
2023-05-17T00:16:51.707Z
ice1000
CC BY-SA 4.0
2023-07-08T18:05:29.973Z
Who writes code in books nowadays? And besides, you'd just implement feint vertical ruled lines.
Steve
CC BY-SA 4.0
2023-05-16T23:00:32.330Z
Can confirm. Worse is that some platforms will render PDFs where indentation is achieved by *moving the code to the right* rather than by inserting spaces. This means that copying code out of the PDF removes all indentation, because it was all just visual.
l0b0
CC BY-SA 4.0
2023-10-20T15:50:43.630Z
Even with braces, keeping track of nesting levels across page breaks is difficult. Humans don't generally find it easy to keep track of brace levels, that's why we expect code to be indented when the language uses braces.
Barmar
<h1>Tabs and Spaces</h1>
<p>In languages that support both tabs <em>and</em> spaces for indentation (*cough* Python), the compiler/interpreter often gets angry if you accidentally mix them, and keeping the one your project uses consistent can be hard without, or sometimes even <em>with</em>, a proper IDE.</p>

CC BY-SA 4.0
2023-05-16T17:55:11.733Z
2023-05-16T17:55:11.733Z
Ginger
CC BY-SA 4.0
2023-05-16T19:55:14.633Z
IMO this isn't an argument against using indentation for code blocks, it's an argument for not allowing programmers to mix tabs and spaces. :P
DLosc
CC BY-SA 4.0
2023-05-16T19:59:22.070Z
@DLosc Sometimes it's not intentional; I myself have frequently pressed Tab in unfamiliar IDEs, expecting it to be auto-converted to spaces, and been sorely disappointed several times.
Ginger
CC BY-SA 4.0
2023-05-16T20:11:02.923Z
Fair. It's too bad tabs vs spaces hasn't gotten to a similar place as different newline conventions, where it's fairly easy to convert between the different styles.
DLosc
CC BY-SA 4.0
2023-10-19T16:15:00.927Z
@DLosc: IMHO, it would have been helpful if programming languages had recognized some meta constructs that would have allowed files to contain information about how editors should process them which would be transparent to the rest of the language.  One of the things I liked about 1990s Macintosh was that each file had a resource fork and a data fork, and text editors could store things like tab stop settings in a resource fork that would be transparent to programs like C compilers.  Additionally, if an editor with an assigned application signature stored its settings in a resource...
supercat
CC BY-SA 4.0
2023-10-19T16:17:46.493Z
@DLosc: ...whose type matched that signature, it would be transparent to any program that didn't understand that resource type.  Things weren't perfect, but being able to have text files include such information meant that a text document that was intended to be displayed with two-character tab stops would configure a text editor that understood its setting resource to use two-character tab stops.
supercat
<h1>Limited auto-formatting</h1>
<p>Complete auto-formatting isn't possible. For a language where proper indentation and/or code layout can be inferred from the non-whitespace syntax, it is possible to completely automate formatting. Adjusting braces or keywords (only two per block) is often less work than aligning all the lines in the block.</p>

CC BY-SA 4.0
2023-05-16T17:50:26.750Z
2023-05-16T18:31:33.253Z
2023-05-16T18:31:33.253Z
Adám
CC BY-SA 4.0
2023-07-15T01:57:53.547Z
“Adjusting braces or keywords (only two per block) is often less work than aligning all the lines in the block.” If it is automatic how could it be more or less work?
Doryx
CC BY-SA 4.0
2023-07-16T06:22:21.490Z
@Doryx In the case where it isn't automatic, though it could have been.
Adám
CC BY-SA 4.0
2023-05-16T18:24:32.797Z
Languages like python *do* have auto formatting and it's used extensively. Formatting has less to do though since code that's syntactically valid is already somewhat properly formatted
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T18:26:15.697Z
@mousetail Right, but I tend to make a mess when editing my code, and then let the auto-formatter fix it all :-P
Adám
CC BY-SA 4.0
2023-05-16T18:27:33.480Z
I do the same in python. Often I leave blocks with too much indentation after, for example, removing a nested if, and the formatter will fix it for me. The formatter will also fix anything inside parenthesis.
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T18:31:42.923Z
@mousetail amended accordingly
Adám
CC BY-SA 4.0
2023-05-16T23:01:55.667Z
How is this different from not being able to format C++ code with broken bracket nesting?
l0b0
CC BY-SA 4.0
2023-05-17T04:42:04.773Z
@l0b0 Already addressed in the final sentence.
Adám
<h1>One-liners and code golf</h1>
<p>It will be difficult to write simple one-line code if code blocks must start at the second line. In <a href="https://en.wikipedia.org/wiki/Command-line_interface" rel="noreferrer">CLI</a> (command-line interface) applications, there are many use cases like <code>&lt;compiler&gt; -e &quot;one line expression&quot;</code>, which can be hard if the language requires indentation in code blocks.</p>

CC BY-SA 4.0
2023-05-16T17:56:02.873Z
2023-05-17T00:17:09.003Z
2023-05-17T00:17:09.003Z
ice1000
CC BY-SA 4.0
2023-05-20T00:42:09.323Z
Some languages solve that by having more than just newline as a separator token, often backslash or semicolon. Eg. `while x; f(x); g(x+1); end`
Longinus
CC BY-SA 4.0
2023-05-16T19:16:18.297Z
Appropriate considering most of us come from Code Golf.SE
Seggan
<h1>Accessibility</h1>
<p>For blind and visually impaired (B/VI) programmers, using indentation-sensitive languages with a screenreader has some extra challenges compared to free-format languages.</p>
<p>The most popular screenreaders are NVDA (free) and JAWS (commercial). You can configure them to speak whitespace, but it’s very noisy to hear <em>all</em> spaces, so it’s typical to set them to only speak the indentation level at the beginning of a line, particularly when moving the cursor to that line.</p>
<h2>Example</h2>
<p>So for example, in this code:</p>
<pre class="lang-python prettyprint-override"><code># Completion message

if work_complete:
    print(&quot;All done!&quot;)
</code></pre>
<p>A typical NVDA setup reads these lines as:</p>
<ol>
<li>no indent number completion message</li>
<li>no indent blank</li>
<li>no indent if work line complete colon</li>
<li>four space print left paren, quote all done bang, quote right paren</li>
</ol>
<p>And following are some observations about that.</p>
<h3>Presentation vs. Semantics</h3>
<p>Notice that the reader says “four space”, “eight space”, “twelve space”, which you need to mentally translate to “one indent”, “two indent”, “three indent”.</p>
<p>Perhaps that’s an argument for the use of tabs exclusively for indentation, or other ways of indicating nesting, or even avoiding it altogether.</p>
<h3>Keyboard Navigation</h3>
<p>Blind programmers tend to navigate entirely by keyboard, which is more convenient when there are paired delimiters at the start and end of a block. In Vim for example you can jump back and forth between brackets with <code>%</code>, and in Emacs you can use <kbd>M-n</kbd> <code>forward-sexp</code> and <kbd>M-p</kbd> <code>backward-sexp</code>. If I type a bracket that matches something far away (offscreen), Emacs gives a message saying what it matched.</p>
<p>I’m not blind, but I do use a keyboard almost exclusively. When programming indentation-based languages in Emacs, I find that I mainly need to navigate by jumping between blank lines instead (using the “paragraph” commands <kbd>M-{</kbd> and <kbd>M-}</kbd>).</p>
<h3>Punctuation Noise</h3>
<p>Punctuation characters are pronounced! Overall, Python is pretty good about this, <em>despite</em> the indentation, because it has relatively few and simple combinations of symbol characters, preferring words for common tasks.</p>
<p>Still, some symbols could be confusing. The comment delimiter of “number” can sometimes sound like a word that’s meant to be part of the comment text. ASCII unpaired quotation marks don’t tell you whether you’re at the start or end of a string.</p>
<p>Other symbols are just annoying. Python’s <code>snake_case</code> (“snake line case”) convention is slightly more readable for sighted users, because it reduces regressive saccades caused by missing the word boundary when scanning. But it’s less convenient for screenreaders, which deal better with <code>camelCase</code> (“camel case”) since that’s a reasonable default for non-code text.</p>
<h3>Resilience</h3>
<p>If indentation is the <em>only</em> way of indicating block structure, as in Python, then the lack of redundancy means that an auto-formatter can’t reliably recover the structure from non-indented code.</p>
<p>And for example, if you’re listening to a video about Python, and you can’t see the spacing, then you have to go and find the text file so you can hear what the spacing actually is.</p>
<h2>Alternatives</h2>
<h3>Optional Layout</h3>
<p>In some languages like Haskell, indentation is optional, in that it’s syntactic sugar for explicit braces and semicolons. This was intended to make it easier to generate Haskell code, but it has the side benefit that you don’t need to use layout if it’s inconvenient for you. In principle, with an autoformatter, you could view and edit the files with explicit delimiters, but check them in with just indentation. I’d really like to have a language setting <code>NoLayoutRule</code> that disables it entirely! With such an option, you could enforce it throughout a codebase.</p>
<h3>Braille Displays</h3>
<p>Some of these factors are less of an issue with Braille displays, but those still aren’t in widespread use—there have been some advances in the past couple decades, but consumer devices are still quite costly—a few thousand USD. A Braille display has much lower bandwidth than a text-to-speech screenreader, due to the limited size—a single line of 40 or rarely up to 80 characters—and limited refresh rate—at best, 20ms or 50fps. Their chief benefit over a screenreader is precision and usability by deaf &amp; hard-of-hearing (DHH) people.</p>

CC BY-SA 4.0
2023-07-04T17:07:31.413Z
2023-07-04T17:07:31.413Z
Jon Purdy
CC BY-SA 4.0
2024-02-21T17:31:29.933Z
Thanks for adding this interesting perspective! Are tabs better than spaces for screen readers? One `tab` equals one indentation level, while number of spaces depend on coding style and requires mental arithmetic to get the indentation level. Eg. `tab tab print quote hello world quote` vs `eight space print quote hello world quote`.
ximo
<h1>Restricted layout</h1>
<p>Freedom to indent without affecting meaning allows creative use of whitespace to illustrate structure and symmetries.</p>

CC BY-SA 4.0
2023-05-16T17:53:47.230Z
2023-05-16T18:22:44.897Z
2023-05-16T18:22:44.897Z
Adám
CC BY-SA 4.0
2023-06-02T14:47:02.557Z
@Bbrk24 This use-case is allowed in Python because the indentation occurs inside square brackets in an expression, rather than at the statement level. This might be an issue in other languages, though.
kaya3
CC BY-SA 4.0
2023-05-16T21:43:28.607Z
[Example](https://chat.stackexchange.com/transcript/message/63587818#63587818), since comments don't allow code blocks.
Bbrk24
<h1>Punch Cards and Coding Sheets</h1>
<p>Punch cards are limited to 80 columns. When you start adding white space on the left, you soon run out of space on the right.</p>
<p>Of course, if you're a business analyst, you aren't punching your own cards. You're writing the code on an 80 column coding sheet. It's formatted for FORTRAN and COBOL indentation, but if you start adding more white space on the left, the punch operators have to <em>count the spaces</em> to get the indentation correct. And if they get it wrong (they will - they operate at speed), then you have to correct and resubmit -- which adds another day or two to the turn-around.</p>

CC BY-SA 4.0
2023-10-18T09:46:42.200Z
2023-10-18T09:46:42.200Z
david
CC BY-SA 4.0
2024-02-21T17:39:21.127Z
Hate it when that happens.
ximo
<h1>Bad for frameworks using inline code</h1>
<p>Some languages such as PHP, JSP, ASPX, could be embedded in an HTML file. Sometimes people come up with the idea of doing similar things using Python. It would be awkward to keep the Python style indentation in the HTML file, so most would probably choose to use a simplified version that doesn't keep the full ability of Python. It would be much more awkward, if HTML was also using indentation this way.</p>
<p>A similar scenario is, some software may choose to use Python code in its configuration file, which is very reasonable. And some software may choose to not use a complete Python script, but mix the code with a traditional ini-style file. That is, one specific item could be set to a string which contains some Python code. Not being able to do this in one line may make the configuration file seemingly unnecessarily complex. It might be worse if the configuration file could contain arrays.</p>

CC BY-SA 4.0
2023-07-03T09:46:00.610Z
2023-07-03T09:46:00.610Z
user23013
<p>This isn't a <em>full</em> answer, just something I immediately thought of. The confusion between which style of indentation to use (spaces vs. tabs) and whether it's enforced is something to consider.</p>
<p>For example, Makefiles only allow tabs, while <a href="https://ninja-build.org" rel="nofollow noreferrer">Ninja</a> only allows spaces. Even <a href="https://ziglang.org" rel="nofollow noreferrer">Zig</a>, not even being a whitespace-sensitive language, considered it an <em>error</em> to use tabs instead of spaces as indentation (Note: this was changed and now not an error, although the built-in formatter (and the only one, really) only allows spaces)</p>
<p>What if you don't have a formatter installed for the language? Different files in the same project, or even parts of a single file could use different styles. This applies of course not only to indentation-based languages, but it might impact them more. Imagine merging two blocks that used two different styles, for example. The lexer/parser has to somehow determine what level of indentation each block is. What if a user's editor is displaying tabs as 8 spaces, but the language (or even another user) treats them as 4 spaces?</p>
<p>Another thing to consider: In my experience, beginners have a hard time writing indentation based code when starting to code, <strong>but</strong> it teaches them to indent code correctly. You've probably seen lots of terrible C code that doesn't get indented at all in most places...</p>

CC BY-SA 4.0
2023-05-16T17:56:23.767Z
2023-05-17T10:13:23.790Z
2023-05-17T10:13:23.790Z
monomere
CC BY-SA 4.0
2023-05-16T19:21:00.247Z
I have seen much code in non-indentation-aware languages, and yeah I haven’t “seen lots of terrible code”
Seggan
CC BY-SA 4.0
2023-05-16T20:09:15.923Z
@Seggan "lots" and "terrible" was an exaggeration, yeah. mostly beginner students or profs at universities do this kind of styling afaik
monomere
<h2>Introduction</h2>
<p>When I first found out that I would be using FORTRAN 77 for a summer job that I had when I was a student, I asked friends if they had any experience with FORTRAN. I would often hear them say things like:</p>
<blockquote>
<p>&quot;FORTRAN is such a <em><strong>nasty</strong></em> language. Indentation actually <em><strong>matters.</strong></em> Can you believe it? Indentation matters! You are not going to be enjoying this summer, good luck!</p>
</blockquote>
<p>Probably the <em><strong>biggest</strong></em> change between FORTRAN 77 and Fortran 90 (which still remains probably the biggest change between FORTRAN 77 and Fortran 2018) is that in Fortran 90 and newer version, <em><strong>indentation no longer matters</strong></em>.</p>
<p>Python didn't become popular until many years later, and I was shocked to see that &quot;indentation matters&quot; in Python. I thought Python was supposed to be a &quot;modern&quot; language? Why is it still like FORTRAN 77 in which indentation matters?</p>
<h2>Answer: Instability against accidental errors</h2>
<p>The drawbacks of a programming language using &quot;indentation&quot; to have any meaning other than just regular white space (which can be used to beautify or format the code in a readable way), become very apparent when you code in FORTRAN 77 and you realize how often you get a compile-time error due to the indentation being incorrect by just one character.</p>
<p><em><strong>This is why they made it so that indentation no longer matters in Fortran 90 and later versions.</strong></em></p>
<h2>Answer: Higher barrier to entry</h2>
<p>Another drawback is that in <em><strong>almost all other languages,</strong></em> whitespace or lack of it, does not carry such significant meaning, so when people try to copy your code and edit it, or when they try to write their own version of some snippet that they see on Stack Overflow, if they are not already experts they might ignore certain amounts of whitespace for aesthetic reasons, and they'll wonder why they're getting errors all the time. It saves a lot of people time if the language sticks to extremely well-adopted conventions, such as indentation not mattering.</p>
<h2>Why it's not a problem for most Python Coders</h2>
<p>Python programmers these days often use editors/IDEs like PyCharm and VS Code, but these do not work on all platforms, for example if you want to run calculations on a remote high-performance supercomputer that has nothing but a simple text-based command-line terminal, and no opportunity to output graphics to your computer screen. On such machines, the administrators will not give you &quot;root&quot; access to install PyCharm or VS Code. You are stuck with using Vi/Vim or maybe Emacs or Nano. In such an environment, soon you will notice how error-prone it is, to code in a language in which tabs and spaces are part of the actual syntax.</p>

CC BY-SA 4.0
2023-05-16T17:57:51.093Z
2023-05-16T17:57:51.093Z
Nike Dattani
CC BY-SA 4.0
2023-07-04T17:19:38.347Z
I write both Haskell and Python without using IDEs, and the indentation is not really difficult or error-prone at all. Vim is totally up to the task. (What is true is that Python's particular way of using indentation has some problems, and let's not even begin about Fortran 77, but none of this is helped with by IDEs.)
leftaroundabout
CC BY-SA 4.0
2023-05-16T18:26:23.770Z
I think especially on mainframes a indentation focused language is helpful. Otherwise lazy people will just write terribly formatted code. Python at least forces you to write somewhat legible code even when there is no IDE to help you
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T18:54:42.587Z
@mousetail then why is it that when changing from FORTRAN 77 (in which indentation matters) to Fortran 90, 95, 2003, 2008, and 2018 (in which indentation ***no longer matters***), they removed all syntax associated with indentation?
Nike Dattani
CC BY-SA 4.0
2023-05-16T18:57:31.150Z
One case of a language making indentation no longer matter does not prove significant white space is bad
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T19:05:05.800Z
@mousetail in nearly every language other than Python, indentation does not matter. Any Fortran programmer will tell you that the most profound change between F77 and F90 is that white space is no longer "significant" (to use your term), and that this was an extremely positive change. All of these things combined, provide compelling reasons to believe that "significant" white space (to use your term) is bad.
Nike Dattani
CC BY-SA 4.0
2023-05-16T19:07:47.027Z
There are a lot of languages where indentation does matter
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T20:23:19.517Z
@mousetail to use your argument again: The fact that there's languages where indentation does matter, doesn't prove that it's a good language design choice. **There's far more languages in which indentation does not matter, than languages where it does matter**.
Nike Dattani
CC BY-SA 4.0
2023-05-16T20:23:58.333Z
Many people prefer languages that have significant indentation, some prefer those that don't
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T20:31:17.670Z
[We both know it's the other way around: many people prefer for languages not to have "significant" indentation, some people do.](https://chat.stackexchange.com/transcript/message/63587461#63587461). Your next comment says that your point was not to compare numbers, but to say that both groups exist. Yet you said "many" for one of them and "some" for the other.
Nike Dattani
CC BY-SA 4.0
2023-05-16T20:31:52.060Z
I don't know numbers. My main point was not that more people prefer indentation, just that both groups exist
mousetail 'he-him'
CC BY-SA 4.0
2023-10-19T01:11:10.043Z
Note that many if not most F77 implementations offered Free Format (indentation does not matter).  It only made it to the standard in F90, which is why indentation is required if you specify F77 "standard mode".
david
CC BY-SA 4.0
2023-10-19T03:19:47.800Z
I don't think so.
Nike Dattani
CC BY-SA 4.0
2023-11-28T21:11:45.957Z
"I write both Haskell and Python without using IDEs, and the indentation is not really difficult or error-prone at all." This statement is an anecdotal fallacy. Just because some people don't find it a problem doesn't mean that it's not a problem. My own anecdote is that I was trying to learn Python and the tutorial added extra spaces to introduce what would be a bug in any other language, then asked to figure out what the code did. I got the correct one last, so I abandoned learning the language as it was all too easy to continue to make bugs like this. The tutorial said it was a feature.
computercarguy
CC BY-SA 4.0
2023-11-28T22:38:44.830Z
@computercarguy is correct.
Nike Dattani
CC BY-SA 4.0
2024-02-21T17:49:34.363Z
Most popular ≠ best. Most people like junk food (I'm proving a point, not saying braces are junk). Python is an immensely popular language, and Haskell is a highly regarded language made by some of the brightest heads in CS. I think it's mostly a matter of taste (qualia), and a conscious emphasis on readability by the language designers. There's no right or wrong, either style has its pros/cons.
ximo
# What are the drawbacks of using indentation for code blocks?
Posted by: username_0 on 2023-05-16
I'm not aware of any language other than Python that uses indentation to denote code blocks. To me, it seems like the simplest way to indicate blocks, and it also encourages proper formatting by making code not work if it is not indented properly. I would expect it to be more widely used; are there drawbacks that I'm missing?
**Tags:** language-comparison syntax whitespace indentation
> **Comments:**
> **username_3**: Haskell, occam, ABC, and various markup and data serialisation languages also use significant indentation.  
> **username_4**: Scala can use indentation instead of braces  
> **username_5**: Not a programing language but YAML is another one  
> **username_6**: Ambiguity if newlines/indentation break for some reason  
> **username_1**: Scala 3 lets you use both indentation and braces, so you can experience the worst of both worlds!  
> **username_2**: Makefiles, although not a programming language, also use indentation.  
---
## 13 answers
### Answer by username_3 on 2023-05-16. Score: 32
# Awkward code pasting

Copying/Cutting and pasting code becomes less than trivial, since the new location may need less or more indentation. An IDE that's aware of the language in use may be able to help with this, but plain text editors cannot.

In addition, various potential pasting destinations fail to preserve whitespace, e.g. comments on Stack Overflow, and messages on Zoom. Facebook and other sites often do not preserve whitespace, so it becomes harder to discuss code examples with others online.

On various forums, inexperienced users tend to paste in their code without putting it in a code block, so as usual with HTML, any amount of consecutive whitespace gets stripped down to a single space, completely altering the meaning of the code.

Finally, some languages, like Python, make the situation even worse than it could be because code blocks are not variable scopes. Moving a block of code means that any variables that are logically "local" to that block don't always hygienically move with it. JavaScript also has this problem without significant whitespace, but the combination in Python is particularly problematic.
> **Comments:**
> **username_0** (2023-05-16): So the idea is that you can copy the code, test it, then fix indentation if it works? The fact that indentation needs to be fixed when copying is one of the things that I see as a benefit of significant whitespace because it avoids incorrect indentation.  
> **username_3** (2023-05-16): @Someone Yes, or simply leave the indentation dirty, for a quick one-off or because it doesn't bother.  
> **username_13** (2023-05-16): Why don't you combine this with your other answers? 1-line answers are highly frowned upon in many SE sites, and here you have 3 sentences across 2 answers :)  
> **username_3** (2023-05-16): @NikeDattani because they are not connected in any way.  
> **username_13** (2023-05-16): They are connected because they're answers to the question :)  
> **username_10** (2023-05-16): Also worth adding that pasting code into e.g. comments on Stack Overflow, Facebook or other sites often does not preserve whitespace, so it becomes harder to discuss code examples with others online.  
> **username_14** (2023-05-17): Just as an additional comment about this, Python makes the situation even worse than it could be because code blocks are not variable scopes. Moving a block of code means that any variables that are logically "local" to that block don't always hygienically move with it. JavaScript also has this problem without significant whitespace, but the combination in Python is a potential source of landmines.  
> **username_12** (2023-05-18): Also, often on forums, people paste in their code without putting it in a code block, so as usual with HTML, the double spaces get stripped, removing the indentation. It's annoying when people do this but people do what they do.  
> **username_15** (2023-10-18): Editors for languages with more restricted syntax than C can auto-format copy/pasted code so that indentation will match program semantics, allowing a programmer to look at the indentation and confirm that things are correct.  Having indentation auto-adjust to match other syntactic markers is more robust than having it be syntactically significant in and of itself.  
> **username_16** (2023-10-20): I run into this problem when pasting into the Python REPL. Along with the fact that it treats blank lines as closing all nesting levels, so you can't paste code with whitespace.  
> **username_17** (2023-11-13): "An IDE that's aware of the language in use may be able to help with this, but plain text editors cannot."  I'm pretty sure plenty of text editors allow you to change indentation of multiple lines at once.  No one in the right mind will be coding in frigging Notepad.  
> **username_0** (2023-11-28): Coding in Notepad is quite common, as far as I know.  
---
### Answer by username_18 on 2023-05-16. Score: 32
# Writing a book

Writing a book with code blocks in this language will be difficult, because between two pages, if a code block is cut in half, readers will have a hard time to figure out how many indentations the second page starts with.
> **Comments:**
> **username_20** (2023-05-16): Can confirm. Worse is that some platforms will render PDFs where indentation is achieved by *moving the code to the right* rather than by inserting spaces. This means that copying code out of the PDF removes all indentation, because it was all just visual.  
> **username_19** (2023-07-08): Who writes code in books nowadays? And besides, you'd just implement feint vertical ruled lines.  
> **username_16** (2023-10-20): Even with braces, keeping track of nesting levels across page breaks is difficult. Humans don't generally find it easy to keep track of brace levels, that's why we expect code to be indented when the language uses braces.  
---
### Answer by username_21 on 2023-05-16. Score: 21
# Tabs and Spaces

In languages that support both tabs *and* spaces for indentation (\*cough\* Python), the compiler/interpreter often gets angry if you accidentally mix them, and keeping the one your project uses consistent can be hard without, or sometimes even *with*, a proper IDE.
> **Comments:**
> **username_22** (2023-05-16): IMO this isn't an argument against using indentation for code blocks, it's an argument for not allowing programmers to mix tabs and spaces. :P  
> **username_21** (2023-05-16): @DLosc Sometimes it's not intentional; I myself have frequently pressed Tab in unfamiliar IDEs, expecting it to be auto-converted to spaces, and been sorely disappointed several times.  
> **username_22** (2023-05-16): Fair. It's too bad tabs vs spaces hasn't gotten to a similar place as different newline conventions, where it's fairly easy to convert between the different styles.  
> **username_15** (2023-10-19): @DLosc: IMHO, it would have been helpful if programming languages had recognized some meta constructs that would have allowed files to contain information about how editors should process them which would be transparent to the rest of the language.  One of the things I liked about 1990s Macintosh was that each file had a resource fork and a data fork, and text editors could store things like tab stop settings in a resource fork that would be transparent to programs like C compilers.  Additionally, if an editor with an assigned application signature stored its settings in a resource...  
> **username_15** (2023-10-19): @DLosc: ...whose type matched that signature, it would be transparent to any program that didn't understand that resource type.  Things weren't perfect, but being able to have text files include such information meant that a text document that was intended to be displayed with two-character tab stops would configure a text editor that understood its setting resource to use two-character tab stops.  
---
### Answer by username_3 on 2023-05-16. Score: 21
# Limited auto-formatting

Complete auto-formatting isn't possible. For a language where proper indentation and/or code layout can be inferred from the non-whitespace syntax, it is possible to completely automate formatting. Adjusting braces or keywords (only two per block) is often less work than aligning all the lines in the block.
> **Comments:**
> **username_5** (2023-05-16): Languages like python *do* have auto formatting and it's used extensively. Formatting has less to do though since code that's syntactically valid is already somewhat properly formatted  
> **username_3** (2023-05-16): @mousetail Right, but I tend to make a mess when editing my code, and then let the auto-formatter fix it all :-P  
> **username_5** (2023-05-16): I do the same in python. Often I leave blocks with too much indentation after, for example, removing a nested if, and the formatter will fix it for me. The formatter will also fix anything inside parenthesis.  
> **username_3** (2023-05-16): @mousetail amended accordingly  
> **username_20** (2023-05-16): How is this different from not being able to format C++ code with broken bracket nesting?  
> **username_3** (2023-05-17): @l0b0 Already addressed in the final sentence.  
> **username_23** (2023-07-15): “Adjusting braces or keywords (only two per block) is often less work than aligning all the lines in the block.” If it is automatic how could it be more or less work?  
> **username_3** (2023-07-16): @Doryx In the case where it isn't automatic, though it could have been.  
---
### Answer by username_18 on 2023-05-16. Score: 16
# One-liners and code golf

It will be difficult to write simple one-line code if code blocks must start at the second line. In [CLI](https://en.wikipedia.org/wiki/Command-line_interface) (command-line interface) applications, there are many use cases like  `-e "one line expression"`, which can be hard if the language requires indentation in code blocks.
> **Comments:**
> **username_4** (2023-05-16): Appropriate considering most of us come from Code Golf.SE  
> **username_24** (2023-05-20): Some languages solve that by having more than just newline as a separator token, often backslash or semicolon. Eg. `while x; f(x); g(x+1); end`  
---
### Answer by username_25 on 2023-07-04. Score: 16
Accessibility
For blind and visually impaired (B/VI) programmers, using indentation-sensitive languages with a screenreader has some extra challenges compared to free-format languages.
The most popular screenreaders are NVDA (free) and JAWS (commercial). You can configure them to speak whitespace, but it’s very noisy to hear all spaces, so it’s typical to set them to only speak the indentation level at the beginning of a line, particularly when moving the cursor to that line.
Example
So for example, in this code:
# Completion message

if work_complete:
    print("All done!")

A typical NVDA setup reads these lines as:

no indent number completion message
no indent blank
no indent if work line complete colon
four space print left paren, quote all done bang, quote right paren

And following are some observations about that.
Presentation vs. Semantics
Notice that the reader says “four space”, “eight space”, “twelve space”, which you need to mentally translate to “one indent”, “two indent”, “three indent”.
Perhaps that’s an argument for the use of tabs exclusively for indentation, or other ways of indicating nesting, or even avoiding it altogether.
Keyboard Navigation
Blind programmers tend to navigate entirely by keyboard, which is more convenient when there are paired delimiters at the start and end of a block. In Vim for example you can jump back and forth between brackets with %, and in Emacs you can use M-n forward-sexp and M-p backward-sexp. If I type a bracket that matches something far away (offscreen), Emacs gives a message saying what it matched.
I’m not blind, but I do use a keyboard almost exclusively. When programming indentation-based languages in Emacs, I find that I mainly need to navigate by jumping between blank lines instead (using the “paragraph” commands M-{ and M-}).
Punctuation Noise
Punctuation characters are pronounced! Overall, Python is pretty good about this, despite the indentation, because it has relatively few and simple combinations of symbol characters, preferring words for common tasks.
Still, some symbols could be confusing. The comment delimiter of “number” can sometimes sound like a word that’s meant to be part of the comment text. ASCII unpaired quotation marks don’t tell you whether you’re at the start or end of a string.
Other symbols are just annoying. Python’s snake_case (“snake line case”) convention is slightly more readable for sighted users, because it reduces regressive saccades caused by missing the word boundary when scanning. But it’s less convenient for screenreaders, which deal better with camelCase (“camel case”) since that’s a reasonable default for non-code text.
Resilience
If indentation is the only way of indicating block structure, as in Python, then the lack of redundancy means that an auto-formatter can’t reliably recover the structure from non-indented code.
And for example, if you’re listening to a video about Python, and you can’t see the spacing, then you have to go and find the text file so you can hear what the spacing actually is.
Alternatives
Optional Layout
In some languages like Haskell, indentation is optional, in that it’s syntactic sugar for explicit braces and semicolons. This was intended to make it easier to generate Haskell code, but it has the side benefit that you don’t need to use layout if it’s inconvenient for you. In principle, with an autoformatter, you could view and edit the files with explicit delimiters, but check them in with just indentation. I’d really like to have a language setting NoLayoutRule that disables it entirely! With such an option, you could enforce it throughout a codebase.
Braille Displays
Some of these factors are less of an issue with Braille displays, but those still aren’t in widespread use—there have been some advances in the past couple decades, but consumer devices are still quite costly—a few thousand USD. A Braille display has much lower bandwidth than a text-to-speech screenreader, due to the limited size—a single line of 40 or rarely up to 80 characters—and limited refresh rate—at best, 20ms or 50fps. Their chief benefit over a screenreader is precision and usability by deaf & hard-of-hearing (DHH) people.
> **Comments:**
> **username_11** (2024-02-21): Thanks for adding this interesting perspective! Are tabs better than spaces for screen readers? One `tab` equals one indentation level, while number of spaces depend on coding style and requires mental arithmetic to get the indentation level. Eg. `tab tab print quote hello world quote` vs `eight space print quote hello world quote`.  
---
### Answer by username_5 on 2023-05-16. Score: 13
# Source code size

For interpreted languages, where the source needs to be sent over the Internet, like JavaScript, source code size is incredibly important. Having the option to just remove all white-space without losing meaning can save a lot of bandwidth in these cases.
> **Comments:**
> **username_8** (2023-05-17): But it also compresses extremely well(?). Representable by a few bits. And repeats (low entropy).  
> **username_7** (2023-05-18): I'm not aware of anything over (at least) the past decade that sends the JS code ***not*** gzipped. Yes, minifiers are often employed to reduce the size of the code, however, like @PeterMortensen says, the whitespace should compress extremely well. Minifiers do remove whitespace but they produce more value by converting other parts of the code.  
> **username_5** (2023-05-18): It's true compression will take out most of the bytes from the indentation but not all of them. It still makes a difference for big source files  
---
### Answer by username_9 on 2023-05-16. Score: 13
There is more than one way to define layout-sensitive programming languages, where indentation matters. The Python way is different from the Haskell way, which is different from the F# way... For reference see Michael Adams's Principled Parsing for Indentation-Sensitive Languages
For Python in particular, one of the biggest drawbacks of significant indentation is that lambdas cannot contain statements.
# Not allowed!
f = lambda x:
      if x: 
       print("hi")   

The reason for this is that Python ignores any indentation between parenthesis or brackets. This is how Python allows us to write multi-line expressions:
x = (1 + 
   2 + 
   3 )

Which Python treats as if you had written everything in the same line:
x = (1 + 2 + 3)

This means that expressions in Python cannot contain anything that cares about indentation. In particular, lambda expressions, cannot contain statements such as if or while, because those statements need indentation.
> **Comments:**
> **username_5** (2023-07-04): `fn()=>`Lambdas can not contain statements in PHP either even though it has bracket indentation. I don't think this choice is linked to the indentation system  
> **username_10** (2023-10-19): @mousetail It's very much related to the use of indentation for blocks. See [this other Q&A](https://langdev.stackexchange.com/q/1395/89).  
> **username_11** (2024-02-21): Thanks for the reference! Really useful for understanding how Haskell and Python parses indentations.  
---
### Answer by username_29 on 2023-05-16. Score: 8
This isn't a *full* answer, just something I immediately thought of. The confusion between which style of indentation to use (spaces vs. tabs) and whether it's enforced is something to consider.

For example, Makefiles only allow tabs, while [Ninja](https://ninja-build.org) only allows spaces. Even [Zig](https://ziglang.org), not even being a whitespace-sensitive language, considered it an *error* to use tabs instead of spaces as indentation (Note: this was changed and now not an error, although the built-in formatter (and the only one, really) only allows spaces)

What if you don't have a formatter installed for the language? Different files in the same project, or even parts of a single file could use different styles. This applies of course not only to indentation-based languages, but it might impact them more. Imagine merging two blocks that used two different styles, for example. The lexer/parser has to somehow determine what level of indentation each block is. What if a user's editor is displaying tabs as 8 spaces, but the language (or even another user) treats them as 4 spaces?

Another thing to consider: In my experience, beginners have a hard time writing indentation based code when starting to code, **but** it teaches them to indent code correctly. You've probably seen lots of terrible C code that doesn't get indented at all in most places...
> **Comments:**
> **username_4** (2023-05-16): I have seen much code in non-indentation-aware languages, and yeah I haven’t “seen lots of terrible code”  
> **username_29** (2023-05-16): @Seggan "lots" and "terrible" was an exaggeration, yeah. mostly beginner students or profs at universities do this kind of styling afaik  
---
### Answer by username_3 on 2023-05-16. Score: 7
# Restricted layout

Freedom to indent without affecting meaning allows creative use of whitespace to illustrate structure and symmetries.
> **Comments:**
> **username_26** (2023-05-16): [Example](https://chat.stackexchange.com/transcript/message/63587818#63587818), since comments don't allow code blocks.  
> **username_10** (2023-06-02): @Bbrk24 This use-case is allowed in Python because the indentation occurs inside square brackets in an expression, rather than at the statement level. This might be an issue in other languages, though.  
---
### Answer by username_27 on 2023-10-18. Score: 6
# Punch Cards and Coding Sheets

Punch cards are limited to 80 columns. When you start adding white space on the left, you soon run out of space on the right.

Of course, if you're a business analyst, you aren't punching your own cards. You're writing the code on an 80 column coding sheet. It's formatted for FORTRAN and COBOL indentation, but if you start adding more white space on the left, the punch operators have to *count the spaces* to get the indentation correct. And if they get it wrong (they will - they operate at speed), then you have to correct and resubmit -- which adds another day or two to the turn-around.
> **Comments:**
> **username_11** (2024-02-21): Hate it when that happens.  
---
### Answer by username_28 on 2023-07-03. Score: 4
# Bad for frameworks using inline code

Some languages such as PHP, JSP, ASPX, could be embedded in an HTML file. Sometimes people come up with the idea of doing similar things using Python. It would be awkward to keep the Python style indentation in the HTML file, so most would probably choose to use a simplified version that doesn't keep the full ability of Python. It would be much more awkward, if HTML was also using indentation this way.

A similar scenario is, some software may choose to use Python code in its configuration file, which is very reasonable. And some software may choose to not use a complete Python script, but mix the code with a traditional ini-style file. That is, one specific item could be set to a string which contains some Python code. Not being able to do this in one line may make the configuration file seemingly unnecessarily complex. It might be worse if the configuration file could contain arrays.
---
### Answer by username_13 on 2023-05-16. Score: 3
## Introduction

When I first found out that I would be using FORTRAN 77 for a summer job that I had when I was a student, I asked friends if they had any experience with FORTRAN. I would often hear them say things like:

> "FORTRAN is such a ***nasty*** language. Indentation actually ***matters.*** Can you believe it? Indentation matters! You are not going to be enjoying this summer, good luck!

Probably the ***biggest*** change between FORTRAN 77 and Fortran 90 (which still remains probably the biggest change between FORTRAN 77 and Fortran 2018) is that in Fortran 90 and newer version, ***indentation no longer matters***.

Python didn't become popular until many years later, and I was shocked to see that "indentation matters" in Python. I thought Python was supposed to be a "modern" language? Why is it still like FORTRAN 77 in which indentation matters?

## Answer: Instability against accidental errors

The drawbacks of a programming language using "indentation" to have any meaning other than just regular white space (which can be used to beautify or format the code in a readable way), become very apparent when you code in FORTRAN 77 and you realize how often you get a compile-time error due to the indentation being incorrect by just one character.

***This is why they made it so that indentation no longer matters in Fortran 90 and later versions.***

## Answer: Higher barrier to entry

Another drawback is that in ***almost all other languages,*** whitespace or lack of it, does not carry such significant meaning, so when people try to copy your code and edit it, or when they try to write their own version of some snippet that they see on Stack Overflow, if they are not already experts they might ignore certain amounts of whitespace for aesthetic reasons, and they'll wonder why they're getting errors all the time. It saves a lot of people time if the language sticks to extremely well-adopted conventions, such as indentation not mattering.

## Why it's not a problem for most Python Coders

Python programmers these days often use editors/IDEs like PyCharm and VS Code, but these do not work on all platforms, for example if you want to run calculations on a remote high-performance supercomputer that has nothing but a simple text-based command-line terminal, and no opportunity to output graphics to your computer screen. On such machines, the administrators will not give you "root" access to install PyCharm or VS Code. You are stuck with using Vi/Vim or maybe Emacs or Nano. In such an environment, soon you will notice how error-prone it is, to code in a language in which tabs and spaces are part of the actual syntax.
> **Comments:**
> **username_5** (2023-05-16): I think especially on mainframes a indentation focused language is helpful. Otherwise lazy people will just write terribly formatted code. Python at least forces you to write somewhat legible code even when there is no IDE to help you  
> **username_13** (2023-05-16): @mousetail then why is it that when changing from FORTRAN 77 (in which indentation matters) to Fortran 90, 95, 2003, 2008, and 2018 (in which indentation ***no longer matters***), they removed all syntax associated with indentation?  
> **username_5** (2023-05-16): One case of a language making indentation no longer matter does not prove significant white space is bad  
> **username_13** (2023-05-16): @mousetail in nearly every language other than Python, indentation does not matter. Any Fortran programmer will tell you that the most profound change between F77 and F90 is that white space is no longer "significant" (to use your term), and that this was an extremely positive change. All of these things combined, provide compelling reasons to believe that "significant" white space (to use your term) is bad.  
> **username_5** (2023-05-16): There are a lot of languages where indentation does matter  
> **username_13** (2023-05-16): @mousetail to use your argument again: The fact that there's languages where indentation does matter, doesn't prove that it's a good language design choice. **There's far more languages in which indentation does not matter, than languages where it does matter**.  
> **username_5** (2023-05-16): Many people prefer languages that have significant indentation, some prefer those that don't  
> **username_13** (2023-05-16): [We both know it's the other way around: many people prefer for languages not to have "significant" indentation, some people do.](https://chat.stackexchange.com/transcript/message/63587461#63587461). Your next comment says that your point was not to compare numbers, but to say that both groups exist. Yet you said "many" for one of them and "some" for the other.  
> **username_5** (2023-05-16): I don't know numbers. My main point was not that more people prefer indentation, just that both groups exist  
> **username_30** (2023-07-04): I write both Haskell and Python without using IDEs, and the indentation is not really difficult or error-prone at all. Vim is totally up to the task. (What is true is that Python's particular way of using indentation has some problems, and let's not even begin about Fortran 77, but none of this is helped with by IDEs.)  
> **username_27** (2023-10-19): Note that many if not most F77 implementations offered Free Format (indentation does not matter).  It only made it to the standard in F90, which is why indentation is required if you specify F77 "standard mode".  
> **username_13** (2023-10-19): I don't think so.  
> **username_31** (2023-11-28): "I write both Haskell and Python without using IDEs, and the indentation is not really difficult or error-prone at all." This statement is an anecdotal fallacy. Just because some people don't find it a problem doesn't mean that it's not a problem. My own anecdote is that I was trying to learn Python and the tutorial added extra spaces to introduce what would be a bug in any other language, then asked to figure out what the code did. I got the correct one last, so I abandoned learning the language as it was all too easy to continue to make bugs like this. The tutorial said it was a feature.  
> **username_13** (2023-11-28): @computercarguy is correct.  
> **username_11** (2024-02-21): Most popular ≠ best. Most people like junk food (I'm proving a point, not saying braces are junk). Python is an immensely popular language, and Haskell is a highly regarded language made by some of the brightest heads in CS. I think it's mostly a matter of taste (qualia), and a conscious emphasis on readability by the language designers. There's no right or wrong, either style has its pros/cons.  
---
