@futurebird

I’ve taught programming like this, but I’m an increasingly huge fan of the debugging-first approach that a few people have been trying more recently. In this model, you don’t teach people to write code first, you teach them to fix code first.

I’ve seen a bunch of variations of this. If you have some kind of IDE (Smalltalk is beautiful for this, but other languages usually have the minimum requirements) then you can start with some working code and have them single-step through it and inspect variables to see if the behaviour reflects their intuition. Then you can give them nearly correct code and have them use that tool to fix the issues.

Only once they’re comfortable with that do you have them start writing code.

Otherwise it’s like teaching them to write an essay without first teaching them how to erase and redraft. If you teach people to get stuck before teaching them how to unstick themselves, it’s not surprising that they stop and give up at that point.

@0xabad1dea Is that like the ‘feels like’ temperature?

@NebulaTide

This doesn't bother me too much. Ideally the program should hide the buttons if it can't find a brightnessctl to execute (and probably should fix the search path, because there may be privilege escalation attacks if you can make a login manager run a program that you can control before it drops privileges). A FreeBSD port can provide this program (which probably can just be a shell script that reads / sets a sysctl).

At least this has a form of abstraction layer, in that it delegates to another program to provide the OS-specific functionality. It would be much worse if it just used the Linux kernel APIs to do it.