I tried reading Proust's In Search Of Lost Time some time ago, in which the first 10-20 pages are about a guy lying in his bed at night and observing his own thoughts (roughly). And I quickly realised how I was reading the words and even sentences, but couldn't grasp the meaning of them - I couldn't produce a "mental model" or image of what it was about. It was a very humbling experience.

I used to be an avid reader as a child, even as a teenager. That was a long time ago. I'm looking forward to that time when I will have the mental capacity to read long prose again.

Let me highlight this part:

> Everything was ruthlessly sacrificed to cut costs, including pilot safety.

If we translate this analogy back to AI driven software development, what would be the equivalent of "pilot safety"?...

Be very careful who sources your pacemaker.

To me, the odd part is when you compare the performance of RPC vs inline code. You present it as if you found something new and foundational, only possible thanks to AI, when in fact, it has nothing to do with AI, and the results should be no surprise to anyone.

Your original architecture was a kludge to start with, it was a self-inflicted wound. This is probably the craziest part:

> We’d tried a few things over the years - optimizing expressions, output caching, and even embedding V8 directly into Go (to avoid the network hop).

I know hindsight is 20/20 - but still, you made the wrong decision at the start, and then you kept digging the hole deeper and deeper. Hopefully a good lesson for everyone working with microservices.

To end on a more positive note, I think this (porting code to other languages/platforms) is one use-case where AI code generation really shines, and will be of immense value in the future. Great reporting, just let's not confuse code generation with architectural decisions.

Oh, I don't disagree. The original vision and what the product ended up doing are light years apart. Likely, had we known what it would evolve into, we would have decided on a different solution (perhaps not JSONata at all, for example).

Having said that, My opinion still is that the previous solution had valid business merit. Though inefficient, the fact that it was infinitely scalable and the only limit was pure dollar cost is pretty valuable. It enables business stakeholders / managers to objectively quantify the value of the feature (for X dollars we get Y business, scaling linearly). I've worked in many systems where this was not at all the case, and there was a hard-limit at some point where the feature simply shut down.

Because only those two extremes exist: you either don't have a phone, or your are glued to it?

Of course not, I said nothing of the sort.

I said I’d prefer to not have a phone than be like people who are glued to their phones. I said nothing about all the people in the middle.

Is it not true that when entering the US you are required to show all your social media content on request, and if there is anything negative about the current administration, you can be denied entry (if you are lucky, and not detained for an indefinite amount of time)?

Truly exceptional indeed. You are basically on par with China.

Do they really do that and what do they do when you say you don't have one? Do they believe you or not having one is as suspicious as having one with the content they don't like?

This is just fake info, I was in China previous year and noone entering or exiting was required to show anything except passport.

FWIW, you don't have to do any of that to enter China.

only to exit

Not true also.

if you say so

There are even people who listen to music at home! They even buy expensive speakers just for this purpose =) I listen to music pretty much all the time except when I talk to other people and sleep.

It maybe a surprise to you, but many people actually enjoy 'music' and don't find it to be just noise.

If I don't have my music then I have to listen to my own thoughts, and nobody wants that.

In seriousness, music is one of the small joys of life. Like a morning coffee or the smell of winter. It makes living a little bit more bearable.

> Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits.

I'm not sure I am missing first class delegation much (not a lot of UI projects in Java these days).

But interfaces with default (and static) method implementations are actually quite usable as traits / mixins. Since Java 8 IIRC.

You can also pass around functions / lambdas (coincidentally also since Java 8) to compose functionality together. A bit harder to follow and/or understand, but another perfectly legitimate and very powerful tool nevertheless.

The EGA version was 4 1.44MB disks for MS-DOS, IIRC. Let's say 5MB. That's about 30 disk sides or 15 disks in DD disks. Not that bad actually, and perhaps the C64 images are smaller or more compressible than the EGA ones... So this should be some kind of an upper limit.

It has to be less if they don't want to spoil the in-game 'insert disk 144' joke ;)

IIRC, the original CGA/EGA version was: 8x 360KB 5.25" disks, or 4x 720KB 3.5" disks.

Afaik Amiga was 4 720KB disks for 32 color version.

DD floppies. Amiga's track format got 880KB out of these.

Notably, this is one game that needed RAM expansion on A500, would not work with just the builtin 512KB.

C64 can cheat via cartridge mapper.

This comparison is a bit misleading, as you are not watching the game full screen, but at 1/4 screen size with video compression artifacts. This helps the EGA dithering tremendously.

In reality, dithering can only help you so much, when you have gigantic pixels and 16 colors... It is a remarkable feat what they achieved despite the limits of EGA, but it can't really compare to VGA.

Old CRTs helped blur the image. For that matter, C64 games on TV screens (which is how most people watched them, even though there existed dedicated Commodore monitors) blurred the image so much, the games barely resembled what you can see now with an emulator and a modern screen. Graphics were designed with this in mind.

> It is a remarkable feat what they achieved despite the limits of EGA, but it can't really compare to VGA.

In many cases, especially in the early days, artists didn't know what to do with so many colors, and produced inferior versions. Loom is a good example. The conclusion is that it's less about hardware capabilities and more about artistry, and technical limitations often force artists to be ingenious.

Well yeah, the good old CRT monitors (the worse, the better in this case) also helped with the EGA dithering, while viewing the EGA graphics fullscreen on an 1080p LCD display, you'll have ~30 pixels for each original EGA pixel.

I would just like to point out the fun fact that instead of the brave new MD speak, there is still a `codespeak.json` to configure the build system itself...

...which seems to suggest that the authors themselves don't dogfood their own software. Please tell me that Codespeak was written entirely with Codespeak!

Instead of that json, which is so last year, why not use an agent to create an MD file to setup another agent, that will compile another MD file and feed it to the third agent, that... It is turtles, I mean agents, all the way down!