[Tutor] a program which list ALL the errors

[dn]

On 25/10/2020 12:15, Alan Gauld via Tutor wrote:
> On 24/10/2020 23:08, Cameron Simpson wrote:
>> On 18Oct2020 12:34, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
>>> But it must be said that its an unusual strategy.
>>> Most programs detect the first error and stop.
>>
>> And those programmes are user experience disasters. I hate them with a
>> passion.
> 
>> When that logic is buried deep in a subsidiary script, the user is
>> massively annoyed. I submitted a small patch to probe for _all_ the
>> software, complain about each missing comonepnt, and _then_ quit. Really
>> easy and avoids much anger in the end user.
> 
> Interesting. I absolutely hate that behaviour. Some compilers
> do it and its a massive pain finding the first error and fixing
> it then trying to find another, and another,  and then discovering
> that fixing the first actually changed the second! It's much,
> much easier IMHO to fix one thing at a time.
> 
> Of course the program should give useful hints as to what it is
> expecting up front. But not give me a raft of error messages - my poor
> brain can only cope with one at a time! :-0
> 
> "Beauty is in the eye..." I guess.


Re-factoring a routine this morning, I caused pytest to 'light-up like a 
Christmas tree'. (yes, I appreciate that you are surprised - get over 
it!) As it happened, of the dozens of failing-tests, most related to the 
same simple typo. However, I was able to quickly scan and reject the 
second, third, ... of these, as 'solved'; but still pick-up a couple of 
others which were 'different'. If I 'fixed' the first error and then 
pytest-ed again, might this have been faster to reveal the 'other 
errors'? Possibly - would depend upon the time taken to re-test cf that 
required for me to read.
(to restore your (mis-placed) faith in my programming abilities - the 
second test was a complete 'pass')

I think my training/background/in-grained habit leads me to the 'show me 
everything - let me (try to) fix it (all) once' option. I notice that 
younger folk (aren't they all, these days?) have grown-up with faster 
machines and faster turn-around (see next paragraph) and thus have the 
habit of 'throwing code at the machine' to see what transpires. Maybe 
that is the 'beautiful eye' you mention?


Back in the ?good, old days: when it cost 24-hours per "turn-around" - 
punching cards, submitting a source-deck, waiting, inspecting the 
returned print-out on that lovely, striped, lineflow stationery... We 
valued the compiler finding an error, and then attempting to re-start to 
find any further problems. The cost of correcting errors at a rate of 
one per run was horrendous ($ or time). Sure, sometimes the compiler's 
re-start embodied assumptions which led to false-negatives, but...
(I assume this continues with present-day compiled languages)

Same in conversation: if someone comes to me with a 'problem', I prefer 
to hear the 'whole story'; rather than 'solving' the first 'issue' - 
only to find that such solution worsens the third 'issue'!
(aside from politeness, 'proper listening', ... my learning patience...)


That said, I notice that pytest has an option to run a file containing 
multiple tests and to stop on first-error, cf my IDE's control file: set 
to run all the way to 'the bitter end'. So, there are clearly different 
preferences/scenarios!


A new aphorism: "horses for courses"?
-- 
Regards =dn