klingon78

I don’t think we’re speaking the same language. I’m talking about how much time it takes to change the code in every unit test, etc. because you upgraded something that requires changing the test framework, and this library and that one, so you end up not only having to fix all of your production code, but all of the tests with their mocks, stubs, injections, annotations, xml config, etc. If you have thousands of tests, this can keep people from upgrading.

In my experience, there is a class of small company that has roughly 3-7 employees, at least half of which are 45-65 years old, where the business is slow and quiet, with little sign of any growth, typically selling a niche product or technology for which there is not much competition. One or more may have big ideas but really they just are happy having a job and working with others.

There’s nothing wrong with this.

I meant upgrading application frameworks, OS, etc., so it’s not a red herring. Those can inflict a lot of changes if you have a lot of tests affected.

Many plan to be a CTO, VP, or making silly money somehow, but that doesn’t often happen. I know few old developers, but those I know aren’t making silly money- they’re either in slow very small businesses or working for some mid-sized to large company.

Something not mentioned but is a much bigger problem than performance for most is that if you write too many tests, you may be unable to easily upgrade/update to newer versions without a significant amount of work to update all of the tests.

You’re right to call out performance as a reason for testing. Unfortunately, though, it’s usually not that easy. A problem not found in testing may be the result of inexperience or lack of foresight in design, such as the assumption that another adapter service in front of that enterprise cloud service that only exists in production isn’t a bottleneck, or that your code that had 100% unit test coverage turned out to leave nasty half-updated data due to non-transactional services and was deadlock-prone with memory leaks.

Older devs even with many years experience have it harder. That’s my own experience.

Is this something that could be applied in general mathematics? If so, is it truly novel and worthy or a trivial derivation? I’m asking because I don’t know, not rhetorically.

I agree that someone shouldn’t be publicly made fun of in-general for sharing something novel and non-trivial that others didn’t already know, and if it highlights a problem in inadequate reviews, maybe it should’ve been presented to the journals that published it with that info.

I don’t mean to downplay this, but it’s similar to the migrant worker booms across the globe over past decades.

For example, people from Central America trek up at risk of their lives through dangerous drug lord territories to get to US states where they can work illegally for less than minimum wage, then send that money back to their families because they can make much more doing that than they could at home and may have no other choice.

The working and living conditions can be terrible, and answer is not to deport them or make their conditions worse; that hurts the host country as well as the workers and creates more division. Similar workers boosted the US culturally and economically because industry and governments embraced them for labor and taxes.

Could undecidability similar to that of Conway or another halting problem be used to better solve security of financial transactions?

If it’s ubersecure maybe it would outperform Moore’s Law, quantum computing, and the hyper-intelligent AIs.

You don’t have to have microservices in the end result, but you could develop and test them as microservices, then have them automatically rewritten into a monolith, perhaps with a subset of their functionality, if that would fit better.

Similarly, you could do TDD on a high percentage of the code by using injection, then automatically rewrite the code into static methods, as Atwood was saying they needed for performance, if that’s what would help.

Code generation, etc. got a bad name over the years as people tended to use it to balloon the eventual source, like that of many autogenerated config files today, but it can be used to do almost anything.