Things that Dennis Ritchie got wrong.

lightsoff

@created_just_to_disl said:

Python doesn't count whitespace and nobody would ever like a language that did.
It just compares amounts of whitespace, just like people are already experts at doing.

No, people are pretty awful at both typing and comparing whitespace.
Consider the following monospaced (thus easy) text:

indentation
of stuff
  which
    is
        fine
        and dandy
   I suppose
oh crap

There's two big issues here:

I used a tab for one of those lines, so that line is either indented by one character or by an editor-defined number.
(Discourse has of course replaced the tab with spaces so it's changed the meaning before I even posted it.)
Assuming all-spaces, which block does the line "I suppose" belong in?
If you look carefully you'll notice that it's a syntax error in Python - but what indentation did I mean?

This class of error simply doesn't occur in any language that uses explicit BEGIN_BLOCK and END_BLOCK tokens, whether braces or some other token.

[size=10]PS: The Python tokenizer absolutely does (and must) handle whitespace by counting it, how else would it figure out how many DEDENT tokens to produce? A program can drop back more than one indentation 'level' in one go.
Also doing anything else would be Bloody Stupid™[/size]

CreatedToDislikeThis

Tab vs. spaces - I don't think python solves this well, but a good solution is to disallow mixing spaces and tabs for indentation. Problem solved. (And as usual with whitespace-significant languages, that's a good idea in other languages as well).
Indentation of I suppose - as you yourself said, python already solves this by requiring matching indentation.

Those class of errors absolutely do occur in languages with explicit block begin and end, except then - rather than the compiler telling you to get your mess together, you get unexpected program behaviour.

[size=9] P.S. counting vs. comparing: Okay, yeah - I'll give you that one. But the original point (that you need to count whitespace in order to avoid mistakes in python-style syntax) is still wrong. I never had to count whitespace - I could just instantly compare it and can get an error if I use invalid indentation.[/size]

(And let the holy war continue)

tar

@lightsoff said:

Discourse has of course replaced the tab with spaces so it's changed the meaning before I even posted it.

PleegWat

@lightsoff said:

As HTML strips out 'unnecessary' whitespace, giving whitespace any significance must be Doing It Wrong™

FTFY

dkf

@lightsoff said:

Also doing anything else would be Bloody Stupid™

Like that stops anyone.

@created_just_to_disl said:

Those class of errors absolutely do occur in languages with explicit block begin and end, except then - rather than the compiler telling you to get your mess together, you get unexpected program behaviour.

Errors relating to uncertain levels of whitespace? WAT? Or errors relating to uncertain levels of nesting? (Really quite rare.)

Musaran

@lightsoff said:

Most C-style language IDEs have automagical whitespace formatting features

- How about the opposite : does indenting a line automagically add braces ?

The fact that we need automagic to keep indent and nesting in sync just proves that it is semantically the same thing and should never have been split.

@lightsoff said:

computers are really good at counting while humans aren't, especially with proportional fonts - is this one space or two?Even worse - is it one tab or 2...8 spaces?

Several solutions :

The editor shows tabs, like most word processors can do.
The language forbids mixing anything between nesting tabs.
The language requires a no-operation symbol between nesting tabs and alignment whitespaces, like that :
( ␉___ represents tab, · represents space )
␉__int Func(int a, ␉__:········int b)
or
␉___int Func(␉int a, ␉___:␉________int b)

This requires support from the editor, but I am ok with that.
Any serious coding is done in a language-aware editor anyways.

@lightsoff said:

As Discourse strips out 'unnecessary' whitespace, giving whitespace any significance must be Doing It Wrong™

I think it is actually the opposite :

C popularized the idea that whitespace is meaningless.
HTML was designed inheriting that mindset.
Web tools were designed inheriting that mindset.

Imagine if C had done it the other way, everything else followed, and today someone came and said :

Hey, let's keep indenting because it is readable, but change the language to not make any use it.
Instead, we have to add extra symbols everywhere, shooting ourselves in the foot if we do it wrong.

What would be the reception ?

dkf

@Musaran said:

I think it is actually the opposite :

C popularized the idea that whitespace is meaningless.
HTML was designed inheriting that mindset.
Web tools were designed inheriting that mindset.

You have a non-standard interpretation of history.

lightsoff

@created_just_to_disl said:

Indentation of I suppose - as you yourself said, python already solves this by requiring matching indentation.

whoosh
No, it doesn't solve it. This syntax error occurs if I press {backspace} or {space} either too many or too few times.

How do you tell which of those two typos I made?
It's not possible by inspection, thus there is a 50/50 chance of introducing a bug to fix the syntax error.

In an enforced BEGIN/END syntax, there is no* way to make a typo that gives you a syntax error where you can't tell whether or not a given token was supposed to be an END or continuation of an existing block.

You can still fuck up either way, it's just that there are fewer fuckups available.

I do subscribe to the C/C++ code style of "braces are always required", as that would again reduce the fuckup-ability. It's a shame that the language itself doesn't - though some other C-like syntax languages do.

[size=10]*Unless you use a variable called "en" in something that uses "end" to close a block, but then you're an idiot and there's no saving you.[/size]

Brook_Monroe

if() and for() and while() (et.al.) are functions, not statements. Functions in C require parentheses. Moving away from that would make them statements, and then the language isn't C anymore.

Pulling the most off-the-rails example of switch() and using it to malign an entire function isn't really logically or semantically supportable. Cascading if() clauses are far worse to maintain. The value to switch() is that compilers can (sometimes) convert the code to JMP tables, which is very efficient; the same cannot be done with a waterfall of if() clauses.

The new casting syntax does make for better searching--but it makes for less readable code. On the other hand, there are those who say that if you have to cast at all, you might be taking the wrong approach and a refactor might be in order.

Any feature can be abused; the fact that abuse is possible doesn't require that a feature be removed. It might mean that the abuser needs to be removed, though.

boomzilla

@lightsoff said:

Most C-style language IDEs have automagical whitespace formatting features that you can trivially configure to use any reasonable corporate style. (Including enforcing K&R, ANSI/ISO etc)

I hate these, because no matter what style you want to use, there are places that should be exceptions, according to the way things look to me.

dkf

@Brook_Monroe said:

if() and for() and while() (et.al.) are functions, not statements.

What language are you using? It's surely not C, where if, for and while are all keywords and so cannot be functions. (I know of languages where what you say is indeed true, such as Forth, but I doubt you're talking about them.)

PJH

@Brook_Monroe said:

Functions in C (are one of the things that) require parentheses

FTFY. Which is why you're clearly trolling with this...
@Brook_Monroe said:

if() and for() and while() (et.al.) are functions,

Gąska

Fun fact: in Rust, if and other conditional constructs are expressions.

another_sam

@Gaska said:

Fun fact: in Rust, if and other conditional constructs are expressions.

In Scala, if() and for() are expressions, while() returns Unit which is similar to void in C-like languages.

another_sam

@Brook_Monroe said:

there are those who say that if you have to cast at all, you might be taking the wrong approach and a refactor might be in order.

These people have never written C, where types are pretty loose.