As a counterpoint: Look at the history of the libxcb: https://en.wikipedia.org/wiki/XCB
[Bart] Massey and others have worked to prove key portions of XCB formally correct using Z notation.
That sounds like math to me. Or is it "craft"?As a counterpoint: Look at the history of the libxcb: https://en.wikipedia.org/wiki/XCB
[Bart] Massey and others have worked to prove key portions of XCB formally correct using Z notation.
That sounds like math to me. Or is it "craft"?[otherwise a (code) monkey could do it] is missing the point of programming.
I know managers who code (occasionally) who think similar. I thought so personally before I had actual prolonged experience with professional programming.
It is hard to express it concisely: why it is fundamentally wrong (category error: like thinking that perl regexes can be reduced to DFA--it is impossible in the general case even if DFAs can [sometimes even should] be used in many cases instead).
It is the same reason why waterfall programming fails most of the time. It is the same reason why generating code from UML diagrams produced by analysts is also a failure in the general case. It is the same reason why log normal distribution can be a good model for software estimation https://news.ycombinator.com/item?id=26393332
And no, you can't replace all programmers with a LLM prompt for the same reason (at least until [if ever] it reaches AGI and then humanity would have much bigger problems).
"agile" became a noun but if you look at the origins, you might get why "craft" may be applied to programming. Try "The Pragmatic Programmer" book.
Mathy projects, formally driven: matrix multiply libraries, symbolic computation, constraint resolution, ...
Engineered projects, formally (or close to it) verifiable: 3D rendering pipeline, distributed database management, garbage collection process, ...
And craft. Which, based on the internet I have experienced, many apps unjustly inflicted upon me, and some memorable restarts between game saves, is most code.
Craft code necessarily involves amateur code, code which isn't economically worth engineering (when you can just throw unit tests at it. Or just wait for user reports!), code referencing weakly characterized libraries or interfaces, and code involving features that have become complex enough that the best reference model for its expected and unexpected behaviors is now itself.
Bzilion's Law of Coding Formalism Levels: "Any ambitious enough software project will descend into an exercise of pure desperate craft. Just before it becomes gambling."