... and I didn't question why.

And thus is born tradition based on ..., actually I'm not sure what it's based on. Much bad process is a result of "because that's how I was told to do it" or, even worse, "that is how we did it at ...". From coding to coffee making to many other fields, progress is only made when people ask "Why?". The question shouldn't be judgmental or intended to create contention, but just for understanding and considering options. Emotive answers are almost always unhelpful, but white space and indentation issues often head that way.

From coding to coffee making to many other fields, progress is only made when people ask "Why?"

Thankfully, in the intervening quarter of a century I have become much better at asking WHY!

Indeed, a core part of my business culture revolves around the Four C's: We Create, we Communicate, we Care about our clients and colleagues and we do everything with Curiosity

We hire against those criteria and our Core Competencies, Job Descriptions and Assessments are all based around those simple Four C's.

For cheap thrills, I googled Four Cs just now and found:

• Cooperation, Collaboration, Contribution, Community
• Customer focus, Culture, Credibility, Competency
• Critical thinking, Creative thinking, Communicating, Collaborating
• Curiosity, Connection, Compassion, Courage
• Clarity, Consistency, Compassion, Curiosity

... but I like your business culture Four Cs the best! I especially like the way you phrased it. You seem to be growing an impressive business culture.

You might think it doesn't matter whether you use spaces or tabs. Yet be very wary when using the make build automation tool. In what Eric S Raymond described as "one of the worst design botches in the history of Unix", semantic meaning was assigned to a TAB character in column one of makefiles!

This tragic UI blunder has cost thousands of hours of lost productivity over many years. I've personally suffered, puzzling over cryptic error messages from make after my editor automatically converted TABs to spaces ... so I naturally singled it out as an example of a UI mistake when I wrote On Interfaces and APIs:

The Unix make utility decrees that the actions of a rule must start with a tab. If you accidentally insert a space before the leading tab, look out! Ditto if your editor or other tool is configured to automatically convert tabs to spaces. This unfortunate design choice is a violation of the principle of least astonishment because most programs treat spaces and tabs the same way. Moreover, when you hit a (typically cryptic) error message for using a space instead of a tab, it may take a long time to figure out what the problem is because tabs and spaces look the same in most editors.

Is this a case of academia being out of touch with working practices or has the favour of spaces changes in the last quarter of a century?

Gofmt formats Go programs. It uses tabs for indentation and blanks for alignment.

The problems of the tab character "\t" were not as apparent in the 1990s like they were later.

Different contexts have different indentation settings, while most people agree on 4 columns nowadays, do most apps default to 8 columns, which used to be standard.

The chaos starts if people mix tab with space and everything looks perfectly indented in their own editor, but once it's opened with another editor ... or posted to perlmonks, it becomes a mess (yes browsers default to 8).

I actually use the tab-key for indentation, but my editor has a setting to insert space. And a command to "untabify" foreign code.

One benefit of "\t" is that it can be easily reverted with one backspace instead of four. But again, this can be fixed with modern editors and I use automatic indentation anyway.

And I wasn't talking about semantic effects.

Perl code is thankfully resilient against "\t" vs " " confusion, and whitespace rarely matters.

But ask the Pythonistas what they think was Guido's biggest design error...

In short: Academics in the 2020 wouldn't say this anymore.

As described nicely in this blog, the pro-TABS camp (including golang) exhort you to use TABs for indentation only, never for alignment:

It's very important to only use spaces for alignment. Never, ever, use tabs for alignment. Tabs may be used for indentation only.

I suspect this important distinction was not widely known in the 1990s, at least I don't remember it being mentioned back then.

I don’t know about programming but even in the 80s—and probably at least the 60s when the Selectric entered the game—tabs in typing and typesetting were format control signifiers without a predefinition; set by document, style declaration, or even a single line. They had no set spacing or even justification. These are all valid tabs and part of why I think tabs have no business in code.

[one tab]Text…
           [one tab]Text…
          [one tab]Longer…
                             [one tab]Text…
                      [one tab]Longer text…
[download]

AFAIK does golang have a fixed opinionated formatting everybody must accept and the formatter is built-in.

In this rigid case you are free to do this, and every body can decide which tab size he wants when reading golang code.

In our case this would equate to force all code posted on PM thru perltidy with fixed settings.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}