I don't know if that's what's happening, but it might work towards TFA's point.

I'd argue that it is ideal, in the sense that it's the sweet spot for a general config file format to limit itself to simple, widely reusable building blocks. Supporting more advanced types can get in the way of this.

Programs need their own validation and/or parsing anyway, since correctness depends on program-specific semantics and usually only a subset of the values of a more simply expressed type is valid. That same logic applies across inputs: config may come from files, CLI args, legacy formats, or databases, often in different shapes. A single normalization and validation path simplifies this.

General formats must also work across many languages with different type systems. More complex types introduce more possible representations and therefore trade-offs. Even if a file parser implements them correctly (and consistently with other such parsers), it must choose an internal form that may not match what a program needs, forcing extra, less standard transformation and adding complexity on both sides for little gain.

Because acceptable values are defined by the program, not the file, a general format cannot fully specify them and shouldn’t try. Its role is to be a medium and provide simple, human-usable (for textual formats), widely supported types, avoid forcing unnecessary choices, and get out of the way.

All in all, I think it can be more appropriate for a program to pick a parsing library for a more complex type, than to add one consistently to all parsers of a given file format.

And the point remains that this operation has been started in a way that leaves the US in a weaker strategic position, not just in the Gulf, but also, crucially, in the far east. It has now become harder to contain China, both in the medium term by the reduction of US military capabilities both globally and in-theater by pulling out strategic defensive assets from South Korea and Japan; but also long-term, by putting themselves into a situation where they have to do that, retroactively, after painting themselves into a corner elsewhere, therefore undermining their posture as a credible, rational actor that can be relied on to oppose China's ambition in the region.

A DVD (single layer) holds about 4.7GB of data.

Btw, border collies are awesome dogs, and sheep are also awesome. I find no automatic disrespect in using them as stand-ins for our human foibles; intent matters.

GP, please don't be discouraged.

In fact, this is a huge chunk of the value a developer brings to the table.

I'm also not going to guess what point you're trying to make. I'd ask you to explain how exactly you think Overton windows relate to our argument about taboos, because, despite a superficial similarity, taboos and Overton windows deal with different things and are very much not the same; but I'm not interested in this style of discussion, sorry. Have a nice day!

This appears to be an entirely impractical definition, to the point that it would not allow a taboo to ever exist in a group of people capable of any sort of rational discussion. Any two moderately curious and independently-minded people could simply destroy any taboo by talking about it. They could even do it on purpose, using this fatal weakness.

Taboos, as in: the actual attitudes and behaviors of people, do not simply disappear the moment they are named or even questioned. I think we have to allow for taboos to be more nuanced, or we will struggle to describe the actual, interesting phenomenon, let alone do anything useful with it.

> once a culture has no taboos it has no real vitality or potential for growth left

That's an extraordinary claim on multiple levels, even when allowing for different ideas of what taboos are and how they work. I already mentioned some questions this raises, which makes it surprising to find the naked claim simply restated, in an even stronger form.

It's the kind of sentence that can sound really deep and powerful in passing, but when you look at it, is really only a huge, gaping question mark in a fancy dress.

That sounds suspiciously like something a taboo would say that has something to fear from being looked at. ;)

I think this chain of reasoning is made of links that do not self-evidently follow. From my lay perspective, taboos seem more complex, resilient and variable to require a perfectly dogmatic approach to hold up. If they were this easy to bring down, they'd all be gone.

I'm also not sure what a "culture without taboos" is, or one has ever existed. Also, what is meant by "peak"? Is there an optimal amount or set of taboos? How do cultures with taboo-ical differences (and their peaks) compare to each other across space and time?

I think it is good and healthy to approach taboos with curiosity, whether it is to interrogate them or to appreciate them more.

I try to remember that I ain't got no problem with other "illogical" uses of negation and could this one in a similar light, but it's more easily said than done.

The gist of what GP meant is that Python does not exactly follow SemVer in their numbering scheme, and they treat the middle number more like what would warrant a major (left-most) number increase in SemVer. For example, things will get deprecated and dropped from the standard library, which is a backwards-incompatible change. Middle number changes is also when new features are released, and they get their own "what's new" pages. So on the whole, these middle-number changes feel like "major" releases.

That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.

> A is the major version number – it is only incremented for really major changes in the language.

> B is the minor version number – it is incremented for less earth-shattering changes.

> C is the micro version number – it is incremented for each bugfix release.

The docs do not seem to mention you, though. :P

[0]: https://docs.python.org/3/faq/general.html#how-does-the-pyth...

If your thing can be reached under "pypi.org", you can either accept that people will come up with their own ideas of how to capitalize or pronounce the name, or you can fight against windmills and tell people what ought to exist or not.

You could check on the phone, but I could certainly see the appeal of a fixed display in a convenient location.

Code should live in main/master and be in a production environment as soon as possible, but it does not have to run for all, most or even any customers/clients from the start. You can gate it behind feature switches, preprocessor directives, global constants, whatever. As long as it has an active purpose and is being developed further, it is not dead. Ideally, it will have tests.

The result of merging back to main often is that other changes will be made in awareness of your new code, and all merging will happen organically and in small increments. You also get to develop complex features bit by bit, in a way that can be verified in a real environment in a controlled way. And everything can be deployed anytime, which should happen often.

Being able to verify incrementally and get quick feedback lowers the risk of otherwise releasing a hitherto completely untested large feature into the wild in one go.

This does not absolve you from making sure that your changes actually work as intended. That will be easier if you portion the work into smaller chunks that are easier to understand than a whole, complex, all-or-nothing feature.

Of course you will still have to make sure that your small chunks fit together and make up a good "whole". However, the idea is that you're doing this exact work anyway when developing a larger feature on the side, but you might as well cut it up to deliver in much smaller increments.

This approach has its own costs and drawbacks, but in my experience it often produces a substantial net-reduction in friction and accumulated complexity and risk, and it keeps things moving, which is a benefit on its own. This is from my perspective in backend development, and it will not apply universally, but widely. Essentially, whenever you can get away with it, you should strive to deliver like this.