Funnily enough, that's what mathematicians have been doing all along.
I wonder how many of them truly think that they construct something new that just happens to then have practical applications and fit nicely with everything else.
Sure, it is philosophical.
You could even go further and say that math exists in the same sense it exists in the Library of Babel, since it's also text.
I would say that this comparison oversimplifies things. Non-math stories in Library of Babel are less practically useful and are less possible to get checked than the math texts. Wrong math can exist, but we often have ways to figure out it's wrong.
For practical purposes I would assume (maybe others can correct me) that math is treated as something you discover when you work on it as mathematician. It's a more intuitive model.
It exists in the same sense that every story exists
I’m sure Russell’s Paradox would have something to say about that.
One might also consider alternative axiomatizations of mathematics with statements that cannot be expressed in ZF set theory, and vice versa. To say that all of these things exist is to really stretch the definition of existence far beyond the ordinary sense of the word.
I am inclined to agree with your view on this, and have found myself in surprisingly knockdown drag-out arguments with people who think math is the "language of God" and "it already exists and we're just discovering it" (as opposed to "we're making up symbolic representations that may or may not map well to observable phenomena in the universe; the set of patterns and rules we can conceive of is vastly larger than the set of interesting ones").
Is too. They could have thought through the law they were writing and predicted malicious compliance. Or written a stronger law. Or revised the law when they spotted malicious compliance.
I don’t understand why that’s considered legal under GDPR. How can consent be express and informed when it would take 30 minutes just to identify each entity your data is being shared with?
In fact the law even specifies “no pre-ticked boxes” but every banner always has “accept all”. And it’s 50/50 to see “reject all” even though it is a requirement that denying must be as easy as accepting.
They should pay a bounty for reporting non-compliance.
> In fact the law even specifies “no pre-ticked boxes” but every banner always has “accept all”.
That's not entirely true. Websites that don't actively try to fuck over their users (because their purpose is not shoving third party ads at you, it's providing information about/a platform for their company's product) often provide a modal with two buttons:
'Accept' 'Decline'.
This, IMO, meets both the letter and the spirit of the law. The funny thing is, for any website actually doing that, if you click 'Accept', your data will likely only be used to improve it.
I've seen the questionnaires from Moscow streets in the last few years on the topics of war.
I've seen what different people write in social networks about it.
Maybe you can trick our naive western friends, but not me.
Being an indifferent somnambula is not the same as being against war.
I will treat this comment charitably and just say that it's yet another case of "definition of X sounds good, so X can't be bad".
I believe in reality it's less about "please don't kill us" and more about getting officials to set up the "pleas profit us" situation.
Yes, money don't change hands in an office, so it's TECHNICALLY not a bribery.
Well, unlike regulators, companies die without profit. So they do indeed need profit. Smaller companies might want a system currently tilted against them to be changed. Larger companies might spend a fortune on regulation-following that has harmful outcomes, e.g. raising prices, for no benefit. Both of those motivations sound reasonable, and both getting their way may result in more profit for them. There's nothing wrong with profit.
The only thing that can possibly be bad is the regulation-writer, or the regulation enforcer, behaving incompetently and/or corruptly, who decides or enforces bad rules.
This applies to a lot of scientific and practical (like construction) topics in general. Everyone relies on someone else (or something else) knowing what to do.
"every time I have to type "as" my inner Haskell programmer screams." - most of the times you don't have to. You choose to.
"If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail." - I don't think it's fair to expect that since most of the statically typed languages will not guarantee things in runtime unless you specifically run a validation code in runtime.
There's also type guards and good old self-written validation functions you can use.
"I don't think it's fair to expect that since most of the statically typed languages will not guarantee things in runtime unless you specifically run a validation code in runtime."
If I have a value of type X in a static language, then I know that it absolutely conforms to the layout of type X. It isn't even that we have to provide a "validation function", it is that it is quite literally physically impossible for my value to not conform to the definition of type X, in the languages like C or Go or Rust where the type layout is actually a specification of a layout of data in memory. If I have JSON '{"a": 1}', there is no way whatsoever to stick that in a "struct { A string }", because it physically doesn't fit. By "physically", I mean, in RAM, in the physical cells and voltages. There's no way to validate that a "struct { A int }" 'really contains an int' because there is no way for it to be anything else.
Typescript specifically has these issues because all of its objects boil down to a Javascript object with certain keys, and all of the values are ultimately of type "any" no matter what Typescript tries to lay on top of it. If I have this sort of data come in to a static language, I have to have a step where it very deliberately converts it down to the static representation. There isn't an equivalent of "as". Modulo unsafe, but we don't count unsafe in these sorts of discussions.
I am absolutely guaranteed in a static language that if my struct says field "A" is an int, it absolutely, positively is, always has been, and always will be.
The main problem I encounter with "as" is when I have external data coming in. For that I have zod and validation functions. What prompted my post is my experience yesterday where I corrected an AI using "as" (which it used because a lot of its training data does this) and had it call an actual validation function that I happened to already have before it cast it into the type. But the reason my Haskell programmer screams inside is that a validation function can still be wrong, because the compiler isn't helping me. In a static language, I can guarantee that if I have "I dunno, some JSON value" on one side and a struct comes out the other end with some value derived from it, I have absolutely had some bit of code check that and pack it into the static value in a way that the compiler has helped check. I can further reliably compose these promises quite reliably through further type specification in my static type.
A validation function can still have bugs in it that a static language compiler would have strictly, compile-time validated. It's better, but it's still the manifestation of the quite accurate criticism that dynamic languages end up trading away all their convenience with not specifying types with having to have vast swathes of validation, and testing of that validation, in the testing backend. In Typescript, I can mostly sorta kinda compose them together, but it takes a lot more features and grease and effort. I appreciate Typescript in its capacity as taming Javascript and prefer it substantially over Javascript alone, it's probably the best thing of its type that we could hope for, but if I consider it as a language that stands alone, I really really dislike it.
Ok, I checked what Go does.
It indeed can generate runtime validators from types. Neat, TIL.
I'd argue it's not by default a capability of statically typed languages, rather something that a language creator can choose to add via reflections or some other mechanisms. So in my mind it's not really static vs dynamic systems.
In Typescript you would need to use additional libraries like this: https://typia.io/
Clearly, it makes sense to have perfect pitch only in connection with a particular instrument for practical purposes.
Besides being a neat party trick, it gives more possibilities and makes things easier if a person wants to work with music professionally, especially with academical (aka "classical") music.
Is there anything about notes and instruments tuning that is not arbitrary? But hear me out: there's few hundred years tradition behind it, at least in the west, so why not follow it for a kid?
"I assume that if the learner drifts later in life by under a semitone, then things will seem like they're between keys." - problem that never occurred to anyone with a perfect or just good pitch.
> there's few hundred years tradition behind it, at least in the west
Not even close to being true!
- There's not been any real convention for most of the history of western music (and no tuning fork anyway) and pitch varied hugely between regions, people and time. Different musician groups in the same church would likely be on different pitches. 415Hz is often used for baroque music but that's just a modern convention, there was no such standard in baroque times.
- 432Hz was somewhat conventional at the end of the 1800s, start of 1900s
- 440Hz is the "official" standard since then
- Many orchestras are tuning to 442, 443, or even 445Hz nowadays
So there's not been any such thing as hundreds of years of tradition, and even now that we do have standards (and ways to measure frequency precisely), pitch inflation continues to be a thing.
>415Hz is often used for baroque music but that's just a modern convention, there was no such standard in baroque times
415Hz is one modern semitone below the standard 440Hz. Many (but not all) baroque instruments were tuned slightly lower than modern ones, and 415Hz is the most convenient slightly lower tuning that retains compatibility with modern instruments by transposing down a semitone.
Not opposed to defence in principle. But Switzerland's army has proven, repeatedly these last few years, that they are incompetent. From understanding a multi-billions contract before signing it to selecting relevant technology (drones that fundamentally cannot fly in a civilian airspace, etc).
Not only incompetent: the way the F35 was handled really looks like corruption from the outside. And for some reason the head of the defence ministry AND the head of the army left not so long after that...
reply