Re: else ladders practice

On 28.11.2024 19:25, Bart wrote:

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 is. (It was with flickering fluorescent lamps in the past and is
with the contemporary energy saving lamps nowadays that need time to
radiate in full glory.) - But I'm not making comparisons/parables;
I made a concrete argument and coupled it with behavioral patterns
and work processes in the context we were speaking about, compiling.

 
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.

There's nothing "wrong" with it. (I just consider it non-ergonomic
in the edit-compile-loop context I described.) You can (and should)
do what you prefer and what works for you - unless you work and
operate in a larger project context where efficient processes may
(or may not) conflict with your habits.

 
If recompiling an entire program of any size really was instant, would
you still work exactly the same way?

(I addressed that in my previous post.)

 
People find scripting languages productive, partly because there is no
discrete build step.

(There are many reasons for using scripting languages; at least for
those that I use. And there are reasons to not use them.)

And there's reasons for using compiled and strongly typed languages.
One I already mentioned in my previous post; you see all errors at
once and can fix them in one iteration. - I seem to recall that you
are somewhat familiar with Algol 68; its error messages fosters an
efficient error correction process.

The point was and still is that it's inefficient to save seconds in
compiling and spend much more time in your edit-compile iterations.

The rest can be re-read if you missed that I wrote "I understand"
your edit-compile habits as an effect of being used to instant
responsive compilers [for the sort of code you are doing, in the
project context you are working, with the software organization
you have, and the development processes you apply].

 

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.

I have (and also heard of) different experiences. (Like hitting the
Enter key on an interactive terminal to start a job and instantly
getting the prompt back.) Myself I worked with punch cards only on
mechanical punch terminals and then put the stack of cards in a
batch queue that got processed (with other jobs) at occasion; the
build times, compiles/links, were not an issue anyway with those
mainframes (TR, CDC, 360-clone). When we switched to interactive
(non-mainframe) systems the processes got slower, much more time
consuming.

 
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.

Sure.

Janis

[...]