[vajrabum]

Old time programmers often wrote everything down before inputting it and engaged with their code instead of with tests and the debugger. Not to say tests and the debugger don't have their place. Here's the handwritten sheets for the Algol 58 compiler that Don Knuth wrote in assembly for the Burroughs 205.

https://archive.computerhistory.org/resources/text/Knuth_Don...

He's famous as a programmer who got things right the first time. And that's been consistent over his career. A lot of what's in there is obsolete, but notice that even in 1960 he was doing something on paper like the literate programming that he developed later.

[tty2300]

That's just because you had to program on punch cards and run your progran over hours to see if it worked. Now its faster to just run the tests and see how it went rather than spend ages reading the code trying to spot issues.

[kragen]

A lot of novices think that, but it turns out that there are many problems that are easy to find by code reviews that are hard to find by testing. (And vice versa — testing is very valuable, especially with things like Hypothesis.)

I'm skeptical that the scope of things you can get working at all by mindlessly banging on tests without thinking about the problem is very large, and when you add other aspects of the software development lifecycle, your prospects seem very slender indeed. If reading your code takes "ages", how are you going to figure out how to extend it next week when you need to change what it does? How are you going to debug it when it crashes once you put in production?

I have written compilers in a somewhat test-driven fashion, and I am especially skeptical that you can purely TDD a compiler. Certainly I've never seen it done. I'm far more skeptical that you could TDD a compiler written in assembly language that achieves the kind of performance this scenario implies. (But tests, especially regression tests, are extremely valuable for writing compilers.)

The particular compiler we're talking about here was one Knuth wrote during a summer-long road trip for US$5500 (roughly US$120 000 today). So the situation was actually considerably more extreme than you're imagining — not only did he not have punch cards when he wrote the compiler, he'd never seen the computer. So he had to spend a few months debugging it after he actually finished driving to the other side of the continent where the computer was.

https://github.com/kragen/knuth-interview-2006#27---writing-...

[tty2300]

In 2019 you could build a compiler in your free time for free so that probably says something about modern development practicices.

I have been working on my current codebase for almost a year now and still haven't seen half of it. There is no just read over it because its massive. Tests are the only thing that makes it manageable. When I want to change something I can find the part that needs to change but I have no idea what features I don't know about that depend on that feature doing something. Tests allow me to very quickly automatically scan the code base to show what things changed.

[kragen]

Knuth had previously built a couple of compilers in 1957 and 1958, as you can read in the interview I linked, but it's sort of ambiguous as to whether it was "in his free time" — his job gave him and his friends access to a computer but I don't think writing compilers was declared to be part of their responsibilities. It wasn't for free, though. I think what that says about modern development practices is that we have cheap computers.

I agree that tests are very valuable for the reason you describe, as well as for other reasons. What codebase are you working on?