Hacker News Reader

Comment by Qworg | Hacker News Reader

This is the exact opposite of what I want in C++.

The use of characters to clearly delineate code sections and scope is a strong benefit of C++ over these other languages. They're not a "source of errors" - they allow a competent programmer the opportunity to quickly reason about the structure of the code. If vertical compression is an issue - get a bigger monitor or an IDE that allows for code hiding.

It is also far better to have a "oops, I missed a brace" error that your compiler/IDE catches, versus a "man, why does my program keep seg faulting unexpectedly" error that takes hours to track down since you missed a single tab somewhere.

View on HN

I'm not sure what your complaint is here. With whitespace sensitivity, "oops, I missed a brace" and "oops, I missed a tab" is exactly the same. Your compiler/IDE would catch it, just as it would any other syntax error. The difference (arguably) is that it's easier to spot (because that's how humans read code).

I would argue that whitespace sensitivity makes those kinds of errors less likely, not more. Curly braces everywhere lead to a lot of visual noise, and can obscure what the code is doing. Consider the classic C syntax error:

    if (foo > bar) 
        printf("Hey!\n");
        return foo;
    return bar;

With whitespace sensitivity, this would do what you think it would. With curly braces, it's misleading.

Whitespace sensitivity also introduces some similar problems. For example, if the printf is indented with spaces and the return foo is indented with tabs, the return will be put outside the if, even though it looks like its inside.

TBH, the real problem with C is not the braces - its that braces are optional.

>For example, if the printf is indented with spaces and the return foo is indented with tabs, the return will be put outside the if, even though it looks like its inside.

Python 3 deals with this by throwing a warning about inconsistent use of tabs and spaces before it even finishes parsing the file (so basically before runtime). There's no reason why any other language can't do the same.

I think tabs vs spaces problem is silly and nobody should be using tabs. Editor should be showing tabs in red and asking the user to clean them up.

I switched from tabs to spaces about a decade ago and I've never regretted it. I seldom find files written by crazy people who think 8 spaces is a viable tab width anymore so I can pretty much adjust to whatever nice 2 space or wasteful 4 space width the original file authors used.

Back in the 1970s, I chose tabs to save bytes in my text files. Today I feel like I can afford the extravagance.

I think the tabs vs spaces problem is silly and nobody should be using spaces[1]. Compilers should treat leading spaces as a syntax error.

Clearly we both can't be pleased. ;)

[1] Except in Lisp.

Every social problem has a simple, rational solution: forbid (and strongly enforce it) anybody making, owning, or talking about, any of the following:

- editors that allow one to set tab width different from 1.

- editors, compilers, and OSes that distinguish tabs from spaces in any way (display of invisible characters, search).

- revision control systems that do not randomly replace spaces by tabs and vice versa in all text files.

If you used our coding style (haskell-ish) you would have no problems with tabs. Keep stuff logically towards the left to make quick scanning easier.

Most languages that are whitespace sensitive don't actually allow you to mix indentation. In fact, Python 2 will give you an error saying that a particular line doesn't match indentation level if it's a different number of spaces and 3 will give you a warning (and since warnings can be made into errors...).

> With whitespace sensitivity, "oops, I missed a brace" and "oops, I missed a tab" is exactly the same.

No. There are two braces per block and as long as you are consistent and always use braces even for single-statement if(){}, you need to miss two braces for equivalence with missing one tab. You also get the benefit that the editor can trivially re-indent your code without actually changing its meaning.

> They're not a "source of errors" -

Yeah I am not entirely agreeing with "source of errors". Usually it is other things like inconsistent syntax or (I am just making it up here) error intolerant syntax. And by that I mean things like:

* I am allowed to use single '=' and '==' in a conditional (in C++). Program still compiles, runs and probably doesn't do what I expect.

* In Python, if I leave an extra , at the end of a variable it creates a tuple ( x = a vs x = a, ). Program still compiles and runs but probably doesn't do what I expect.

* In general think of the time you spent hours and days hunting a bug that ended up being a one character error like above.

In either case, it would be nice if compilers or linters should warn you...

But anyway, I don't think as you were saying, {} are necessary a cause for more or less "errors"

But, { } are a source of visual noise. I think it clutters the screen and it provides an opportunity for strange syntax. When I scan code quickly I don't match up parentheses, I look for nicely formatted and indented blocks of code first. Whitespace and indentation is best for that.

There shouldn't be 100+ page style guides for how to format a language, it should have a one, best, clearest, default formatting and it should be used by everyone. That, I found after programming Python for almost 10 year now, is very helpful.

> This is the exact opposite of what I want in C++.

This is the exact response I was expecting to go to the top of hacker news -- negative and dismissive. Also, it's nonsense.

Go to a Python mailing list, and count the number of emails complaining that "my program keeps seg faulting unexpectedly" due to "missing a single tab somewhere". Can't find any examples? Well, it would appear that Python coders are more competent than you.

Alternatively, perhaps our eyes and brain are intrinsically wired to easily detect vertical and horizontal lines. Maybe that's why they're so prominent in design -- just a thought. And maybe that's why all C++ programs have some scheme of indentation to denote scope anyway.

I really hate that whenever someone makes a proposal for a language, the zealots, be they lisp or C++ or whatever, immediately come out of the woodwork to heap scorn upon the idea. Personally, I think the kind of change proposed by the OP (with a few modifications) would be really nice, and would give the language a more Pythonic flavour, which isn't called executable pseudocode for nothing.

> If vertical compression is an issue - get a bigger monitor or an IDE that allows for code hiding.

You need to listen to yourself type.

Maybe this is true, but I am just having a real hard time believing a fresh syntax is going to solve any real problems with C++. To do that a language with better semantics is needed, which is a much tougher problem being tackled by D, Rust, etc...

> I really hate that whenever someone makes a proposal for a language, the zealots, be they lisp or C++ or whatever, immediately come out of the woodwork to heap scorn upon the idea.

I often wonder if contrarianism is so prevalent in community discussions simply for the sake of disagreement or to provoke negative emotion. It's completely counter to constructive criticism.

Although to be fair, there are some comments to the contrary that at least make a passing effort to explain what they don't like about the suggestion and why they dislike whitespace languages in general, so I can't tar everyone with the same brush.

That said, considering some of the outright vitriol, I almost feel like someone ought to implement it on principle alone.

> my program keeps seg faulting unexpectedly

Python scripts segfault?

Yeah, I expected a mixed response. The "missed tab problem" always crops up and is vastly overblown. C++ of course has the "misplaced semicolon" counterpart to it:

    while (i < 100); //loop body is empty
    {
        // random unnamed block instead of loop body
    }

Oh, and it's kind of difficult to get a bigger screen on a laptop.

Reply on news.ycombinator.com