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.

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

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.

(Construction planner has three arms)

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

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.

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/

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

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.

Is the animation comically slow for anyone else?

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.

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.

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?

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.

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.

> I’m reminded of

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

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?