Re: Is Programming Obsolete?

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Mon, 8 Apr 2024 13:31:33 -0000 (UTC), Rich wrote:
 

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>
That is inherent in the nature of the problem it is trying to solve:
automate an interface--the GUI--which was never designed for automatic
operation. No matter how you slice and dice it, that kind of thing
inherently turns out to be fiddly and fragile.

 
But that part wasn't the problem.  AutoHotKey included function calls to
do that, and once one found the function call to perform "step x" that
one wanted, it worked.

 
In my experience, that is very much part of the problem. I have done this
sort of thing in the past--thankfully, not lately.

Yes, that can be problematic.

E.g. bring up a dialog box to enter a number. I have a template for the
event sequence, to do the initial menu selection, then have my code insert
the (variable) sequence of keystrokes for the number, then end with the
sequence for clicking the OK button.
 
Only if you do it a little too fast, the text field or the OK button might
not actually be enabled yet, and so some part of the sequence gets ignored
and the whole thing goes badly wrong. So you stick in a tenth-of-a-second
delay somewhere, entirely through trial-and-error, until it seems to work.

None of which is AutoHotKey's fault.  All of which is directly caused
by the GUI not ever having been intended to ever be automated in any
way.

Then later on somebody reports that it sometimes fails in a different
place. But of course it works for you. So you then have to try the
sequence multiple times, until you see it fail that one time, and then you
have to figure out why and come up with another tweak to the sequence to
fix it.
 
All this take programming skills--which ordinary users don’t have.

Yup.  My complaint, however, was with the syntax irregularities of
the AutoHotKey script language.  The actual language syntax looks like
it was designed by a group of drunken monkey's after a night of bar
hopping, with an LSD trip added at the end for good measure.  No two
functions used similar calling conventions, and for those that required
some of the same parameters it looked like the language designer
intentionally randomized the order of the parameters for each function
call. 

So who are these macro-recorder thingies aimed at?

I suspect their aim might be twofold:

1) folks who want to use it to change keystrokes (i.e., make their
keyboard be Dovrak but their OS does not have a Dovrak layout); or

2) folks who literally just want to "record" a macro sequence, without
any conditionals and no error checking of any form.

The actual rest that provides a seemingly Turing complete language
looks to have been randomly bolted on using parts from plural
different bodies.  It felt like a language that took the worst parts of
Perl, Javascript, Java, Python, C, COBOL, Ada, etc. and combined it all
into a new ugly monster.

They seem designed to pretend that there is no programming involved
in using them, but on the other hand it can take a lot of work to use
them reliably.  And so you end up with the worst of both worlds.

That indeed.  Maybe their 'recording' part inserts delays equal to what
time it took the user to move/click through things, which would, for
the most part, create an appearance of working most of the time.