benrutter

I think that's pretty much true- it's worth saying there are other people who have the insane privilege of the three you mentioned who aren't some of the wealthiest people in the world, so there's some kind of explanation needed aside from just privilege, even if that's just "luck".

This raises such an interesting question, how much of the wealthiest individuals wealth is due to skill, and how much is because in an unequal system there has to be someone at the most wealthiest point.

I think it's an interesting thought, I'm not sure I have a hot take here or anything. The likes of Jeff Bezos and Elon Musk are clearly good at amassing wealth (and interested in amassing wealth) but I suspect a lot less is attributable to skill than many would think.

I work in Python every day and think about this a lot - people really don't seem worried about its performance. Sure people want it to be faster, but I don't see very many people changing their language choice for a faster language, despite Python being a lot slower than most alternatives.

If I think about where I see python being used though, this kind of makes sense, the two big use cases are:

- Web APIs and backends, where for the most part either the network or the database is the bottleneck

- Data science work, where for the most part, work exists in libraries like polars, pytorch etc that ship the main work out to other languages.

So from that perspective, although we'd all like python do be faster, it's speed isn't the bottleneck in the use cases where its popular (that's probably also the reason why we don't see Python getting used in other speed critical places).

That's a really different story to JavaScript, which doesn't have a handy CFFI or otherwise you can just reach out to. There are a lot of cases where JavaScript speed improving would speed up the reactivity of a web app, even now.

I'm not arguing against a faster CPython - I'd love one! But I think there's a clear reason why it hasn't been prioritised historically in the way JavaScript's performance has.

> How many Python JIT experiments have failed?

Wait, how many? I'd say just this one. The other that I know of, pypy, was massively successful for a single maintainer project. And definitely showed the possibility/potential of JIT python.

I wouldn't call it a failure for not over taking mainline CPython.

Which bits of tone felt AI to you? It didn't set off my internal "ai-detector", not that I'm an expert or anything.

This is a fun idea- it's a shame it's tied to anthropic models though. From the transcripts, I think this looks like it'd work well even with quite a small (10B parameter or so) local model.

I work in python daily, it's not necessarily my favourite language, but I'd say it's mostly fine.

What languages are you thinking of specifically when you mention better thought out ones?

Is this really a thing in the US? At least in Europe, rooftop solar like OP mentioned doesn't require grid-connection?

This is a good question - there are fairly high imposed tariffs on solar in the US[0] but I think the labor is the big part. Over here in the UK, solar installation would cost about $12k dollars, so quite a bit cheaper, but still not below $10k.

One thing that isn't super obvious from the article is that a lot of it is talking about industry solar panels rather than rooftop. The overheads of installation etc get a lot smaller if you're installing a whole bunch at once.

This isn't to say that installing solar panels on your house is a bad idea - they normally pay for themselves after something like 10 years from memory, so are similar to double glazing.

[0] https://www.energy.gov/cmei/systems/overview-trade-and-polic...

I think limiting presidential terms is pretty American, I can't see why its undemocratic to stand for longer as long as there are still elections, free press, right to protest etc.

In the US, FDR stood 4 terms, and he was hardly the end of democracy.

Yeah, that's an interesting case study. It's pretty common practice to do something like llm-as-a-judge if your programming agentic systems.

I think those are different from pure "natural langyage programming" though because there's normally code you've written that's calling out to the LLM, so it's within the context of written code.

I think this, and lots of other comments are so interesting. There are a lot of different increasingly complex ways LLM outputs and coding are being tied together by people, that I hadn't really considered.

I still don't know if I'd agree with you. I think:

> the preferred form of the work to making modifications to it

Implies what you point to when you want to know where to make changes.

That wouldn't be a prompt - you might use a prompt to make changes, but the thing you're making changes to, certainly at present, is your java/python/rust++ /whatever codebase.

Lots of projects, even fully vibecodes ones, don't push and include prompts in their repos. But they all push the java code (sticking with java as an example for the sake of argument).

I can't imagine that working on a project where the java code is omitted, and people make changes to the software just by editing the prompts would go well. It's an interesting thought experiment, but I think you'd find it very hard to work on any kind of team where that was the practice.

I don't have strong opinions on when it's ok to use the work "programming" or not, but I think if you're using claude-code/pi/open-code/etc to produce something like a website or application, the "program" is the code the LLM outputs, not your prompt etc.

I don't think I'd want to call it "natural language programming" in the way Dijstra's implying here unless the prompt was the thing that was actively being executed/ran/whatever when someone loads your app or website.

Yes, I think that's a pretty good description of Inform7.

Whether "natural-language-like syntax" is enough "count as natural language programming" is probably a question of definition. For Dijkstra's essay here, he doesn't offer a particular definition, but he certainly seems to be implying something much more fluid and ambiguous than Inform7 is.

I definitely didn't mean to imply Inform7 had achieved the holy-grail of natural language programming or anything.

I think Dijkra's main point he's driving at is here:

> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

I'm inferring/assuming a bunch, but I think he's saying something along the lines of, programming is useful because it is precise, and natural language is not precise, so attempts to make programming languages more like natural language are butting up into this inherent contradiction of precision. And therefore will end up as worse programming languages (for attempting to be more naturalistic).

In the history of programming languages, I think most attempts to be "more natural language like", such as COBOL or AppleScript, do become worse for attempting to walk the tightrope between natural-language and programming. I think Inform7 is unusual in that it achieves that balance in a way that isn't just objectively terrible (you may disagree) - I think that's mostly because it offers very few programming constructs, and is a tool for writing a kind of prose (text adventure games).

Anyway, to come back around, that was my reasoning for mentioning Inform7 - I think it's an interesting deviation from other experiments in natural language programming so far.

It's been a while since I've seen a "weird hands" type image generation problem from AI, so it feels fun to see one on the image for Fable 5.1. [0]

(Construction planner has three arms)

[0] https://www.modelcompare.ai/blog/ai-models-controversial-tak...

I'm at least a tiny bit less ignorant on biology than psychology. I don't think this is the kind of thing that does evolve.

Normally more general capacities than that evolve. We've evolved the ability to learn and adapt, and that's what we're using to create these heuristics. But I don't people evolve into individual beliefs/attitudes in that way.

I think this essay has aged pretty well and remains pretty spot on.

Some people will push back that agent development is "natural language programming" but I don't think that's right. I think in that case the agent is the one programming, and the programming still always happens in a deterministic language like Rust/Python/Typescript/etc. Maybe that'll change, but to me at least the other way would be a disaster.

The best exception I know of though, is definitely the Inform 7 language which is for writing text adventures[0]. It has a lot of fans, and I've never gone deep with it, but seems to do a pretty elegant job or marrying up natural language and programming together in a unique way.

Either way, definitely a must-check-out for any language-geeks interested in natural language programming.

[0] https://ganelson.github.io/inform-website/

I don't know if that is a psychological quirk - it seems pretty rational to me. We are more affected by events that happen close to us than those that happen far away, so instinctively finding local events more interesting than distant ones seems like what I'd expect[0].

[0] Not that my expectation has any weight, I have close to zero knowledge of psychology.

Honestly, with these kind of shenanigans, and having recently read the Meta tell-all "Careless People", I'm amazed at Meta's ability to still disappoint my expectations, despite them being at a low I didn't think could be beaten.

WhatsApp scares me a little to be honest - I can (and have) easily switch from using Facebook, Instagram etc. But WhatsApp is used for all sorts of groups where I live (family, work, political, etc). It's a really sticky technology, and very hard to move off of without convincing a lot of others. That would be bad enough on its own, but combined with Meta's continuous shady goings on, I genuinely feel uncomfortable with how much power is in such disinterested hands.

This is an amazing image, I am fully on board with whatever it is.

Is the animation comically slow for anyone else?

Ah yeah, apologies, I'd assumed you were talking about within city transport even though you didn't say that!

Maybe I'm lucky in my commute, I live in a small town in the UK, and head into London once a week- if I do miss my train it's about 20 minutes until the next at peak times.

I honestly can't think of anything worse than trying to do that journey driving though, it'd be twice as long, and very expensive to park etc.

Yeah I wondered this too! The website explains the features, but from what I can tell it's just the feature set of Helix. I'm sure there's a plan behind what the forker wants to do with the project, would be awesome if the website explained!

Really? What did you not like about Helix that you get from Nano? (No judgement, I'm just curious!)

I don't have anything against Nano, but for something I use every day, I'd really miss go-to-definition, and being able to jump between sections of text quickly.

> Public transport has inherent problems that cannot be solved that will always have it be less convenient than a car.

I guess maybe? My original comment was about the benefits of relatively good public transport vs flying cars (which seem space age but don't add a lot of value to our lives).

I think you're arguing a world with only cars might be more workable than a world with only public transport? I'm not sure that's a choice that's required by anyone though?

> Does not start at your schedule. Missed by a hair? Wait up to 2h.

Doesn't sound like it? What kind of functional transport has a once a 2 hour schedule? I see this in rural areas but not in cities with good public transport.

Haha, there's something so true and so boring about the fact that we'd all be much happier with a good public transport system than flying cars.

Yeah that's so true! I thought that as I was writing, but figured it proved my point more that even with a really charitable interpretation, it's hard to make he case for a 10x speed up at a high level.

I think a lot of us are trying really hard here to avoid the simplest and most obvious answer, which is that AI coding software is helpful, but doesn't deliver the kind of productivity gains boosters are talking about.

There's a bunch of reasons for this, but the obvious one to me is just that I haven't seen any backed up claims that actually break down how a 10x (or similar) speed up would get delivered in practice.

For the sake of an example, let's imagine an engineer who works an 8 hour day split up like this:

- 2 hours: investigating and debugging potential issues

- 1 hour: reviewing code

- 2 hours: in various team meetings, catch ups or otherwise

- 1 hour: designing (including at a level of writing code for prototyping etc)

- 2 hours: actually writing code

I think that's a semi-reasonable day breakdown. Realistically, I think AI helps debug faster, and generate code faster. Possibly design work too, but I think this isn't really the case since AI workflows necessitate a lot more design work in order to make the AI generation deterministic.

So looking at that day, if I was able to fully automate writing code and debugging issues so that it took 0 time at all (which I think is a very optimistic assessment of the actual speed ups AI provides), we're looking at a 2x speed up of an engineers productivity.

If we think AI makes those things twice as fast (so 2 hours, instead of 4) the engineer is now at a 1.25x speed up. That's great, but it's hardly revolutionary. It'll change your output something like the way going from a team of 4 to a team of 5 might do.

This is obviously complete conjecture and I'm sure the average time engineers spend on things is different, but I think there's an obvious take away. If you want to make claims about the performance impact of code, you need to know where the code spends its time, and what impact you're making on those sections of code.

Similarly, if you want to know what performance gains are being made, you need to know what engineers spend their time doing and what impact AI is having of those tasks.

I've seen very little attempt to actually make realistic claims on that basis, and a lot of vibes-based "wooah, AI makes me so much faster" type claims. Those claims are obviously not nothing, but I wouldn't trust people's gut reactions to make serious claims about the overall productivity changes in our entire industry.

No need to be rude! Besides OP just said:

> I’m reminded of

They were drawing a comparison, not saying "x will definitely happen because y"

Genuine question, is this legal under US anti-monipoly laws?

I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.

Surely buying a company out only to close their main offering is defined as anti-competitive?