What is the longest word in your language, and what does it mean in English?
Ephera @ Ephera @lemmy.ml Posts 28Comments 2,593Joined 5 yr. ago
Right, so you might want ask about this on !askscience@lemmy.world or such, as science-y folks tend to not be comfortable with what I'm about to say, but to the best of my knowledge, that's all just complete horseshit. Like, no, your understanding of the photograph is not somehow incorrect. It's just two halves of a photograph and because you know the first half, you know what's on the second half. The second half does not get changed by you looking at the first half. Nor does the entangled quantum get changed by you looking at the first quantum.
I think, a big part of this mass confusion is that at the size that quanta have, looking at them does actually change/move the quantum that you look at (not a potentially entangled one). This is not for crazy reasons, but because looking at them requires light, which is the equivalent of blasting them with photons, and photons are themselves quanta.
It's like if you had a dark room with a ball in it and you can only throw other balls into there to try to figure out where the first ball is. You need to hit the first ball, in order to have a chance of working out where it might be based on the angle that your thrown ball returns at. If you do hit the first ball, it will move. So, you only really know where it was at the time of impact. Quanta are not balls, but they do still interfere with each other when they get close to each other.
Entanglement in this analogy is that you've spun up two balls next to each other like cogwheels, so you know them to have the opposite (and equally strong) spin. Then you've released those into the dark room and start throwing other balls at them to try to work out their spin. If you hit one of the spinning balls, your thrown ball will come back out with a spin opposite to that and the spin of the ball that was hit will have reduced. In this moment, you know that the other spinning ball also has an opposite spin, because you originally spun the two balls like cogwheels. The other ball does not get changed by you measuring the first, but there's no way for you to know, because you have to measure it to find out, which means also throwing a ball at it and therefore changing it, too.
As far as I can tell, this is the other big part of where the confusion comes from. Because measuring necessarily also involves changing the thing and because it's actually impossible to disprove that the entangled quantum didn't get changed by us measuring the first, you get folks that follow a school of thought of things being non-deterministic. Of things only being set in stone once you measure them. There's lots of vested interest in things being non-deterministic for religious or moral reasons and there is no way to disprove it at the quantum level. These folks then propagate concepts like superposition and that when you open the box, you're the one that forces the cat to be killed. (Schrödinger was not one of them, by the way. The cat analogy was a critique of superposition as an idea.)
To my knowledge, there's no evidence for non-determinism (folks will sometimes argue with quantum fluctuation showing it, but it doesn't happen in complete isolation, so that disqualifies it in my opinion) and given that the rest of our reality seems to be perfectly deterministic, I think we should assume the quantum stuff to be like that, too, unless proven otherwise, but unfortunately not everyone goes along with that.
Yeah, Wikipedia tells me the longest word that was actually in use is Grundstücksverkehrsgenehmigungszuständigkeitsübertragungsverordnung. It was a decree from 2003 until 2007.
Basically:
- "Grundstück" is a plot of land.
- "Verkehr" is
traffic"trade" in this context. - "Genehmigung" is approval.
- "Zuständigkeit" is responsibility.
- "Übertragung" is transfer.
- "Verordnung" is decree.
So, it decreed that the responsibility of approving traffic on trade of private plots of land should be transferred (to a different government body).
Really not sure an estimate for algorithmic complexity is the right way to specify this. 😅
But if your supposed input unit is days, then I guess, yeah, that kind of works out.
I've heard this explanation of it once from a physicist: Imagine you have a photograph. You rip that photograph in half. Now you put both halves into envelopes and mix them up. At this point, you don't know which half is in which envelope. Now you send one of the envelopes to Australia. You open your half. Because you see that you have the left half of the photograph, you gain instant knowledge that the right half is in Australia.
With quanta, you can for example have a subatomic particle which decays into two quanta and then you know those quanta to have certain similar properties. As Wikipedia puts it:
For instance, a spin-zero particle could decay into a pair of spin-1/2 particles. If there is no orbital angular momentum, the total spin angular momentum after this decay must be zero (by the conservation of angular momentum). Whenever the first particle is measured to be spin up on some axis, the other, when measured on the same axis, is always found to be spin down.
https://en.wikipedia.org/wiki/Quantum_entanglement#Meaning_of_entanglement
Yeah, if middle management micromanages you, that's likely because their boss makes them answer some uncomfortable questions, if anything goes wrong.
Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you're only doing things that you've done in a similar form before.
If the feature takes two weeks to implement, there's so many steps involved in accomplishing that, that there's a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.
But yeah, I also double any estimate that I'm feeling, because reality shows that that ends up being more accurate, since I likely won't have all complexity in mind, so in some sense my baseline assumed error is already 100%.
Well, I think your idea would be simpler, if we weren't talking about Java.
Pretty much everything is an object in Java. It's only logical that a type would also be an object and have associated fields.
Similarly, what you're thinking of as "reference types directly" doesn't make sense in Java, because it lacks many of the systems to make that actually usable like a type. What you get from .class
is a Class
object, which you can't stick into a generic type parameter, for example.
It basically uses reflection to give you e.g. the name of that type and you can also instantiate an object of that type, if no parameters need to be passed to the constructor function.
And then, yeah, I think for explaining that you merely get an object which roughly describes the type, the separate .class
field is a good idea.
I think, the seagull that sits on the floating manatee is called Evelyn. But yeah, a bit confusing...
Yeah, don't use YAML for storing serialized data. It's intended to be hand-written.
I figured, I'd ruffle some feathers by saying that. 😅
But yeah, I stand by my point. Just because your target users are capable of dealing with complexity, doesn't mean you should be making use of that rather than simplifying usability, since your users have plenty other things they could be learning instead.
I will caveat that I can see it becoming worth it to learn an intricate logic for a power user, when things fall into place and make sense at a higher level as you learn more about it.
But in my experience, that's just not the case with package managers. You need a few specific commands to be obvious and then the special cases can be obscure flags.
Arch's package manager is pretty terrible.
Here's two commands. See if you can guess what they might do:
sh
pacman -S package_name pacman -Syu
I believe, there's some sort of logic to the letters, but man, most users seriously do not care. They just want to install, update and remove packages 99% of the time, so they shouldn't need to learn that intricate logic for three commands.
I guess, you could use pkcon
to do that instead, but that doesn't really help new users...
Well, it also avoids running instantiation code, which could be doing all kinds of things. In theory, it could have a side-effect which modifies some of your application state or issues a log statement or whatever.
Even if it doesn't do anything wild right now, someone could change that in the future, so avoiding running such code when it's not needed is generally a good idea.
I don't believe there is much deeper of an explanation than "because the Java designers didn't implement support for that".
That feature is called "types as a first-class value" and you need to implement some special casing or an entire system in the language to make it work. Telling devs there's a special static variable .class
is conceptually simpler to implement and understand.
Well, the thing is, if you're developing a library, you usually do so, because you want it to be useful to people in the ecosystem.
By putting it under the GPL, you limit that usefulness to only those projects which are willing to also put themselves under the GPL. From an idealist point of view, I certainly also would like to say that people not willing to put their software under GPL don't need to be my users. But from a library author point of view, I might as well not write a library then, since no one's going to use it then.
Many open-source projects are under a permissive license themselves. I might disagree with their choice, but I don't really want to exclude those from using my library. They're still doing good things. I would love to exclude specifically any proprietary software from using my library, but that's not really something you can require in your license without excluding all those permissive open-source projects.
So, to answer your question, I actually don't think people are being tricked into it. I thought about choosing GPL for my libraries for a while (all my applications are under GPL) and decided against it. Which is a personal choice that others can disagree with, but all I'm saying is, I know what I'm doing, I wasn't tricked to use a permissive license.
Yeah, I just put my whole collection on shuffle and have come to appreciate the simplicity of that.
I use this web music player at home, which only supports shuffle and because it's a web thing, I can't either use keyboard shortcuts to skip songs (without switching to that window).
And I actually like that I can't distract myself with selecting just the right music. Because if I don't distract myself and just get into coding or whatever, I'll quickly stop noticing what precise music is playing.
Larger open-source projects tend to have forums. Here's a few off the top of my head:
If a GUI can be built which accomplished something in 1-2 clicks, then there's very likely a CLI which can do the same with 1-2 commands, as CLIs are easier to implement than GUIs...
Oh yeah, I wasn't trying to say that Luanti had an incredibly original thought with volumetric lighting. There's been (pre-resource-pack) volumetric lighting mods for Minecraft probably already a decade ago. I was rather just wondering, when the proof of concept has existed for a whole decade, why do they decide to include it now. It probably would have worked well even on weaker phones three years ago already...
Huh, half a year after Luanti introduced volumetric lighting. I find it hard to believe that Microsoft execs watch out for what Luanti does, but maybe a whole bunch of Android re-packagings of Luanti suddenly looked a whole lot better than Minecraft and that got through to those execs...? It's a bit of a strange coincidence, at least.
Damn, seems you're right. For folks reading along: That's not how that word usually works in German, but I guess, it is how it works in German legalese...