Real men know that infinite sets are just a tool for proving statements in Peano arithmetic, and complex numbers must be endowed with the standard metric structure, as God intended, since otherwise we cannot use them to approximate IEEE 754 floats.
Counting warnings is a poor practice, because you don't see where warnings exist or are added or removed while reading or writing code. Suppression annotations in code next to where the problem occurs are more explicit, and the progress is easy to measure with e.g. git log -S. The main difficulty is automating adding these annotations. For at least one static analysis systems, there is an off the shelf solution: https://github.com/palantir/suppressible-error-prone
Wealth tax is the best type of tax, because it incentivizes productive activities against speculation. It should be levied on a continuous basis rather than on transaction basis though, which is just basic numerical analysis.
Not my downvote, but the least devastating tax is only on commerce, and it has to be at insignificant levels to keep from resuting in undue damage.
Taxing wealth, property, wage income, or just plain existence has always sapped productivity like few other things.
It's foolish to try and tax "wealth" when you should instead be taxing the creation of wealth as it's in progress and nothing else. When actual ongoing business operations are going forward is the only time anybody can truly afford to pay any significant tax at all. Even if they are billionaires, and I say this as someone at the complete opposite end of the spectrum.
Ordinary wage income doesn't even make sense to tax whatsoever when you want max productivity, unless income is excessive enough to reach so far above average that greater capitalist profits can be earned on the surplus. Then maybe more than just those gains should be taxed.
I think that the problems with unchecked exceptions are due to the simultaneous presence of both checked and unchecked exceptions. The designers must have thought that checked exceptions would be the rule, but left an escape hatch.
If there were no checked exceptions to begin with, people might have thought about making the Java compiler (and later language server) infer all possible exception types in a method for us (as effect systems do). One could then have static analysis tools checking that only certain exception types escape a method, giving back checked exceptions without the type and syntax level bifurcation.
On the other hand, if all exceptions were checked, they would inevitably have had to implement generic checked exception types, ironically leading to the same outcome.
The plain Java equivalent of the proposed semantics would be a type system extension similar to JSpecify:
@Result(ok=Ok.class, error={Checked1.class, Error2.class}) Object function()
combined with enough restrictions on the usages of results of such methods (e.g., only allow consuming the results in an instanceof pattern matcher; not even switch would work due to impossibility of exhaustiveness checking).
The one feature that the proposed Kotlin error types share with Java checked exceptions is that they can be collected in unions. However, the union feature for checked exceptions is pretty much useless without the ability to define higher order functions that are generic over such unions, which is why checked exceptions fell out of favor with the spread of functional APIs in Java 8.
Math does that. Peer review cycles are measured in years there. This does not stop fashionable subfields from publishing sloppy papers, and occasionally even irrecoverably false ones.
I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.
It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.
There is no "Navier-Stokes theorem". There is a famous class of open problems whether Navier-Stokes equations are well-posed (have solutions that don't explode in finite time) for various initial data, but that type of question is completely irrelevant for any practical purposes.
I do share the feeling though. As a non-expert, I have no idea what the existing, allegedly practically relevant, formalizations of distributed algorithms actually guarantee.
reply