[CydeWeys]

These fine-grained attempts at parsing the words to mean things other than how they are commonly used doesn't serve any purpose. Yes, of course the act of physically typing in characters in a programming language is not exactly the same thing about thinking about the algorithms you want the computer to do, but so what? It's trivial and it doesn't matter, and specifically using language to highlight that difference is pointless. To use an analogy, people will often say that "so and so website says X", but the website didn't actually say anything; it can't talk. What they mean is they read so and so text on a website. But we all know what they mean, and it's annoying and pointless to jump in to correct the language there. Similarly, it's annoying and pointless to pedantically argue that "well actually that's not programming, that's coding".

[mrkeen]

> It's trivial and it doesn't matter

They are different and they absolutely do matter.

DateTime.Now() is a perfectly valid thing to write while coding. Unless you are in a distributed system, where 'now' doesn't exist, so all source code using 'DateTime.Now()' is automatically suspect. How do you know if you're in a distributed system? That's a programming question, not a coding question. And from a lot of the microservice push-back you get here on HN ("just use a single DB instance - then your data is always consistent",) a lot of devs don't realise they're in a distributed system.

"Backtracking", "idempotent", "invariant", "transaction", "ACID", "CAP", "secure", "race condition", "CRDT", are all terms that exist at a programming level, but they don't show up in the source code. A single effectful statement in the source code can be enough to break any of these quoted programming terms.

[pron]

> These fine-grained attempts at parsing the words to mean things other than how they are commonly used doesn't serve any purpose.

Except we're talking about a talk title. Lamport explains what he means in the talk. What I responded to was a comment on the content based entirely on the title.

> It's trivial and it doesn't matter, and specifically using language to highlight that difference is pointless.

Sure, and that is precisely Lamport's point. You really need to watch the talk. He shows how abstract algorithms cannot be fully described in any language that is intended to be executed by a computer.

> Similarly, it's annoying and pointless to pedantically argue that "well actually that's not programming, that's coding".

And Lamport is not doing that. You're arguing over a pithy title to a rather deep talk.

[Workaccount2]

>These fine-grained attempts at parsing the words to mean things other than how they are commonly used doesn't serve any purpose.

It's meant to differentiate human "programmers" from AI "coders". Ever since LLM showed up there has been a noticeable urge to redefine the value proposition of software work to be less about what LLMs can do (write code) and more about what humans can do (write programs).

[Swizec]

> Ever since LLM showed up there has been a noticeable urge to redefine the value proposition of software work to be less about what LLMs can do (write code) and more about what humans can do (write programs).

We’ve been having this debate for my entire career (since at least 2010). The suits have always misunderstood what programmers/engineers do and we’ve always pushed back explaining that it really is closer to city planning than to brick laying.

The agile manifesto (2001) was in large part a response to these pressures to think of programmers as the people who “just implement” what the smart suits have already figured all out.