Actually, I'm curious why people don't like white space sensitive languages. I get the tab v space thing, and there are certainly a couple of other down sides, but none of these seem like deal breakers to me. Given that python was the second language I learned, it's possible that I drank the coolaid early and I'm blind to some things that are truly egregious.

So the question is: why do folks completely avoid a language for a single relatively bland syntactic feature? Is there some cost I'm not aware of, or is it just stylistic/aesthetic?

> why do folks completely avoid a language for a single relatively bland syntactic feature?

Personal preference isn't a good enough reason?

I don't like white space sensitive languages because I've seen what happens in python when somebody accidentally adds a couple of lines formatted with spaces into a file formatted with tabs. I've seen git and svn mangle tabs. Long blocks are harder to track. Refactoring functions and nested ifs are much harder to keep track of. If you somehow lose all of the formatting in a block or a file, it's much more difficult to recreate the code if the only block delimiters are whitespace.

Essentially, white space delimiters are just one more thing that can go wrong and ruin my day. I try to keep those to a minimum. That said, Nim is my new go to for short scripts. I wouldn't write anything large in it for the reasons mentioned above.

Nim disallows tabs entirely, and in Python 3 it's an error to mix the two in the same file. So those errors can't happen anymore.

Out of your list, the only one that seems like a real problem is recreating blocks if the code lost all formatting.

You just described two errors that do actually happen and in the next sentence say those errors can't happen anymore. What am I missing here?

The comment I replied to was talking about errors arising from mixing tabs and spaces and incorrect indentation levels that arise from it.

If a language either disallows tabs entirely or will refuse to run/compile code that mixes tabs and spaces in the same source file, you obviously can't get errors related to mixing tabs and spaces.

loosing parts of your code is bad. The same goes for braces, if you loose them in a big c program your day is ruined as well.

To me, braces are simpler and more explicit, but then I drank the C/C++ koolaid.

Whitespace is intended for human readability, with spaces and tabs not having any implicitly contradictory meaning. In a whitespace sensitive language, you have to set your text editor to make those invisible characters visible to make certain to only use the correct invisible character, then employ multiple such characters based on the necessary level of indentation to do the work of a single set of braces.

I know this has been said before but for me it's as simple as:

"Format your code as you would have done anyway but just leave out the curly braces".

It reduces rather than increases the number of things I have to think about.

My problem with this is that you have to make sure every contributor has the same editor settings. You have to also configure every editor before you can use it to write code in such a language, which is sometimes impractical.

Curly braces make this not an issue an they're visible. I don't want to depend on non-visible characters for behavior, but it's only a personal preference.

> you have to make sure every contributor has the same editor settings

You have to do that in any language. Ever worked on a C/C++ files where the indentation is different from your settings? I see only 2 choices: either you temporarily adapt your settings, or you just cringe your way through.

The third alternative (use your own settings anyway), is just lazy and mean.

> I don't want to depend on non-visible characters […]

There's an easy solution. First, either forbid or mandate tabs for indentation. Second, forbid trailing whitespace. That way all spaces will be visible.

> My problem with this is that you have to make sure every contributor has the same editor settings. You have to also configure every editor before you can use it to write code in such a language, which is sometimes impractical.

I'm not aware of ever having to do any of these things. I'm not even sure what you mean by "configure". Every editor I've installed has always done the right thing out of the box and every contributor who isn't completely incompetent has done the right thing naturally.

Compared to my experience in curly-brace languages where indentation holy wars about and it's actually painful to read code in with a brace style you're not used to - I have more respect for the wisdom embedded in Python and PEP8 daily.

For me, the process is "just write the braces, the editor/tooling will do the formatting for you", so no difference.

Except my code looks prettier than yours. ;-)

Joking aside and as silly as it is to talk about "objective aesthetics" - surely you can see an argument for "less clutter == better" - as much as you've trained yourself to not see the braces, they add nothing that indentation doesn't already provide other than visual noise.

Yeah, no, I think code with braces looks better....

Objective asthetics? As far as I'm concerned, the tabs vs. spaces debate has basically proven that it doesn't exist for programming languages... (I'm rabidly pro-tabs, by the way). Maybe some of it is "trained myself not to see the braces", but it looks wrong without them.

All that aside, you just moved the argument from "My way is faster/less work" to "My way looks better", which is somewhat objective -> subjective.

> you have to set your text editor to make those invisible characters visible

Or you set it to replace one with the other, and not bother you.

Still more work than just using braces.

>Still more work than just using braces.

How so? It's a one time change to a setting in your editor, vs thousands and thousands of keystrokes.

I don't have to change anything in my editor all to use braces, I can just use them.

No extra work is less work than even a little.

It really bothered me in python, but for some reason I didn't mind it in F#. Of course, some of that may be related to the fact that I enjoyed F# so much that I was willing to put up with significant whitespace. Or perhaps it's just been too long since I've used python and today it would bother me less.

I thought F# was roughly an Ocaml clone. What significant whitespace does it have?

I'm pretty sure whitespace in F# is one way to control blocks. So anything further indented than an if is part of the if block. I'm definitely not an F# expert though, so I'm sure there's more to it than just that.

I also think there's a way to write F# that doesn't have significant whitespace, but uses a lot more keywords. Verbose syntax, I think that's called. I almost never see examples written that way, though.

I can't speak for F#, but it does have its origins in Ocaml, and whitespace doesn't matter there. Try putting that entire if-block (or any other statement) all one one line, just to see what happens.

Last I checked, Crystal had a tendency to use union types where it should use sum types. For example, if you have an array and you pop it and get nil, there's no way of knowing if you got nil because the array was empty or because the popped element was nil.

Nim is my first whitespace-sensitive language. I had no plans to love it. We're now engaged.

When's the wedding? :D

exactly, they're just better ;)

> I do not enjoy whitespace-sensitive languages

Out of curiosity, why? What’s wrong with using whitespace to organize things?