This phenomenon (or a closely related one?) is recognized and known as Kotov Sydnrome in the context of chess.
A summary, courtesy of chess dot com:
> The name of this "syndrome" comes from GM Alexander Kotov, author of the classic chess book Think Like a Grandmaster. In the book, Kotov described an incorrect yet very common calculation process that often leads players to select a suboptimal or bad move.
> According to Kotov, in positions where the lines are complex and there are numerous candidate moves and variations to calculate, it's easy to make a hasty move. A player in that situation might spend too much time going over two moves and all of their ramifications without finding a favorable ending position. In that process, the player is likely to go back and forth between the two different lines, always coming to the same unsatisfying conclusion—this wastes precious mental energy and time.
> After spending too much time evaluating the first two options, the player gives up the calculation due to time pressure or fatigue and plays a third move without calculating it. According to the author, that sort of move can cause tremendous blunders and cost the game.
Not exactly a true greybeard though, given that the author has "more than 10 years of experience", and judging by the picture on his GitHub page ;) [0]
Games couldn't rely on patches back in the day, because they used to be shipped in boxes, and providing patches was tricky. (The ease of providing updates may indeed incentivize releasing half-baked software nowadays).
I am less sure if those careless, youngest programmers endlessly scrolling Tik Tok videos are fervently dedicated to Martin Fowler's misled teachings.
And even less sure if the author summarizes them in a fair manner to begin with: "Many such organizations will build microservices even if their software domain complexity is not high and the software itself is not projected to scale that much. They will do it because their God told them to do it", he snarks.
If you go to Fowler's website [0], however (under "Are Microservices the Future?"), he's not dogmatically advocating for microservices: "Despite these positive experiences, however, we aren't arguing that we are certain that microservices are the future direction for software architectures [...] not enough time has passed for us to make a full judgement [...] There are certainly reasons why one might expect microservices to mature poorly [...] One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem."
Doesn't really fit the image of a God commanding you to build microservices regardless of the domain complexity and other factors. Perhaps he's changed his tune since, I don't know. A quote would help.
On the other hand, observations such as that "from the usability perspective, the software must be user-friendly" , or "the role of software has become increasingly important, to the point where our world now heavily relies on it.", etc. are undeniably correct.
Sure, I see your point. Obviously a wasteful format is also getting in the way of queryability. My point is that the main goal should be to improve for queryability, which inherently requires some optimizing for storage, but that's secondary. As opposed to optimizing exlusively for data size.
Because in the former case it may still be best to accept some compromise (in the form of redundancy/simplicity) to hit the sweet spot.
Especially in the context of many comments that seem to have taken an extremely "code golf"-like approach towards the problem.
What's good style in production code isn't necessarily good style in test code (and vice versa).
Good style in an SDK or a library is not necessarily the same as good style in a self-contained business app.
Just like suburbs and downtown can't be expected to look similar (whether in Montreal or elsewhere), style, too, is context-dependent, and there's more aspects to this context than just the language of choice.
PGN is a highly redundant format, but it has the inherent advantage of being human readable. The problem is interesting, but I think it falls on the side of "fun" more than "profit". Storage is cheap, and PGN files are still small. An average PGN is still below 1 kilobyte. So one movie in BlueRay quality = about 20 million games. That's a lot. The practical problem is not storage, it's computation. Basically, querying the game database quickly. Compression gets in the way of that.
For example, I've just played a game, now I want to go through the opening and fetch all games from the database that went through the same initial moves/positions (that's not the same thing, as a game may arrive at the same position through a different order of moves; AKA transposition). Let's say, all the way until move 15 or 20, because it will only be at that point that a decent game finally becomes unique by deviating from all the recorded games in the database (AKA a novelty was played).
Or I want to find all games where an endgame of a Queen and a pawn against a lonely Queen occurred. There is actually a query language for that, named (surprise, surprise) Chess Query Language: https://www.chessprogramming.org/Chess_Query_Language
I feel that whatever a superior alternative to PGN might be, its strength would likely be better queryability rather than higher storage efficiency as such.
> Use StockFish to predict the next move, and only store the diff between the actual move and the prediction.
This ties the algorithm down to one specific version of Stockfish, and configured identically (stuff like the hashtable size etc.), because all such factors will have an impact on Stockfish's evaluations. One factor changes, and you can't decompress the backup.
Once you have the technology to freeze evolution, you also have the technology to accelerate it and steer it, and given the level of incentive (to gain competitive advantage), I don't imagine it would be a balanced sword-and-shield race in the long run. The "conservatives" couldn't keep up with the "modernists", unless it's some sort of a totalitarian system.
There's been this great (relatively) short story, both humorous and profound, by Stanisław Lem; "The Twenty-first Voyage" in "The Star Diaries". It's based on that exact premise.
> Because they need to keep some gaps in the tax law to allow their friends to pay less taxes than normal people.
The self-employed in Poland provide almost 30% of total budget revenue from income tax [1]. (This statistic is somewhat dated, but I don't believe it's changed drastically since). That's a lot of "friends" and "wealthy expats".
It certainly helps the IT sector to stay globally competitive, also attracting foreign talent (hence plenty of programmers from eg. Ukraine, particularly these days).
Being self-employed has its own downsides - if anything goes south (as in, you did something terribly wrong, there's graphite on the ground, and you're held financially responsible for the outcome), you are liable down to your very last penny, in theory at least.
By comparison, if you're on a contract of employment, you're only liable up to the equivalent of your three salaries, even if your negligence has caused damages in the millions.
You are not protected by the labor law (by contrast, getting fired on an employment contract runs into plenty of legal protections should you choose to dispute it).
It makes sense to me that accepting greater responsibility - as a one-man company - gets compensated somehow, like in the form of lesser tax burdens.
Not all intellectual property is patented. Anyhow, you don't include git diffs. You cannot, even if you wanted to - the code is not your property. The whole point is that you're selling your intellectual property rights. It also means that the tax office pretty much has to rely on your word that the work is innovative in nature. Obviously they'd be in no position to tell the difference anyway.
> > I can't see why a company couldn't have one long-term customer.
> Let's hope you won't find out why that's a very bad idea.
The way you phrased it feels needlessly patronizing (perhaps unintentionally), but more importantly, it does not really address my comment.
I wasn't arguing if it is a good idea or not. I was responding to the argument that having multiple customers is necessary to be regarded as "truly" self-employed in the eyes of the taxman. My point is that it's not uncommon nor unusual for a small company to be invoicing only a single customer. Hence my examples. Whether it is safe business-wise is another story.
> If at the end of the year you've only sent invoices to a single customer then you are simply at risk. You need multiple customers to be stable and secure. Two is better than one and three is really the minimum.
Noone denies that having diversified sources of income is (other things being equal) the safer option. But the subject was legal recognition, not optimal business strategies.
I'm not sure if there had been any unprecented drop in the trust level between 2015 and 2023 (meaning under the Law and Justice government).
While it is true that it's relatively low in Poland in general... Eg. according to this survey [1], the percentage of respondents expressing trust in the government decreased from 38% in 2016 down to 32% in 2022 (while clearly exceeding 40% about half way through).
Which is pretty normal whenever the same party stays at power for a longer period; its popularity wears out over time.
For comparison, the same score was at 39% back in 2012, midway through the term of the government preceding Law and Justice. Hardly a striking contrast.
I'm even less sure about your claim when it comes to the context of welfare systems in particular.
Social transfers and safety net is one of the very few areas where the Law and Justice government achieved substantial results, even though it had to steer the country through the hardships of the pandemics.
For example, in terms of the percentage of children at risk of poverty and social exclusion Poland ranked 14th in the EU back in 2015 [2]. By 2022, it ranked 6th [3].
Also look at [4], [5], [6]...
I am putting aside the infamous judiciary reforms, abortion, and other hot button areas (which are far less of a priority for an average voter than echo chamber—commentators tend to assume). I'm focusing on the taxing & welfare, and sheer facts.
> To truly do that, you need to move your center of life abroad, which generally means being outside Poland for 183 days a year.
Yeah, theoretically. But at least within the Schengen area, that's pretty difficult to prove/disprove, especially if you've got no family. I'm working remotely, I'm renting a cheap room in Budějovice, here's the tenancy agreement. Come see if my toothbrush is wet :)
I'm not fighting, I was just curious what you're basing your claim on. I disregarded your unnecessarily incendiary phrasing ("software from Poland is such a tacky crap") completely.
A summary, courtesy of chess dot com:
> The name of this "syndrome" comes from GM Alexander Kotov, author of the classic chess book Think Like a Grandmaster. In the book, Kotov described an incorrect yet very common calculation process that often leads players to select a suboptimal or bad move.
> According to Kotov, in positions where the lines are complex and there are numerous candidate moves and variations to calculate, it's easy to make a hasty move. A player in that situation might spend too much time going over two moves and all of their ramifications without finding a favorable ending position. In that process, the player is likely to go back and forth between the two different lines, always coming to the same unsatisfying conclusion—this wastes precious mental energy and time.
> After spending too much time evaluating the first two options, the player gives up the calculation due to time pressure or fatigue and plays a third move without calculating it. According to the author, that sort of move can cause tremendous blunders and cost the game.