Is Programming Obsolete?
========================
Brian Harvey
University of California, Berkeley

My topic, the role of programming in computer-using education, is the
intersection of two broader topics: the role of programming in
computer use generally, and the goals and objectives behind the use
of computers in education.

The first personal computers came with a BASIC interpreter, and with
little or no other software. Of necessity, anyone who wanted to use a
computer programmed it. The question for educators was not "Should
students program the computer or use it in some other way," but
rather, "Should we spend the money on computers for the students to
program?" When computers were brought into schools, the typical
result is that some kids were deeply engaged in programming them,
while others ignored them.

Soon teachers and others began to develop computer programs intended
to teach specific lessons. These programs ranged from drill and
practice to simulations. The early programs were narrowly focused;
each program taught one lesson. This was the context in which Logo
became famous when its developers argued for preferring programming
as a student activity over the use of drill programs and the like, on
the grounds that programming engages the mind in mathematical
activity; students who program in Logo would do mathematics, rather
than merely learn about it.

Today the situation is very different. The Macintosh was the first
personal computer to be sold without a programming language at all;
instead the first Macs came with a word processor and a painting
program. Software has become a giant industry, with many choices
available in all categories. People expect to use computers without
programming them; programming is seen as a task for experts.

Another factor in the changing view of programming is the increasing
complexity and sophistication of user interfaces. Commercial software
has a professional "look and feel" that the old homebrew BASIC
programs can't match. Kids expect arcade-quality animation and a
graphical user interface. The programs that they can write themselves
don't meet that standard.

These are the roots of the current conventional wisdom that
programming, as an activity for students, is obsolete.

But It's Not!

1. People want to program.
==========================
If you ask most computer users, they'll tell you that they don't want
to program. The word "programming" has come to connote something
horribly complicated, beyond the ability of most people. But the
people who say they don't want to program are wrong. The proof is
that they buy "macro" languages, such as QuickKeys. These are
abysmally poor programming languages, in which the notation is based
on keystrokes and mouse clicks rather than on the desired program
functions, and yet people put up with their awfulness because they
are so desperate to program their computers! They don't express their
desperation in those terms; they say that they merely want the
computer to carry out their tasks, which aren't exactly the ones
built into the commercial software. But teaching a computer to carry
out a desired task is precisely what "programming" really means.

Macro languages are awkward because they are retrofitted into a
system designed to prevent programming. In recent years, the computer
system designers have begun to recognize users' passionate desire to
program, and have developed programming languages that are better
integrated with their overall systems. The first example was
Hypertalk, the programming language within the Hypercard application
program. Unfortunately, Apple was so terrified that their customers
would be scared away by the phrase "programming language" that they
made two bad mistakes with Hypertalk. The first, which I find very
revealing, was that in the first release of Hypercard the programming
language was hidden. Users had to take the trouble to declare
themselves expert before they could even look at, let alone write,
Hypertalk programs. The second mistake was to think that the way to
make a language easy for beginners is to make it "English-like." This
is the same mistake that led to the design of COBOL a generation ago,
one more illustration of the old saw about repeating the mistakes of
history.

Still, Hypercard was a big success, precisely because it acknowledged
the desire of users to program their computers. In the world of
education, we've seen a new flowering of educational Hypercard
programs written by teachers and students, similar to the earlier
explosions of educational programming in BASIC and in Logo. And
better languages have followed; Apple has finally introduced Apple
Events, which makes most Macintosh software extensible, and Microsoft
has introduced Visual BASIC to make the PC programmable by its users.
Word processing programs such as Microsoft Word have added extension
languages, and so have spreadsheet and database programs. But many of
these ad hoc languages, such as DBASE for database programming, are
badly designed and lack essential capabilities.

2. Learning isn't just curriculum.
==================================
Everyone likes to quote the remark that "education is what's left
after you forget everything you learned," but we sometimes evaluate
educational computing plans as if that weren't true, as if what's
important were the specific facts. Schools spend fortunes on enormous
catalogs of programs, each of which imparts one lesson. But the best,
most enduring examples of educational software are the ones that
allow students to create the lesson themselves -- in other words, the
ones in which the learner programs the computer.

This doesn't have to mean that the student works in a general-purpose
programming language. Some of the best educational software consists
of special-purpose languages, such as Geometric Supposer and its
descendents like Geometer's Sketchpad. The design of special-purpose
programming languages for educational use has a long history. One
very early, well known example is Rocky's Boots, a (visual!)
programming language for propositional logic. The IBM "Writing to
Read" package, while not really a programming language, follows a
similar approach, in that the learner is encouraged to create
something -- in this case, an English text -- rather than merely to
take in knowledge and regurgitate it on demand. In all of these
cases, learning to program isn't the goal; the goal is to learn
geometry, or logic, or reading skills. But programming isn't a
distraction! It helps in the learning, and it helps make the learning
endure for the student.

3. Learner-centered computing.
==============================
Here are two examples, at different age levels, of using computer
programming to teach other subjects in a learner-centered way.

The first is an investigation into English grammar, suitable for
upper elementary grades. Instead of learning abstract definitions for
the parts of speech ("A noun is a person, place, or thing" and so
on), students can discover for themselves which words fit into what
roles in a sentence, by constructing a sentence-generation program in
Logo. (This activity is inspired by _Exploring Languge with Logo_ by
E. Paul Goldenberg and Wallace Feurzeig.)

to sent
output (sentence nounphrase verbphrase)
end

to nounphrase
output (sentence "the adjective noun)
end

to verbphrase
output (sentence verb nounphrase)
end

to noun
output pick [girl boy elephant zebra giraffe clown]
end

to adjective
output pick [big happy little funny silly]
end

to verb
output pick [hugs punches likes visits]
end

? print sent
THE FUNNY CLOWN HUGS THE HAPPY ZEBRA

? print sent
THE LITTLE GIRAFFE PUNCHES THE SILLY BOY

(This program would not be presented to students by the teacher.
Rather, the students would build up to it themselves. Perhaps the
teacher would present a much simpler program, for example, one that
generates sentences such as FRED RUNS or SUSAN SMILES. This is an
open-ended project; the program can be extended to generate many
different sentence structures.)

The second example is for college undergraduates learning abstract
algebra. These procedures are written in ISETL, a language designed
specifically to resemble formal mathematical notation. They come from
an algebra course taught by Uri Leron. The procedures model the
definition of a group, a mathematical structure made up of a set S
and an operation o that satisfy certain requirements. Those
requirements are tested by the procedures:

is_closed := func(S,o);
return
forall a,b in S |
a .o b in S;
end;

is_associative := func(S,o);
return
forall a,b,c in S |
(a .o b) .o c = a .o (b .o c);
end;

has_identity := func(S,o);
return
exists e in S |
(forall a in S | e .o a = a);
end;

identity := func(S,o);
return
choose e in S |
(forall a in S | e .o a = a);
end;

has_inverses := func(S,o);
local e; e := identity(S,o);
return
is_defined(e) and
forall a in S |
(exists a' in S | a' .o a = e);
end;

Ben Collver <bencollver@tilde.pink> wrote or quoted:
>Is Programming Obsolete?

When I laid eyes on that title "Is Programming Obsolete?", I
figured the article was gonna be all about how these newfangled
AI systems are gonna be taking over the job of writing code
before long. You know, they'll be able to understand what we're
asking for in plain English and then whip up the program we
need or tweak an existing one, so us old coots won't have to be
messing around with all that programming mumbo-jumbo anymore.

Yep, the way I see it, those AI gizmos are gonna be putting
us programmers out to pasture before too long. We'll be
as obsolete as a rotary phone, mark my words. These young
whippersnappers these days, they won't even know what it's
like to have to painstakingly write out line after line of code
just to get a simple task done. Nope, they'll just be barking
orders at their AI assistants and watching the magic happen.
Heck, they probably won't even know how to use a punch card!

Ah, but don't you worry. Us old-timers, we'll still be hanging
around, spinning our war stories about the good old days
when we had to use our noggins to solve problems. We'll be
like the last of a dying breed, clinging to our FORTRAN and
COBOL like a security blanket. Just you wait and see!

Ben Collver <bencollver@tilde.pink> wrote:
> But the people who say they don't want to program are wrong. The
> proof is that they buy "macro" languages, such as QuickKeys. These
> are abysmally poor programming languages,

Indeed, they are. Made use of "AutoHotKey" some years back at $job to
automate a custom GUI program for a repetitive task mgmt. wanted done, but
naturally the GUI program authors had never provided any ability to
perform.

AutoHotKey is the most absymal "programming" languge, maybe second only
to Brainfuck [1]. If there was, ever, any 'design' to the language, it
was either "designed" to be a massive screwup, or it was "designed" by
15 rabid hyenas who built only one piece and intentionally went their
own way with how to build that piece. Not one built in function was
similar in any way to any other built in function. Parameter orders
differed for every one (even when groups of them took the same initial
set of parameters), and IIRC some required double quotes for delimiting
strings, but others required single quotes as string delimiters. Some
names where snake case (move_window) while others were camel cased
(DeleteWindow) with seeming no rhyme or reason why.

I managed to accomplish the 'automation' task, but AutoHotKey the
language was a constant source of bad juju in getting to that end
state.

[1] https://en.wikipedia.org/wiki/Brain_Fuck (and if one is attempting
to program in Brainfuck, the very name should indicate one is in for a
rought time).

Rich <rich@example.invalid> wrote or quoted:
>AutoHotKey is the most absymal "programming" languge

Yet, AHK the best tool for some jobs!

When you want to write a program to print the numbers
from 0 to 9, nothing is more awkward than to write it
in TeX. Yet, TeX, too, is the best tool for some jobs!

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Rich <rich@example.invalid> wrote or quoted:
>>AutoHotKey is the most absymal "programming" languge
>Yet, AHK the best tool for some jobs!

(usually "AutoHotkey")

|There are only two kinds of languages:
|the ones people complain about and the ones nobody uses.
- Bjarne Stroustrup

Ben Collver <bencollver@tilde.pink> wrote or quoted:
>complexity and sophistication of user interfaces. Commercial software
>has a professional "look and feel" that the old homebrew BASIC
>programs can't match. Kids expect arcade-quality animation and a
>graphical user interface. The programs that they can write themselves
>don't meet that standard.

With Python and tkinter, GUIs actually are easy to write:

import tkinter

tkinter.Label( text="Hi! What's your name?" ).pack()
entry=tkinter.Entry()
entry.pack()
button = tkinter.Button( text="Ok" )
def ok(): tkinter.Label( text="Hi, " + entry.get() + "!" ).pack()
button.pack()
button.config( command=ok )
tkinter.mainloop()

.

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Rich <rich@example.invalid> wrote or quoted:
>>AutoHotKey is the most absymal "programming" languge
>Yet, AHK the best tool for some jobs!

By chance, read this on the Web:

|Python wrapper for AutoHotkey with full type support. Harness
|the automation power of AutoHotkey with the beauty of Python.

>When you want to write a program to print the numbers
>from 0 to 9, nothing is more awkward than to write it
>in TeX. Yet, TeX, too, is the best tool for some jobs!

... and today, TeX has Lua ("LuaTeX")!

Rich <rich@example.invalid> wrote at 16:51 this Sunday (GMT):
> Ben Collver <bencollver@tilde.pink> wrote:
>> But the people who say they don't want to program are wrong. The
>> proof is that they buy "macro" languages, such as QuickKeys. These
>> are abysmally poor programming languages,
>
> Indeed, they are. Made use of "AutoHotKey" some years back at $job to
> automate a custom GUI program for a repetitive task mgmt. wanted done, but
> naturally the GUI program authors had never provided any ability to
> perform.
>
> AutoHotKey is the most absymal "programming" languge, maybe second only
> to Brainfuck [1]. If there was, ever, any 'design' to the language, it
> was either "designed" to be a massive screwup, or it was "designed" by
> 15 rabid hyenas who built only one piece and intentionally went their
> own way with how to build that piece. Not one built in function was
> similar in any way to any other built in function. Parameter orders
> differed for every one (even when groups of them took the same initial
> set of parameters), and IIRC some required double quotes for delimiting
> strings, but others required single quotes as string delimiters. Some
> names where snake case (move_window) while others were camel cased
> (DeleteWindow) with seeming no rhyme or reason why.
>
> I managed to accomplish the 'automation' task, but AutoHotKey the
> language was a constant source of bad juju in getting to that end
> state.
>
>
> [1] https://en.wikipedia.org/wiki/Brain_Fuck (and if one is attempting
> to program in Brainfuck, the very name should indicate one is in for a
> rought time).

For /very simple things/, AHK is usable.
--
user <candycane> is generated from /dev/urandom

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>import tkinter

>tkinter.Label( text="Hi! What's your name?" ).pack()
>entry=tkinter.Entry()
>entry.pack()
>button = tkinter.Button( text="Ok" )
>def ok(): tkinter.Label( text="Hi, " + entry.get() + "!" ).pack()
>button.pack()
>button.config( command=ok )
>tkinter.mainloop()

It can be rewritten to look a bit smaller and nicer:

from tkinter import *

Label( text="Hi! What's your name?" ).pack()
entry = Entry(); entry.pack()
def ok(): Label( text="Hi, " + entry.get() + "!" ).pack()
Button( text="Ok", command=ok ).pack()
mainloop()

Now let me ask the Chatbot!

|Chatbot, please write a tiny tkinter program to ask the user
|for his name and then greet him using his name.

Answer (The rest of my post is what the Chatbot answered):

|## Tiny Tkinter Program to Greet the User
| |Here's a simple Tkinter program that asks the user for their
|name and then greets them:
| |python
|import tkinter as tk
| |def greet():
| name = name_entry.get()
| greeting_label.config(text=f"Hello, {name}!")
| |root = tk.Tk()
|root.title("Greeting App")
| |name_label = tk.Label(root, text="What's your name?")
|name_label.pack()
| |name_entry = tk.Entry(root)
|name_entry.pack()
| |greet_button = tk.Button(root, text="Greet Me", command=greet)
|greet_button.pack()
| |greeting_label = tk.Label(root, text="")
|greeting_label.pack()
| |root.mainloop()
| |Here's how the program works:
| |1. The `greet()` function is defined, which retrieves the
|user's name from the `name_entry` widget and updates the
|`greeting_label` with a personalized greeting.
| |2. The main Tkinter window is created with the title "Greeting
|App".
| |3. A label is added to prompt the user for their name.
| |4. An entry widget is added to allow the user to input their
|name.
| |5. A button is added with the text "Greet Me", which calls the
|`greet()` function when clicked.
| |6. A label is added to display the greeting.
| |7. The `mainloop()` function is called to start the Tkinter
|event loop and display the application.
| |When the user enters their name and clicks the "Greet Me"
|button, the program will display a personalized greeting.

On Sun, 7 Apr 2024 15:22:13 -0000 (UTC), Ben Collver wrote:

> The best software combines a graphical user
> interface with a powerful extension language.

No, the best software builds its graphical user interface *on top* of a
powerful “extension language”.

The reason for layering things this way is that trying to program your
extensions by operating through the GUI inevitably turns into an exercise
in frustration (example: Microsoft VBA). Far better to bypass the GUI to
access the programmable abstractions underneath. If you can build your own
GUI extensions on top of that, so much the better.

Example: Blender 3D, with its powerful Python API, probably the most
comprehensive of any content-creation app. Essentially, every part of the
contents of a Blender document can be accessed and manipulation as Python
objects. In the web-developer world, we have the “DOM” concept (“Document
Object Model”); exactly the same principle applies here.

Other open-source content-creation apps also use or offer Python as their
API language: Inkscape, GIMP, LibreOffice.

And then there is Emacs, not only written (largely) in Elisp, but also
extensible in Elisp.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Other open-source content-creation apps also use or offer Python as their
> API language: Inkscape, GIMP, LibreOffice.

LibreOffice also has its own BASIC:
https://en.wikipedia.org/wiki/OpenOffice_Basic

I found it had too many functions that didn't work like they
said on the label.

--
__ __
#_ < |\| |< _#

On Sun, 7 Apr 2024 16:51:22 -0000 (UTC), Rich wrote:

> AutoHotKey is the most absymal "programming" languge ...

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.

In Comp Sci, we learn early on about the concept of “abstract machines”
layered on top of each other, starting with the bare hardware, which is
the most general kind of machine, and specializing it more and more in the
upper layers until we get something suited to the set of problems we are
trying to solve.

That process stops when you get to the GUI: that is designed for operation
by humans, not to have anything else layered on top of it.

On Sun, 7 Apr 2024 17:50:03 -0000 (UTC), candycanearter07 wrote:

> For /very simple things/, AHK is usable.

For /very simple things/, AutoHotKey seems pointless. The whole point of
using such a tool is to automate tasks too complex for the human operator.

On 2024-04-07, Rich <rich@example.invalid> wrote:
> Indeed, they are. Made use of "AutoHotKey" some years back at $job to
> automate a custom GUI program for a repetitive task mgmt. wanted done, but
> naturally the GUI program authors had never provided any ability to
> perform.

I feel for you! I used to support a number of non-trivial AHK
automations. Unclean!

More recently i discovered xdotool and wrote scripts to produce
music videos out of MOD scene music using VirtualBox, various
MOD trackers and players, ProjectM, and ffmpeg. It was fragile
and worked just well enough to work at all, reminding me a lot
of AHK.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:00 this Monday (GMT):
> On Sun, 7 Apr 2024 16:51:22 -0000 (UTC), Rich wrote:
>
>> AutoHotKey is the most absymal "programming" languge ...
>
> 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.
>
> In Comp Sci, we learn early on about the concept of “abstract machines”
> layered on top of each other, starting with the bare hardware, which is
> the most general kind of machine, and specializing it more and more in the
> upper layers until we get something suited to the set of problems we are
> trying to solve.
>
> That process stops when you get to the GUI: that is designed for operation
> by humans, not to have anything else layered on top of it.

The problem happens when there's no way to access the underlying
functions, or it requires bad workarounds like the GUI scripting.
--
user <candycane> is generated from /dev/urandom

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:01 this Monday (GMT):
> On Sun, 7 Apr 2024 17:50:03 -0000 (UTC), candycanearter07 wrote:
>
>> For /very simple things/, AHK is usable.
>
> For /very simple things/, AutoHotKey seems pointless. The whole point of
> using such a tool is to automate tasks too complex for the human operator.

I always saw it as a macro language, like something to quickly run an
action with a button press.
--
user <candycane> is generated from /dev/urandom

On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:

> The problem happens when there's no way to access the underlying
> functions, or it requires bad workarounds like the GUI scripting.

That kind of thing seems less common in the Open Source world. Perhaps
because it is more likely to be seen as a bug and fixed.

On Mon, 8 Apr 2024 02:08:01 -0000 (UTC), Ben Collver wrote:

> More recently i discovered xdotool and wrote scripts to produce music
> videos out of MOD scene music using VirtualBox, various MOD trackers and
> players, ProjectM, and ffmpeg.

You’ve got FFmpeg in there, the universal multimedia “sonic screwdriver”,
that should already be able to do nearly all the necessary conversions/
encoding.

I looked up projectm, and it seems to be some kind of OpenGL-based
visualizer, that comes as a library anyway, so you shouldn’t need to
struggle with operating it via some GUI’s puppet strings.

Similar thing for MOD files: I see that modplug is available as a library,
too. And it’s available as a build option for FFmpeg.

On Mon, 8 Apr 2024 03:20:03 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:01 this Monday (GMT):
>
>> On Sun, 7 Apr 2024 17:50:03 -0000 (UTC), candycanearter07 wrote:
>>
>>> For /very simple things/, AHK is usable.
>>
>> For /very simple things/, AutoHotKey seems pointless. The whole point
>> of using such a tool is to automate tasks too complex for the human
>> operator.
>
> I always saw it as a macro language, like something to quickly run an
> action with a button press.

If that’s a simple action, then the GUI should already have it.

If it’s a complex action ... my condolences on having to struggle with any
keystroke/macro recorder.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 7 Apr 2024 16:51:22 -0000 (UTC), Rich wrote:
>
>> AutoHotKey is the most absymal "programming" languge ...
>
> 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.

The absymal part was the actual AuthHotKey script language itself. It
looked to have been created by ten different people, at ten different
points in time, all of which decided to "do something differnt" for the
patch they were adding at the time they were adding it.

Perl gets grief for having too many sigils ($ for scalars % for
key-value maps, etc).

But, imagine a Perl where for "moving a window") the function call was
(and the $, %, ^ and *'s were require below)

move-window-to-x-y( $win, %handle, ^x, *y)

Meanwhile, the function call to resize a window was (and the sigis
below were required, but no commas were allowed):

ResizeWin( @oldw #oldh &win !newwidth ?handle :newheight)

And, note how the "win" variable needs to be dereferenced as $win for
one of the calls, but &win for the other, and the window handle is
%handle for one and ?handle for the other.

This kind of "fun" inconsistency in AutoHotKey's scripting language
makes it an absolute <sarcasm>Joy</sarcasm> to work with.

The manipulating of a GUI was actually the easy part. The abysmal part
was the script language inconsistencies.

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Ben Collver <bencollver@tilde.pink> wrote or quoted:
>>complexity and sophistication of user interfaces. Commercial software
>>has a professional "look and feel" that the old homebrew BASIC
>>programs can't match. Kids expect arcade-quality animation and a
>>graphical user interface. The programs that they can write themselves
>>don't meet that standard.
>
> With Python and tkinter, GUIs actually are easy to write:
>
> import tkinter
>
> tkinter.Label( text="Hi! What's your name?" ).pack()
> entry=tkinter.Entry()
> entry.pack()
> button = tkinter.Button( text="Ok" )
> def ok(): tkinter.Label( text="Hi, " + entry.get() + "!" ).pack()
> button.pack()
> button.config( command=ok )
> tkinter.mainloop()

Writing it in it's native Tcl will avoid the Python "wrappings" for
accessing the Tk widgets:

#!/usr/bin/wish
pack [label .label -text "Hi! What's your name?"]
pack [entry .entry]
pack [button .button -text "Ok" -command ok]
proc ok {} {
pack [label .label[incr ::seq] -text "Hi, [.entry get]!"]
}

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday (GMT):
> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>
>> The problem happens when there's no way to access the underlying
>> functions, or it requires bad workarounds like the GUI scripting.
>
> That kind of thing seems less common in the Open Source world. Perhaps
> because it is more likely to be seen as a bug and fixed.

Of course, the opposite is usually more true. A lot of stuff is
terminal-only.
--
user <candycane> is generated from /dev/urandom

On 2024-04-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> You’ve got FFmpeg in there, the universal multimedia “sonic screwdriver”,
> that should already be able to do nearly all the necessary conversions/
> encoding.

I wanted to produce a video showing the tracker interface as it scrolled
through the score while playing the song, using the same tracker that
was used to compose the song. My first attempt was using FastTrackerII.

My problem was that VirtualBox advertised SoundBlaster emulation, but it
doesn't work at all in DOS. Analysis from others leads me to believe
that it is VirtualBox's fault. I tried running FT2 and others in DOSBox
but the performance was so slow that it caused audio skipping. So what
i ended up doing was using xdotool and VBoxManage to coordinate the
tracker playback, capturing video with ffmpeg, and then muxing in the
audio track produced previously by the tracker's disk dump feature. I
may have had to trim the audio track with sox before i got it to sync.

I'm done playing that game, so i don't really have anything to prove.
But feel free to have a go at it!

On Mon, 8 Apr 2024 14:30:06 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:49 this Monday (GMT):
>
>> On Mon, 8 Apr 2024 03:20:02 -0000 (UTC), candycanearter07 wrote:
>>
>>> The problem happens when there's no way to access the underlying
>>> functions, or it requires bad workarounds like the GUI scripting.
>>
>> That kind of thing seems less common in the Open Source world. Perhaps
>> because it is more likely to be seen as a bug and fixed.
>
> Of course, the opposite is usually more true. A lot of stuff is
> terminal-only.

Feel free to offer examples.

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.

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.

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. So who
are these macro-recorder thingies aimed at? 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.