wkk

Python with PyPI, C# with Nuget, Docker with Dockerhub, Java with Maven Central, hell even just regular Linux packages from dodgy repositories…

Supply chain attacks concern almost everything everyone everywhere.

Because believe it or not Twitter is still popular despite everything

You need to know where to look for said evidence, this is one new lead. Measure planet wobble for a few years and see if there’s anything. Other experiments can and will be carried in parallel in the meantime.

Godot definitely has sponsors which while not directly being “customers” are still very important when it comes to financing the development of the engine

Having said that I want to believe current sponsors won’t have issues with the Godot Foundation here

[…] it was decided that the language would be called “ECMAScript” instead. (Microsoft happily offered up “JScript”, but no-one else wanted that.) Brendan Eich, the creator of JavaScript and a co-signatory of this letter, wrote in 2006 that “ECMAScript was always an unwanted trade name that sounds like a skin disease.”

I tend to agree with these sentiments

Just fork it 🤓

It definitely feels like a knee jerk reaction, but there would be some merit to it: The Rust language feels apt to implement a kernel with. If I remember correctly that’s what Redox is trying to accomplish? https://redox-os.org/

Why would using it on PC degrade image quality, if anything a desktop with a good GPU would potentially beat a PS5 in terms of graphics?

An adapter will be required to plug the PSVR2 though, that information is already available. But once plugged it should work with SteamVR.

close but no (last panel doesn’t match?)

Antagonizing the borrow checker is wrong. If it screams it does so to prevent you from writing a mistake. Eventually once you have enough experience you should write code in such a way that doesn’t trip the borrow checker because you know how to properly handle your references.

Is it difficult to learn at first? Yes, but the benefits of learning this outweighs the downsides such as writing code that may use references when it shouldn’t.

I’m not a Rust aficionado, but the few Rust I’ve written opened my eyes on issues that I have been dealing with in other languages but for which I was blind.

Lastly I tried following a Godot project tutorial that was using GDScript except I challenged myself to follow it but rewrite the examples given using Rust’s bindings for Godot. It was definitely more cumbersome to work with, but I might also have been doing something wrong (such as blindly transcribing GDscript instead of writing more idiomatic Rust).

All of that to say 1) borrow checker is your friend and 2) scripting languages will always be more convenient at the cost of being way more dirty (way less safeties)

In the end you need to pick the right tool for the job. Multiple tools may be used within the same project.

Same energy:

The message transferred between the particles supposedly FTL does contain information though. What I meant was that we cannot encode our own arbitrary information on top of it. The message has a physical effect on reality, without it the state we find the particles in cannot be respected.

Just reconsider this: If we agree that the result of a measurement is totally random (no hidden variable predetermining the result of the measurement) but that once we measure and know the state of one particle then we know with certainty the state of the other particle (entanglement): information about the collapse of the first measured particle was shared to the other so that it’s no longer random.

edit: If your argument is about “sharing information doesn’t imply transmission” then let’s stop here and leave this thread agreeing that “information was shared” :)

I have no opinions on what shape the information sharing takes. Nor am I interested in guessing.

I mean you can setup a source of entangled particles and two very far detectors that would do measurements roughly at the same time on each particle in such a way that information traveling at the speed of light wouldn’t have time to travel the distance between both detectors.

You can then just gather roughly simultaneous measurements and at a later time join the datasets from both detectors to see what one measured vs the other for each pair.

If I understand correctly the current observations show that collapsing the state of one of the particle influences the other all the way at the other detector. Since there’s no hidden variables that predetermine the result of measurements while the result of the collapse is random, and the fact that particles still respect the correlation over any distance is why there seem to be a FTL communication between the particles.

Something has to be communicated between the particles for the influence to work FTL, but it also seem we cannot leverage this phenomenon to send “actual information” this way :/

edit: Important point with that experiment: once the particles have been observed, if you try the experiment a second time using the same particles, then you’ll get different results, this time in line with hidden variables because the particle’s state already collapsed.

The 2022 nobel prize was given to experimentalists that observed the violation of Bell’s inequality.

https://en.m.wikipedia.org/wiki/Bell's_theorem https://en.m.wikipedia.org/wiki/Quantum_nonlocality

I’m genuinely not an expert but I get it to mean that there aren’t hidden variables created alongside the entangled particles.

https://www.khanacademy.org/computing/computers-and-internet/xcae6f4a7ff015e7d:the-internet/xcae6f4a7ff015e7d:routing-with-redundancy/a/internet-routing

I wouldn’t call that “messy and inefficient” but you do you. I’d be curious to know what’s a “clean and efficient” solution for you when it comes to routing packets around the planet :)

It’s like you’re sucking the fun out of us… Wait a minute

By “the most exposure to writing code the better” I might have meant to expose people to as many paradigms and patterns as possible and them have dealt with it. i.e. Writing a (shitty) eventloop is what really made it stick for me with async/callback-based programming.

I’m not a good comment writer so here’s some text:

Not a teacher, but Python is great to discover various aspects of programming (algorithmic, flow control, I/O, OOP, metaprogramming). It’s also easy to setup.

Java is just painful. The environment setup and the various frameworks available there are just way too overwhelming.

JS is actually close to Python in my opinion, and better suited for getting introduced to functional programming while still using a non-functional language. See anonymous functions/arrow functions. APIs are heavily callback-oriented which is also a great thing to get used to: You can register a bit of computation (a function) to be executed some other time, i.e. when something happens. You are not in control of the execution of that function, someone else is and will call you back. This is something important to learn (imo).

Finding the optimum algorithm is not important in the beginning (imo). When writing code there’s often two pretty different activities that happen:

1. Defining and organizing your abstractions and flow.

2. Identify bottlenecks and search for fast enough/memory efficient solutions.

In most real world scenarios, having good program flow and abstractions will be enough. Not everyone works on real-time terabyte-sized data processing. See gamemaking: it’s a very performance sensitive domain yet frameworks allow anyone to make a decent game. Why? Because for most problems, someone already wrote a library that’s fast enough. You just need to wire things properly together.

Teaching something lower-level like C/C++ is great, but you need to spend time deconstructing all the goodies people got used too when dealing with other languages. i.e. Why you can’t create an array with different types/structs inside anymore (not without pointers).

And then just get them to practice writing different bits of software with increasing complexity, over the year(s). The most exposure to writing code the better. Trial and error is how anything is learned, and while you might try to warn your students about common pitfalls it might only really click once they’ll make the mistake. Push them in situations where they’ll make mistakes.

The most important mindset to have (imo) is to constantly challenge yourself and your work: find ways to break your own stuff. Maybe you’ll miss cases but the better you get at anticipating breakage, the better you’ll get at writing robust software.

The second most important thing is to seek to understand every line of code you write and as many implications as possible. A program is supposed to be deterministic, there’s very few surprises to be had when dealing with code (there are some though). What I mean by that is: if someone reports a bug, it can often be enough to read the code with the unexpected result in mind and work your way back to the places that allowed for this bug to occur, just by reading statically.

Lastly one thing that was motivating for me when learning programming was when our programs would run against one another. Competition fosters innovation.

I hope these pieces of opinion help with anything…

Technically speaking it would pick up the men in metal armors, not the wooden horse per se.

But the barrier would lift for the wooden horse full of men in armor indeed.

Sorry that’s A-tier