Coding Isn't Programming

You forgot "hacker" :D

IMO it's a pure waste of time to react to the headline without engaging the content.

> Coder, programmer, software engineer call yourself whatever you want, the point is to make a computer do what you want it to do.

That is definitely not what software engineering is. It requires translating requirements and ensuring that the code is maintainable in the context of a team and the product's lifecycle.

At least in Germany you can only call yourself a software engineer if you've got an actual engineering degree.

> The professional title "engineer" is legally protected under the German Engineering Act [0].

[0] https://verwaltung.bund.de/leistungsverzeichnis/EN/leistung/...

Building a bridge and building a sand castle are two entirely different things.

Each impressive in their own way, but clearly there is a difference both in terms of the skills required and the outcomes enabled.

I think the specific term used matters less than the ability to distinguish between different types of building things.

If you want to build a bridge, you’re not going to hire the sand castle builder if sand castles are all they have built.

I recently attended ICWMM, a conference of people who model stormwater for a living.

Many of the people there technically program for a living, because some of their models rely on Python scripts.

They are not software engineers. These aren't programs designed around security issues, or scalability issues, maintainability issues, or even following processes like pull requests.

I laughed at this. Having a lovely fixed and unmovable perspective on many pursuits is so engineering. Coding, programming, etc, shapes our communications skills and our outlook in interesting ways. Dating truly benefits as well.

"Vibe coding" seems like one of those things where there's way more people complaining about the concept than there ever were people actually promoting it in the first place.

> he was angry in the 80s in my parents living room

Yikes, how bad was your parents’ living room?

Vibe coding is analogous to programming while high with identical results.

What exactly was he angry at?

> a pyramid of shite

Why do some people use such abominations like "shite" or "shoot" instead of just using "shit"? C'mon lads, everyone knows what you want to say, why not just say it?

With all due respect to Dr. Lamport, whose work I greatly admire, I take issue with his example of the max function. The problem he sets up is “what to do with an empty sequence.” He proceeds to handwave the integers and suggest that negative infinity is the right value. But in realistic use cases for max, I want to assume that it produces a finite number, and if the inputs are integral, I expect an integer to pop out.

Apologies to Lamport if he addresses this later; this is where I quit watching.

There are basically two ways out of this, that I’m aware of: either return an error, or make the initial value of the reduction explicit in the function signature, i.e.:

    max(x, xs)

    max(xs)

> Thinking is always better than not thinking.

"Truer words were never spoken." --Case from Gibson's Neuromancer

Key points:

    Algorithm vs. Program: An algorithm is a high-level, abstract concept implementable in various programming languages. We should focus on the ideas, not specific languages.

    Concurrency Challenges: Concurrent programs are hard due to thread interleaving, leading to numerous possible executions. Debugging is unreliable, and changes can expose hidden bugs.

    Abstraction is Key: Find an abstract view of the program, especially for concurrency, describing how threads synchronize. This higher-level thinking is crucial before coding.

    All programs: any piece of code that requires thinking before you write code.

    What and How: For most programs, write both "what" the program does and "how" it does it. Precise languages (like Lamport's TLA+) are vital for verifying concurrent programs but not essential for all.

    Trivial Example: A simple "max element in array" function illustrates how abstraction simplifies even trivial problems. It revealed a bug in the initial "what" (handling empty arrays) and led to a more robust solution using mathematical concepts (minus infinity).

    Executions as State Sequences: View program executions as sequences of states, where the next state depends solely on the current one. This simplifies understanding.

    Invariants: An invariant is a condition true for all states of all executions. Understanding invariants is crucial for proving program correctness.

    Termination: The example program doesn't always terminate, showcasing the need to consider termination conditions.

    Real-World TLA+ Usage: Amazon Web Services uses TLA+ to find design flaws before coding, saving time and money. The Rosetta mission's operating system, Virtuoso, used TLA+ for a cleaner architecture and 10x code reduction.

    Abstraction Beyond Concurrency: Even when the "what" is imprecise (like a pretty-printer), abstraction helps by providing high-level rules, making debugging easier.

    Thinking and Writing: Thinking requires writing. Writing helps you think better, and vice versa.

    Learn Abstraction: Abstraction is central to math. Programmers should learn to think abstractly, possibly with guidance from mathematicians.

    Why Programs Should Have Bugs: Library programs often lack precise descriptions, making them hard to use correctly. This is especially true for concurrent programs where input/output relations aren't sufficient.

> starting the search with the value negative infinity

But then there is no differentiation between the result of the empty set and a set containing only negative infinities.

I consider them separate conditions and would therefore make them separate return values.

That's why I would prefer returning a tuple of a bool hasMax and an int maxV, where maxV's int value is only meaningful if hasMax is true, meaning that the set is non-empty.

Another way of doing such would be passing in an int defMax that is returned for the empty set, but that runs into the same problem should the set's actual max value be that defVal.

Anyway, I typed it up differently in my other toplevel comment in this thread.

>> separate the "What?" from the "How?"

This is a huge mental error that people make over and over again. There is no absolute "what" and "how", they are just different levels of abstraction - with important inflection points along the way.

The highest level of abstraction is to simply increase happiness. Usually this is accomplished by trying to increase NPV. Let's do that by making and selling an accounting app. This continues to get more and more concrete down to decisions like "should I use a for loop or a while loop"

Clearly from the above example, "increase NPV" is not an important inflection point as it is undifferentiated and not concrete enough to make any difference. Similarly "for loop vs while loop" is likely not an inflection point either. Rather, there are important decisions along the way that make a given objective a success. Sometimes details can make a massive difference.

I think he argues that more thought should go into explicitly designing the behaviour of a software system ("What?"), independently from its implementation ("How?"). Explicitly designed program behaviour is an abstraction (an algorithm or a set of rules) separate from its implementation (code written in a specific language).

Even if a user cannot precisely explain what a program needs to do, programmers should still explicitly design its behaviour. The benefit, he argues, is that having this explicit design enables you to verify whether the implementation is actually correct. Real-world programs without such designs, he jokes, are by definition bug-free, because without a design you can't determine if certain behaviour is intentional or a bug.

Although I have no experience with TLA+ (which he designed for this purpose in the context of concurrency), this advice does ring true. I have mentored countless programmers, and I've observed that many (junior) programmers see program behaviour as an unintentional consequence of their code, rather than as deliberate choices made before or during programming. They often do not worry about "corner cases", accepting whichever behaviour emerges from their implementation.

Lamport says: no, all behaviour must be intentional. Furthermore, he argues that if you properly design the intended program behaviour, your implementation becomes much simpler. I fully agree!

Separating the "What" from the "How" is a pretty old idea originating from Prolog, and yes you can do that. Erlang for example, in which many of Lamport's ideas are implemented, is a variation of Prolog.

Prolog by itself haven't found any real world applications as of today, because by ignoring the "How", performance suffers a lot, even though the algorithm might be correct.

That's the reason algorithms are implemented procedurally, and then some invariants of the program are proved on top of the procedural algorithm using a theorem prover like TLA+.

But in practice we implement procedural algorithms and we don't prove any property on top of them. It is not like the average programmer writes code for spaceships. The spaceship market is not significant enough to warrant that much additional effort.

Isn't that more or less what all abstraction is about, getting an interface that allows you to work with the "what" but not the "how". When I call file open, I get the "what", a file to work with, but not the "how", DMA access, Spinning rust, SSDs, could be an NFS in there who knows.

Yes, the "hows" have impacts on performance. When implementing or selecting the "how" those performance criteria flow down into "how" requirements. As far as I am concerned that is no difference from correctness requirements placed on the "how".

Coming from the other direction. If I am hard disk manufacturer I don't care about the "what". I only care about the "how" of getting storage and the disk IO interface implemented so that my disk is usable by the file system abstraction that the "what" cares about. I may not know the exact performance criteria for your "what", but more performance equals more "whats" satisfied and willing to use my how.

"not 2, not 1" is the old Zen abstraction for deeply interrelated, but separate concepts.

The What puts constraints on the How, while the How puts constraints on the What.

I would say the the What is the spacial definition of the algorithm's potential data set, while the How is the temporal definition of the algorithm's potential execution path.

As I look around at the state of software development in the tech industry, I see a desperate need for more pedantry, not less. As a whole the industry seems bent on selling garbage that barely works, then gradually making it worse in pursuit of growth-at-all-costs.

When nobody cares if their systems work in any meaningful way, of course they'll dismiss anything that hints are rigor and professionalism as pedantry.

Yes, I had to pump it through Gemini 3 times before I could really get what he was talking about. He spends the first 3 and half minutes just starting to frame the subject, which I gleaned from reading the transcript. I wonder if this is just his academic background or a long career of billing by the hour. Probably both.

I think the distinction is evident in the words themselves. Coding creates code, programming creates programs.

If you write code but it doesn't create a program (i.e. you are just recording data) then you're coding but not programming.

Likewise, if you create a program without writing any code (for example, the way a pilot programs routes into his nav computer, or the way you can program a modern thermostat to have specific temperatures at specific times of the day) you're programming but not coding.