Re: else ladders practice

On 28/11/2024 17:28, Janis Papanagnou wrote:

On 28.11.2024 15:27, Bart wrote:

[ compilation times ]

>
And for me, used to decades of sub-one-second response times, 7 seconds
seems like for ever. [...]

 Sub-seconds is very important in response times of interactive tools;
I recall we've measured, e.g. for GUI applications, the exact timing,
and we've taken into account results of psychological sciences. The
accepted response times for our applications were somewhere around
0.20 seconds, and even 0.50 seconds was by far unacceptable.
 But we're speaking about compilation times. And I'm a bit astonished
about a sub-second requirement or necessity. I'm typically compiling
source code after I've edited it, where the latter is by far the most
dominating step. And before the editing there's usually the analysis
of code, that requires even more time than the simple but interactive
editing process.

You can make a similar argument about turning on the light switch when entering a room. Flicking light switches is not something you need to do every few seconds, but if the light took 5 seconds to come on (or even one second), it would be incredibly annoying.
It would stop the fluency of whatever you were planning to do. You might even forget why you needed to go into the room in the first place.
  When I start the compile all the major time demanding

tasks that are necessary to create the software fix have already been
done, and I certainly don't need a sub-second response from compiler.
 Though I observed a certain behavior of programmers who use tools with
a fast response time. Since it doesn't cost anything they just make a
single change and compile to see whether it works, and, rinse repeat,
do that for every _single_ change *multiple* times.

Well, what's wrong with that? It's how lots of things already work, by doing things incrementally.
If recompiling an entire program of any size really was instant, would you still work exactly the same way?
People find scripting languages productive, partly because there is no discrete build step.

My own programming
habits got also somewhat influenced by that, though I still try to fix
things in brain before I ask the compiler what it thinks of my change.
This is certainly influenced by the mainframe days where I designed my
algorithms on paper, punched my program on a stack of punch cards, and
examined and fixed the errors all at once.

I also remember using punched cards at college. But generally it was using an interactive terminal. Compiling and linking were still big deals when using mini- and mainframe computers.
Oddly, it was only using tiny, underpowered microprocessor systems, that I realised how fast language tools really could be. At least the ones I wrote.
Those ported from bigger computers would take minutes for the simplest program, as I later found. Mine took seconds or fraction of a second. Part of that was down to using a resident compile/IDE that kept things in memory as much as possible, since floppy disks were slow.
Here's a test: how many times can you twiddle your thumbs while waiting for something to build? (That is, put your hands together with interlocked fingers, and rotate your thumbs around each other).
I can only manage 3-4 - if building an artificial 1Mloc benchmark. Otherwise it's impossible to even put my hands together.
In 7 seconds I can do nearly 25 twiddles. That's a really useful use of my time!