Ephera @ Ephera @lemmy.ml

Posts

28

Comments

2,588

Joined

5 yr. ago

Hmm, what do you dislike about the behaviour on mobile? Like, do you actually need to edit the URL of your search provider? Personally, haven't run into a situation where I needed that yet...

There's always been a tendency of folks reading programmer humor to be beginners rather than seasoned devs. I think, there's just more of those in general, as there's lots of fields where entry-level coding skills are good enough...

Yeah, I doubt WebAssembly when executed in a browser will become multi-threaded anytime soon, since JavaScript is single-threaded just as well. If you need multiple threads, you need to use web workers. Haven't done anything with those yet, but I'd assume them to be usable from WebAssembly as well, since the whole JavaScript API seems to be accessible.

Well, and in Rust, I'm pretty sure the runtime that's typically used for async stuff (tokio) will produce a compile error, if you try to enable the "multi-thread" feature flag on the WebAssembly target.
But yeah, might be more of a problem with other languages.

LibreOffice has a way to switch to a sidebar UI. I always preferred that, because of what you describe...

Well, part of the problem is that web apps themselves are kind of alien on the web. The web is generally document-based. Web apps take the document format and try to turn it into something it's not.
There's a way to not do the JavaScript, but it doesn't fix things being document-based and it can be argued that it makes other things worse in some respects.

I'm talking about WebAssembly. Basically, you can write your web app in HTML+CSS+Rust and then the Rust part is compiled to WebAssembly, which then takes the role that JavaScript would normally take. It does not have to be Rust, lots of languages can be compiled to WebAssembly, but Rust has the most mature ecosystem for that, as far as I'm aware.

In principle, it is also possible to use WebAssembly to render directly to a pixel buffer, but that's really rather heavyweight and not terribly responsive, so not generally done, unless you implement a game¹ or similar.
Alright, so back to the document mangling approach. There's various frameworks available for Rust. I've used Leptos so far. There's also Dioxus and Yew and probably others.

Advantages:

• Don't have to write JS.
• Can write Rust. Rust has some concepts that mesh really well with frontend dev, like the Result and Option types for error handling, which you can pass directly to your rendering stack and it can show either the data or the error (or nothing).
• Can use the same language in backend and frontend and therefore also get compile-time checks that the two work together.

Disadvantages:

• The ecosystem is young. You will find barely a fraction of the component libraries as you can find for JS.
• Rust also has concepts which don't mesh well with frontend dev, like the whole memory management concept. Those frameworks bypass that or make use of it in clever ways, but things can be a bit peculiar or overly complex at times.
• WebAssembly is sent to the browser in one big blob, because it's a compiled program. This means you get somewhat of a loading time when first loading the web app. There's ways to mitigate that with "hydration" strategies, but yeah, still a thing.
• While JS is often minimized/uglified and therefore not readable anyways, WebAssembly makes that even more of a reality, because it is essentially assembly code that's sent to the browser. It does still call the same APIs under the hood as JS does, so content blocking shouldn't be affected, but yeah, can't try to understand the code itself. This can also make debugging during development somewhat more painful.
• Well, and it's also yet another web standard that browsers have to support. It doesn't make browsers simpler in the sense that suckless would like.

I've listed a lot of disadvantages, so just to point out that, yes, to me, the advantages are absolutely worth it. But I can totally understand, if others see that differently.

¹) See, for example, Bevy and this UI example in particular.

Yeah, I'm honestly a bit confused. I have basically the same paper bin and it's not heavy at all. I'd expect a cat to be able to knock that over no problem. Like, maybe it doesn't try to while you're around, because it might fall over with the bin or hit itself with it, but I wouldn't expect a real troublemaker to worry about that either...

Ah yes, intentionally misunderstanding someone's comment. We've all seen them.

I mean, what the heck is this passive-aggressive comment? If you disagree with me, then come at me.

Yeah, fair enough. I use laptop keyboards so much that I need to get used to a full-sized keyboard, whenever I use one. 🙃

Unfortunately, laptop keyboards are a mess of different layouts, so it's not either like I can sit down at someone else's laptop and immediately know where everything is...

As a software engineer, I'd say statistics is more useful for journalism. If in doubt, you could be analysing papers about entirely different fields, like physics or biology or whatever. Those also deal with statistics.

But I also just feel like there's not terribly much journalism to be done surrounding computer science. There's the bog standard news cycle of tool XYZ had a new release, but beyond that, it's more a field where techies try out or build things and then they tell each other about it.
I guess, you could also consider some of the jobs adjacent to computer science / software engineering, like technical writer or requirements engineer or project/product owner. In some sense, the latter two involve interviewing customers and their domain experts to figure out what's actually needed.
Having said that, to my knowledge you typically get into these roles by being a software engineer and then just taking on those tasks regularly enough until someone notices...

One decent reason is that it brings the mouse closer, so you can move your hand over more quickly and are more likely to find the right keys when moving the other way.

It's a programming language, which is particularly relevant for Linux, because it doesn't require a runtime (separate program that runs the code). This allows it to be used in the kernel.

But it also means that it's very good for building libraries. With a small bit of extra work, virtually any other programming language can call libraries implemented in Rust (like you can with libraries implemented in C).
Add to that, that Rust allows for performance similar to C and makes lots of typical C bugs impossible, and suddenly you've got folks rewriting all kinds of C libraries and applications in Rust, which is something you might have also heard about.

Since no one else responded so far, the last thing I remember about it is that it got overrun by conspiracy nuts. Don't know, if that's still the case or if it was just a local thing, but yeah.

Yeah, as I understand, in the terms of language design theory, it is technically still "manual memory management". But since you don't end up writing malloc() and free(), many refer to it as "semi-automatic" instead, which certainly feels more accurate.

Same. What we refer to as "centipedes" also looks a lot more like millipedes with less legs. So, their body is longer and the legs shorter.

The thing is, everyone would agree that it's a strength, if the Debian-specific format was provided in addition to a format which runs on all Linux distros. When I'm not on Debian, I just don't get anything out of that...

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...

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ücks­verkehrs­genehmigungs­zuständigkeitsübertragungs­verordnung. 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