The economy of scale is the mechanism that provides the mutual economic benefit - the environment of trust is the political situation that facilitates economies of scale expanding beyond national borders.
> The structure of British democracy kept fascists away, not British people.
That sentence was particularly hard to parse. It read like you were saying that the structure of British democracy kept fascists away, but did not keep the British people away (???).
I did manage to figure it out eventually though. I think you meant to write:
It was the structure of British democracy that kept fascists away, not the British people.
The other replies do a good job of explaining what 2s complement is.
I find the best way to understand why 2s complement is so desirable is to write down the entire number line for e.g. 3-bit integers.
Using 1s complement, the negative numbers are backwards. 2s complement fixes this, so that arithmetic works and you can do addition and subtraction without any extra steps.
(Remember that negative numbers are less than positive numbers, so the correct way to count them is:
I've been working quite heavily with async Python for five and a half years now. I've been the principal developer of a control system framework for laboratory automation, written pretty much entirely in async Python. I say framework because it's a reusable engine that has gone on to become the foundation for three projects so far. Our organization is primarily involved in materials research.
At it's heart it's kind of like an asynchronous task execution engine that sits on top of an I/O layer which allows the high-level code to coordinate the activities of various equipment. Stuff like robot arms, furnace PID controllers, gantry systems, an automatic hydraulic press/spot welder (in one case), various kinds of pneumatic or stepper actuated mechanisms, and of course, measurement instruments. Often there might be a microcontroller intermediary, but the vast majority of the work is handled by Python.
My experience with async Python has been pretty positive, and I'm very happy with our choice to lean heavily into async. Contrary to some of the comments here I don't find the language's async facilities to be rough at all. Having cancellation work smoothly is also pretty important to us and I can't say I've experienced any pain points with exception-based cancellation. Maybe we've been lucky, but injecting an exception into a task to cancel it actually does work pretty reliably. Integrating dependencies that expose blocking APIs has never been a big deal either. Usually you want to have an interface layer for every third party dependency anyways, and it's no big to deal to just write an async wrapper that uses a threads or a thread pool to keep the blocking stuff off of the main thread.
I personally think that a lot of people's negative experiences here might have more to do with asyncio than the language's async features. Prior to stepping into my current role, I also had some rough experiences with asyncio, which is why we chose to build all of our async code on top of curio. There was some uncertainty at first about how well supported it would be compared to a package in the standard library, but honestly curio is a really well put together package that just works really smoothly.
Oh hey, I'm the mirror universe version of you. I used to work in a semiconductor plant, writing Python code that controlled robot arms and electronic measurement instruments and so on. In my universe we used threads over blocking calls instead of async and it was exactly as bad as you might imagine.
>Having cancellation work smoothly is also pretty important to us
+10000. Threads don't have good cancellation semantics, so we never had a robust solution to the "emergency shutdown" problem where you need to tell all the running equipment to stop whatever they're doing and return to safe positions.
Every day I worked on that codebase I wished it had been async from the beginning, but I couldn't see a way to migrate gradually because function coloring makes it an all-or-nothing affair.
A lot of negative comments in this thread, but I think the article makes one really good point, that has had far-reaching consequences for for society before and beyond AI: humans are pretty bad at assessing intelligence.
Yeah, "commodification" is the wrong word here. I'm not sure what the best word would be, but it would be more along the lines of "extraction" or "exploitation".
As in:
The last 15 years has been just relentless attempts to bend and twist everything the previous generation has built to extract value instead of creating it.
Ehh, I think the real footgun here is using a property with backing storage to store what is clearly a derived value. Using a computed property is what we really should be doing here, if we think our code should line up with our intentions.
I feel like what's happened here is that the author actually needed a system to cache their derived values, but didn't think to build that out explicitly.
As a teen I used to play around with Core Wars, and my high school taught 8086 assembly. I think I got a decent grasp of it, enough to implement quicksort in 8086 while sitting through a very boring class, and test it in the simulator later.
I mean, probably few people ever need to use it for something serious, but that doesn't mean they don't understand it.
Really what produces an advantage is an environment of trust. Having that reduces a lot of friction when it comes to economic activity.