It's pretty clear theyre going to drop below their 2011 baseline soon. In other words, 5% of GDP into pronatal policies and transfers will have at best delayed the inevitable drop by a couple years.
Also, judgement alone might not be enough. Judgement can take you to "something is off", but not necessarily further. I mix music as a hobby and it takes a good amount of practice to step up from recognizing the presence of a problem to actually know where and how to fix it. If you don't know where you should look, you just aimlessly try various things, and it is not unusual to make the problem worse.
Eventually you learn to properly recognize the problems, not just their presence, but their actual nature and implications. But this takes practice.
> The set of all possible mapping from all possible finite strings to booleans is definitely not countable.
Just to add another perspective to this, this is one of the places where classical and constructive mathematics diverge. Do those functions that are not expressible by algorithms (algorithms are countable) even exist? Of course you can define them into existence, but what does that mean?
Another food for thought is to consider if the limits imposed on computation by the Turing machine is a law of physics? Is this an actual physical limit? If so, what does that mean about the functions not expressible by algorithms? What is so exciting about programs/algorithms that they are both a well-defined mathematical object suitable for formal analysis, but they are actually machines as well, fully realizable physically and their properties physically falsifiable.
Before anyone starting to nit-pick, I just put this comment here as a conversation starter, not a precise thought-train: this is a deep rabbit whole that I think is worth to explore for everyone interested in the computational world. I am pretty sure other commenters can add more accurate details!
These are definitely thought-provoking questions and there are branches of mathematical philosophy such as constructivism and mathematical intuitionism that explore these.
Even if computation is not directly part of the laws of physics, knowing that humans and our computers are limited to things that are finite and computable might place limits on how we can appreciate how the universe works.
This is kind of a digression but if you (or others) are interested in some examples of things that are right on the edge of these questions you should check out the [busy beaver function](https://www.quantamagazine.org/amateur-mathematicians-find-f...). This tell you the maximum number of steps an n-state Turing machine can take before halting.
It is also interesting to consider, that if all transcendental numbers exist physically, then it basically means that there is an experiment that yields the Nth digit of such a number (for any N assuming unlimited physical resources to realize the experiment). If such experiment does NOT exist though, then there cannot be any relevance physically of that Nth digit (otherwise the "relevance" would materialize as an observable physical effect - an experiment!). This is something Turing machines cannot do for uncomputable numbers, like Chaitin's Omega, etc. We can yield the Nth digit of _many_ transcendental numbers (PI, e, trig functions, etc), but not all of them. It is so interesting that physics, machines and the existence of all the real numbers are so intertwined!
Of course one can also ponder, even if a mathematical object is "un-physical", can it be still useful? Like negative frequencies in fourier analysis, non-real solutions to differential equations, etc. Under what conditions can "un-physical" numbers be still useful? How does this relate to physical observation?
And just for the fun of it: when you execute unit tests, you are actually performing physical experiments, trying to falsify your "theory" (program) :D
One way to think about it is to ask yourself, is your personal project actually _playtime_? Playing is not goal oriented and therefore very relaxing. There is nothing wrong with that! I am happy to "play" programming and I learned a lot of techniques that I used years later - and then actually finishing it. Do not deny yourself playtime!
Agree completely. Reframe recreational programming as your favorite video game, and you’ll feel much more satisfied after a session that produces nothing, because that was never the point.
> But honestly, why ruin your fun projects by turning them into work.
Agreed! For fun, it is completely fine to not finish things if you enjoy the process more than the actual result. You achieved your goal of having fun and likely still learned a lot from it. Of course if it bothers you then sure, improve on your ability to close things, but first evaluate if this truly an issue coming internally from yourself, or some imagined external pressure that your work is worthless if you don't finish it (in the hobby context). Is it important to show it to others for example, or is this a solitary activity purely for yourself? In some hobbies I strive to finish, because I want to show it to others, in others, I don't care at all.
The email verification email itself does not show up properly in Fastmail for some reason. I had to switch to the text only view to get the actual link...
The problem with generics type erasure is less of an issue though in practice because the ecosystem is generally compiled from typed code and hence the compile-time guarantees reduce the dangers of erasure. This is unfortunately not true in TypeScript where you encounter plain JS all the time (sometimes TypeScript wrappers of dubious quality) causing more havoc. So while _theoretically_ type erasure could be considered having similar problems, in _practice_ it is much more manageable in Java. I guess if the whole JS ecosystem would be TypeScript only it would be less of an issue there as well, but right now it can be messy.
One more addition, there is a subtle but very important difference between how TypeScript's "erasure" works compared to Java's.
In the case of Java, an explicit cast is emitted in the bytecode, which upon execution checks the compatibility of the actual runtime type with the target type during runtime. Yes, this makes it a runtime error compared to a static bytecode verifier/compiler error, but the behavior is well defined and the error does not propagate further from the original mistake.
In comparison, Typescript does not emit "verification code" at the casting site ensuring for example that all asserted fields exist on the runtime object at that point. The result of this is that the type mismatch will be only evident at the point where for example a missing field is accessed - which can be very far from the original mistake.
If you wish, you can consider type issues caused by Java's erasure as runtime, but _defined behavior_, while in TypeScript it is kind-of undefined behavior that can lead to various error symptoms not known in advance.
(edit: added translation of unit)