mattclarkdotnet

Why would any of those compounds come from fossil fuels? Sulfur is mined, hydrogen peroxide is water with some oxygen taken off, and sodium carbonate is made from salt and limestone

For PCB design 5.6 Sol/Terra is streets ahead of 5.5, and uses fewer tokens, so I'm not sure it can really be the same model.

The problem is the assumption that in most debates there are sides to be taken, and that there are 2 of them. It leads to shoddy journalism where "balance" means finding someone to debate another, regardless of the bizarreness of their position.

In the real world there are many perspectives on a given issue, and a lot to be learned by everyone through open discussion. "Both sides" mentality discourages this, and also tends to give too much airtime to extreme views.

It's almost certainly meant to be 27%, not a factor of 27.

So you’re wanting to bet that we’ll get humanoid robots capable of driving a dumb car at L4 before we get cars capable of L5? When we have no humanoid robots driving cars, and many L4 cars driving around? I’ll take that!

Only by embracing solipsism, in which case why are you here debating things, since your entire truth is derivable from your existence alone with no other observations or interactions required?

Philosophy can be perfectly effective as a tool of thought while still being unable to resolve self evidently unsolvable “ultimate questions”

The theistic schism? I had to look it up, and was not cleverer after. Nobody can ever know an ultimate why, for obvious and well established philosophical reasons. At least the scientists are trying to squeeze the knowledge gap down as small as possible instead of making up stories.

Oh it's worse than that, for distribution and playback sampling at more than 48kHz is likely worse in many ways due to unwanted ultrasonic noise and increased intermodulation distortion. 96/24 makes sense for production, and 96/float56 is common in DSP chains.

The analog input will use separate ADC modules, just as the analog output uses separate DACs. DSPi itself is purely digital (OK, excepting the PWM based sub out). These modules are just a few dollars on AliExpress for ~96dB SINAD

I2S input is on the roadmap, and hardware modules from AliExpress are being tested by Troy, so yes you will get plenty of analog inputs!

It's for the pico. RP2040 works fine, but RP2350 has a hardware FPU and much more processing capability, so supports more channels and filters

We throw away food because we are so good at making it cheaply that the problem has shifted to distribution costs and fair wages. Also high productivity economies need to deal effectively with the Baumol effect (https://en.wikipedia.org/wiki/Baumol_effect). If they don't then even people in the USA can be food poor despite huge GDP per capita.

You might enjoy the book "Red Plenty" by Francis Spufford, which traces the consequences of this thesis ("Capitalism already is a poor allocator") through the Khrushchev years of the USSR, seen through the eyes of the economists, mathematicians and planners who tried to do better than capitalism.

Of course there are in-between approaches like industrial policy in mixed economies, for example the South Korean shipbuilding industry. But those tend to work with the grain of capitalism, not against it.

At best it’s checking available credit. All the other stuff is done after the fact. The idea that any banking transaction involves “subtracting one number from another” is so wrong it’s barely worth engaging with.

Since when were payment networks latency sensitive? It’s usually 2 or more seconds to even get a payment up on the card terminal from the merchant POST system, then 2-5 seconds more from card presentation to getting approval back.

Thank you! Spy looks brilliant, especially the comptime-like freezing after import.

What's nuts is that the language doesn't guarantee that successive references to the same member value within the same function body are stable. You can look it up once, go off and do something else, and look it up again and it's changed. It's dynamism taken to an unnecessary extreme. Nobody in the real world expects this behaviour. Making it just a bit less dynamic wouldn't change the fundamentals of the language but it would make it a lot more tractable.

Let's not get started on the cached shared object refs for small integers....

It's still ridiculous. A hypothetical Python4 would treat function declarations as declarations not executable statements, with no impact on real world code except to remove all the boilerplate checks.

Allowing metaprogramming at module import (or another defined phase) would cover most monkey patching use cases. From __future__ import python4 would allow developers to declare their code optimisable.

Performance is one part of the discussion, but cleanliness is another. A Python4 that actually used typing in the interpreter, had value types, had a comptime phase to allow most metaprogramming to work (like monkey patching for tests) would be great! It would be faster, cleaner, easier to reason about, and still retain the great syntax and flexibility of the language.

Oh, and while we're at it, fix the "empty array is instantiated at parse time so all your functions with a default empty array argument share the same object" bullshit.

To clarify, it is nuts that in an object method, there is a performance enhancement through caching a member value.

  class SomeClass
    def init(self)
      self.x = 0
    def SomeMethod(self)
      q = self.x
      ## do stuff with q, because otherwise you're dereferencing self.x all the damn time

RPython is great, but it changes semantics in all sorts of ways. No sets for example. WTF? The native Set type is one of the best features of Python. Tuples also get mangled in RPython.

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax.

Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e.g. ORM bindings).

Exactly! Continuous reporting reduces the stupid gaming of quarterly results. Weekly would be best as anything longer still gives sales teams enough time to rig the game as they do currently. I'd also get rid of fixed year ends for tax purposes and replace them with continuous trailing 12-month assessments.

In every sales-led company quarter end is a shitshow. It'll be even worse if there's only one chance to bring the numbers back in instead of 2 or 3. It's used to put pressure on sales teams, but the net result over the year is never good because it sours relationships and reduces overall deal value.

The best thing would be continuous daily or weekly reporting with no defined year end. Unfortunately the entire global system of tax and accounting is set up around annual reporting, so change is impossible.

Thank you, that’s what I came here to learn!

Sure, but each request has its own context. Shared resources like DB connection pools will be longer lived but by definition they aren’t alllcated by the request thread. So why not simply exempt everything allocated by a request thread from GC, and simply destroy it on request completion?