Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though. Dealing with external input requires type assertions (since Typescript doesn't know what the program is getting at compile-time) and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.
However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.
> Writing a Typescript program that takes external input but has no runtime error checking is already a mistake, though.
If it's a service, yes, and that's true no matter what technology the service is using. If it's a library, no, because...
> and if you write type assertions without ensuring that the assertions are accurate, then that's on you, not Typescript.
That's on whoever is using the library, not the library author. If the library author provides type definitions, and you as the consumer choose to ignore them, then it's on you.
Sure, but if the caller is Javascript then you're running Javascript, not Typescript*, so it makes sense that you're not going to get type safety.
I'm also not sure we're actually disagreeing on anything, so perhaps my reply was pointless. I agree that if you mix JS and TS in the way you describe, you'll have problems. My reply was just to say "yes, and that's not really Typescript's fault", but perhaps you weren't implying that to begin with.
* I'm aware that you can't run Typescript directly, but I hope my point here is clear... you're running a program that wasn't type-checked by TS.
I don't think we're disagreeing either. I didn't mean to suggest that it was Typescript's fault, just that the relationship between TS and JS in theory is something like "TS is a superset of JS" but once you get down to the practice of writing idiomatic reusable code it's more like TS and JS are fully different languages.
This might be a dumb question but are there any current or foreseeable practical applications of this kind of result (like in the realm of distributed computing) or is this just pure mathematics for its own sake?
Not a dumb question. The links to mesh networking etc seem interesting. It sounds like the insights from descriptive set theory could yield new hardness/impossibility results in computational complexity, distributed algorithms etc.
are there any current or foreseeable practical applications of those results?
the math of infinity isn't very relevant to the finite programs that humans use. Even today's astronomically large computing systems have size approximately equal to 3 compared to infinity.
> The solution was reached by using codebreaking software the team had developed along with extensive manual work, in part required because Perwich had mistakenly omitted a couple of letters in his ciphertext.
That explains how the team of 3 codebreakers got it, but what about the other codebreaker, Matthew Brown, who figured it out by himself? The article doesn't say anything about his approach. Seems impressive if he can match the effort of three cryptographers using their own custom software. I want to read more about him!
Recently, I ripped usage examples out of a rust project's README.md, and put them in doc comments. Almost all of them were broken due to small changes over time, and I never remembered to update the readme. `cargo test` runs doc comments like mini integration tests, so now the examples never rot. I wish more languages and tools had this feature.
It means having to go to the linked docs (which are automatically pushed to the repo's github pages) to see examples, but I think this is a reasonable tradeoff.
If you're looking for something real-time, I'd recommend checking out NASA's "Eyes on the Solar System" visualizer (not as comprehensive but still pretty cool):
I'm having trouble understanding the second diagram in the article. I can make sense of a directed graph, but this one has thin horizontal lines with arrows leaving them in both directions. These lines look like dividers, not nodes, so I'm not sure how to interpret it.
I think the intention is to show the divide between Amazon's and Cloudflare's responsibility, over the piece of fibre linking their network devices together. It would have been clearer to continue the lines and just put a dotted divider between them I feel.
It looks like she's a science communicator rather than a scientist herself. That's interesting... I'm not used to seeing academic papers that include an author devoted entirely to the writing aspect. (Then again, maybe I just haven't noticed?)
> set theory is the foundation of all of mathematics
I disagree. I would say set theory is a foundation, not the foundation.
Which system is the "correct" foundation of mathematics? Does it even make sense to talk about correctness in this context? These are open questions and they're very interesting! Don't prematurely close yourself off to them by assuming that set theory's role is some kind of scientific fact.
Kurt Godel kind of threw this line of reasoning into the bin unfortunately. No system can be both complete and consistent, therefore the authors statement that the set theory he is studying is the basis of all mathematics as well as consistent is probably false.
The article is right to say that set theory can serve as a foundation for almost all other mathematics, and you're also right to say that no reasonably-complex consistent system of axioms can be complete. The resolution to this is that if you ground something (let's say topology) in e.g. ZFC (the most commonly used system of axioms for set theory) then incompleteness in ZFC maps to incompleteness in topology. Here's an example https://en.wikipedia.org/wiki/Moore_space_(topology)#Normal_... .
There are other foundations, some of which are based on things other than set theory (category theory, type theory), but they're usually equivalent to ZFC ± a few axioms, because you can embed those other foundations in some kind of set theory, and embed set theory in the other foundations.
However, if your point is that Typescript can lull people into a false sense of safety, then sure, I take your point. You have to understand where type assertions are coming into play, and if that's obscured then the type safety can be illusory. The benefits of Typescript require you to make sure that the runtime inputs to your program are sufficiently validated.