Coding Isn't Programming
LLM “Vibe Coding” and Productivity
- Several comments discuss “vibe coding” as using LLM agents to generate almost all code, with humans mainly guiding, configuring, and reviewing PRs.
- One poster claims they no longer hand‑write frontend code and achieve “team‑level” output via agents.
- Others report occasional “mind‑blowing” results from LLMs but say this is rare and inconsistent.
Skepticism About LLMs and Complexity
- Many participants say LLMs work well for boilerplate, common stacks (especially React/frontend), and small scripts, but break down around 100–300 LOC or when full‑codebase context is needed.
- Observed problems: looping between a few wrong templates, non‑compiling code, forgetting prior edits, deleting needed code, poor performance on niche tools/languages, and inability to handle real business‑scale complexity without strong human guidance.
- Predictions that “everything will change next year” are compared to repeated self‑driving car timelines; several expect disappointment and note lack of a clear “Moore’s law for LLMs.”
Lamport’s Thesis: What vs How, Algorithms vs Programs
- Multiple summaries of the talk:
- Programming should be “thinking and abstraction first, then coding.”
- Algorithms are abstract; programs are concrete implementations.
- Executions should be modeled as sequences of states; invariants (properties true in all states) are central to correctness, especially in concurrency.
- Good specs separate what a system should do from how it does it; without specs, behavior can’t meaningfully be called “correct” or “buggy.”
- Commenters generally agree abstraction and explicit behavior design improve correctness, but some argue “what” vs “how” is purely relative abstraction, not a hard boundary.
Max-Function / Negative-Infinity Example
- The talk’s “find max in an array” example and use of “−∞” to handle empty arrays spark debate.
- Critics note ambiguity between an empty array and one containing only −∞, and argue for explicit error flags or non‑empty types instead.
- Others say the −∞ trick is acceptable at the abstract/spec level, with mapping to error handling done at implementation time; some point out the spec is closer to a supremum than a maximum.
Terminology: Coding, Programming, Software Engineering
- One camp says “coding/programming/software engineering/hacking” are effectively interchangeable in practice; arguing fine distinctions is unhelpful pedantry.
- Another camp insists the distinctions matter:
- Coding = producing code;
- Programming/engineering = designing systems over time, handling correctness, maintainability, concurrency, safety, etc.
- Some see the “coding isn’t programming” line as a post‑LLM move to define human value as design/abstraction rather than typing code; others note this debate long predates LLMs and echoes older “bricklayer vs architect” tensions.
Professionalization and Title Gatekeeping
- Discussion of “software engineer” as a protected title in some jurisdictions (e.g., parts of Germany) leads to broader debate:
- Pro‑gatekeeping: society needs licensed professionals (like civil engineers, doctors) when failure has serious public consequences.
- Anti‑gatekeeping: paper credentials often block capable practitioners, with historical examples where great contributors lacked formal recognition.
- Some argue that for most software (non–safety critical), strong licensing is unnecessary; for safety‑critical domains, responsibility should rest on domain‑specific regulations and audited tooling.
Pedantry, Formalism, and Accessibility
- Some find the talk and thread “insanely pedantic,” others say the industry’s low rigor justifies more pedantry.
- The shift from plain language to mathematical logic in the talk is criticized as alienating to most practitioners and reminiscent of waterfall/UML‑style processes; defenders say more formal math/logic training for programmers would be beneficial.
- There is acknowledgment that abstraction and specs are powerful, but also concern that highly formal methods are usable only by a small subset of mathematically trained developers.