Hacker News: mattclarkdotnet

New comment by mattclarkdotnet in "Migrating the American express payment network, twice"

mattclarkdotnet — Mon, 23 Mar 2026 08:54:03 +0000

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.

New comment by mattclarkdotnet in "Migrating the American express payment network, twice"

mattclarkdotnet — Mon, 23 Mar 2026 03:40:53 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Thu, 19 Mar 2026 22:51:42 +0000

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

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 05:34:47 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:53:58 +0000

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

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:51:09 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:48:32 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:45:18 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:20:26 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:11:55 +0000

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

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 04:03:55 +0000

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.

New comment by mattclarkdotnet in "Python 3.15's JIT is now back on track"

mattclarkdotnet — Wed, 18 Mar 2026 03:31:47 +0000

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

New comment by mattclarkdotnet in "US SEC preparing to scrap quarterly reporting requirement"

mattclarkdotnet — Tue, 17 Mar 2026 04:43:31 +0000

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.

New comment by mattclarkdotnet in "US SEC preparing to scrap quarterly reporting requirement"

mattclarkdotnet — Tue, 17 Mar 2026 04:38:51 +0000

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.

New comment by mattclarkdotnet in "Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)"

mattclarkdotnet — Thu, 26 Feb 2026 12:53:01 +0000

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

New comment by mattclarkdotnet in "Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)"

mattclarkdotnet — Thu, 26 Feb 2026 05:57:36 +0000

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?

New comment by mattclarkdotnet in "Dissecting the CPU-memory relationship in garbage collection (OpenJDK 26)"

mattclarkdotnet — Thu, 26 Feb 2026 01:10:30 +0000

Sorry if this is obvious to Java experts, but much as parallel GC is fine for batch workloads, is there a case for explicit GC control for web workloads? For example a single request to a web server will create a bunch of objects, but then when it completes 200ms later they can all be destroyed, so why even run GC during the request thread execution?

New comment by mattclarkdotnet in "“Car Wash” test with 53 models"

mattclarkdotnet — Tue, 24 Feb 2026 11:05:32 +0000

Seems like you’re the one not applying common sense now!

New comment by mattclarkdotnet in "Writing code is cheap now"

mattclarkdotnet — Tue, 24 Feb 2026 11:04:05 +0000

So… XP was the right way all along?

New comment by mattclarkdotnet in "AI Added 'Basically Zero' to US Economic Growth Last Year, Goldman Sachs Says"

mattclarkdotnet — Tue, 24 Feb 2026 03:00:09 +0000

If you were to force the choice I might agree. But I’d prefer to think there’s likely a sliding scale in operation here. Even humans aren’t conscious all the time, or equally conscious at all times. It will be an amazing day when we figure this out.