How much of this article should the successor to s...
# of-end-user-programming
k
How much of this article should the successor to spreadsheets (whether it uses graphics, or gestures, or interpretive dance) nudge people to learn? https://jstrieb.github.io/posts/digit-length
g
hm. my immediate intuition is that the programming environment should let the user manipulate anything that’s integral to the display of information—so, since the environment needs to use concepts like characters, digits, and base 10 numbers to display the number to the user the problem should become relatively trivial
in another sense: the work to determine the number of digits in a number should be being done by the display environment already so the user should be able to hook into that work without redoing it
k
To clarify, by 'this article' I mean not just the problem mentioned but the pedagogical goals mentioned, that the problem is intended to teach.
g
hm. i think i’d stand by my stance in either case: it should be as unintuitive to make testing errors, or to not work from examples at the start as it is to begin a woodworking project by sawing off your hand at the wrist
k
Interesting. Can you clarify "make testing errors"?
g
low coverage, tests that test things that aren’t in the execution path, tests that don’t cover a large proportion of execution paths
k
Interesting, but it seems really draconian. Writing insufficient tests is far more subtle than sawing off your hand, it's like mismeasuring a mitre. Neophytes need to be allowed to make mistakes on little projects many many times as they acquire skills. A key part of bringing something new to people is being forgiving where possible.
The other angle is error quality. It takes taste to write good tests. No tool will capture that sensibility until we get AGI.
g
i’m being intentionally draconian here—i think there’s value in aiming high. i think the taste and forgiveness aspects both should be moved to the ui: it’s a lot easier to notice errors when you have live feedback for example. we definitely share the same goals, though
k
I think we have a pretty fundamental philosophical disagreement. When I encounter an overly draconian tool (which is inevitably wrong some of the time) I consider it stupid and try to route around it as much as possible. "Draconian" doesn't feel "high" to me. "The UI can soften the blow" feels like throwing a hard problem over the wall for someone else to solve. The only way to teach taste is to create a suitable environment and let people find it in their own time. Forcing when people should do the right thing is motivation-sapping.
g
ah i think the ui can actually eliminate the blow. also by draconian i just meant like radical in the political sense, not punitive. to be clear here—i still think our goals are the same: making mistakes shouldn’t be punished. tools should make mistakes either inconsequential or unintuitive
👍 1
the reason i’m not contributing to mu at the moment is that i feel more suited to contributing on the ui side of things so i’d be throwing this task over the wall to myself, i guess
💡 1
i think a lot of programming uis are like video games that make it really easy to run your character off a cliff by accident—you should be able to have a wall climbing mechanic maybe, but the accidental mistake costing you the level really burns. maybe i’m stretching the metaphor here
you should at least have to press a button, you know?