[rescue] Python > 3.6 on Solaris 10

[Liam Proven]

On Mon, 18 Oct 2021 at 12:58, Peter Corlett <abuse at cabal.org.uk> wrote:
>
> I posit that the Haskell and Lisp examples listed are transcribed from
> Haskell and Lisp syntax and are not used in brace-delimited languages.

I bet any imaginable system is used by some
people/projects/communities somewhere. Or worse, combinations or
mix-and-match blends of different indentation styles.

I work in XLM 95% of the time these days. (Pity me...)

One of my colleagues has switched from Emacs  to VS Code and has
become quite the evangelist for it. His indentation is OK, but he
doesn't line wrap at all any more and so new lines can be hundreds of
characters long. I don't know what VS Code does for him but he can't
see it -- I presume it's soft-wrapping it and not showing him the
difference, making it impossible for him to tell.

I mostly work directly in Github and it breaks it very badly.
Invisible scrollbars far off the top or bottom of the window and
broken inconsistent keystrokes. I have to make edits to his source to
hard-wrap it just to read the wretched stuff.

Another colleague, the woman I was hired to cover for when she was on
maternity leave, just ignores indentation completely. Most of her code
is just flat against the left margin and when there is indentation it
is 100% totally random. She doesn't seem to even see it. Reading her
edits is a nightmare.

> Further, many of the others are uncommon or project-specific and date back
> to when we were still figuring out these things.

Agreed.

> Most code I encounter seems to be more or less K&R: modern machines have
> 16:9 or 16:10 widescreen displays, applications and operating systems add
> menubars and toolbars to the top and/or bottom, and this leads to styles
> which aren't profligate with vertical space if the developer wants a
> reasonable amount of code on screen at once.

A fair point.

> Occasionally you find some code which defies categorisation. Procmail is my
> usual go-to when highlighting C on crack. Check out this beauty:
> https://github.com/Distrotech/procmail/blob/master/src/regexp.c

Ug. Well, it's neat and seems vaguely self-consistent at least.

> I see that you're firmly in Team Python :)

Not really! Python has been bouncing off my brain hard since v1.x was
current and while I can kinda read it, I can't write it usefully. Keep
meaning to try again.

But while there's a huge amount of noise pro and con syntactic
whitespace, the simple argument that it _forces_ disparate groups of
programmers to _all indent the same way_ is rarely mentioned.

Many love it, many hate it, a few are ambivalent, but few mention this
big win: each coder _can't_ just pick their own preferred style.
That's a big deal ISTM. I totally get the arguments about code
breaking if you render it in HTML and the difficulties of cut and
paste and so on, but it pours oil on the waters of indentation
preferences. That's important.

It seems that it leaves people one choice: spaces, tabs, how many of
them, and mixtures of both. :-D

But AIUI the interpreter sorts it out and it mostly just works.

FWIW, my impressions on this were partly informed by a conversation
between you and I and James, walking between several pubs around
London Bridge and Borough Market one weekend...

> There are many reasons I don't like Python, and significant whitespace is
> high on the list. It's fine for small, well-designed programs, but Python
> developers tend to be quite junior and after a while their code gains far
> too many levels of indentation ("helper functions, we've heard of them"),
> making it much harder than it should be when I'm dragged in to "just help
> add this one simple feature they're struggling with" which turns out to need
> a major refactoring and I have to be extremely careful to correctly indent
> and dedent the right lines the right number of levels to not totally wreck
> the code. Significant whitespace is just too brittle for real-world code,
> and the only good place for it is in trivial pseudocode in academic papers.

I don't know about that. I mean, I really don't, but there are some
big Python projects out there and it seems to work.

If it didn't, there wouldn't have been so much screaming over v2 -> v3.

> Python's significant indentation has a possible upside in that it doesn't
> waste vertical space on a line containing a closing brace, but that line
> should probably be left blank for readability anyway. After all, we organise
> prose into paragraphs rather than smush everything together.

True, yes, but again, it leaves too much room for individual interpretation.

If braces are so bloody significant then they need to be highlighted.
My eyesight isn't bad but in the old days of text-mode editing (i.e.
not in a GUI, no antialiasing or scalable proportional fonts), I saw
setups where the difference between a brace and an ordinary round
bracket was a single pixel displaced by 1 left or right.

For me, that is just too hard to see.

Less of an issue these days, but given that the same sort of people
who favour C also favour horrid 1970s editors and working in terminal
windows, still surprising to me.

> The other way is to mandate that all code be run through a source-tidying
> tool to ensure consistency. This can be enforced via the version control
> system, although peer pressure is often sufficient.

Well true. But that too has issues as I have discovered with XML:
reformat the source with another tool and you get huge diffs, and the
changes the human made are lost in the noise of the massive
every-bloody-line change that the formatting tool made.

If the indentation was live in the editor, as it was when I was a kid
playing with BASIC, I think that'd be much better, but I've not seen
that in any modern editor yet.

> The C languages are too fragmented for any particular formatting tool and
> style to be the de facto standard, but Rust has rustfmt, Perl has perltidy,
> and so on, so there's less to argue about. clang-format is quite nice if you
> need to use one of the languages it supports and get to choose the
> formatting tool.

I believe you, but see above.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ~ gMail/gTalk/FB: lproven at gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053