Ellen Ullman: “The Dumbing Down Of Programming”
Found this two-part article from Salon magazine of 1998 <https://www.salon.com/1998/05/12/feature_321/>, <https://www.salon.com/1998/05/13/feature_320/>. Choice quotes: My intention had been to buy an upgrade to Windows NT Server, which was a completely sensible thing for me to be doing. ... But somehow I left the store carrying a box of Linux from a company called Slackware. ... In six clicks of a wizard, the Microsoft C++ AppWizard steps me through the creation of an application skeleton. ... Of course, I could look at the code that the Wizard has generated. ... But everything in the environment urges me not to. ... In this programming world, the writing of my code has moved away from being the central task to become a set of appendages to the entire Microsoft system structure. I'm a scrivener here, a filler-in of forms, a setter of properties. ... I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things. ... In an ideal world, I would not have to choose between the extreme polarities of dialog box and source code. My dream system interface would allow me to start hesitantly, unschooled. Then, as I used the facility that distinguishes me from the machine -- the still-mysterious capacity to learn, the ability to do something the second time in a way quite different from the first -- I could descend a level to a smarter, quicker kind of "talk." I would want the interface to scale with me, to follow me as my interest deepened or waned.
What's your opinion on that Lawrence? I was thinking about this when I added a #'kbd-macro-query #'read-from-minibuffer interaction to a C-c <capital> keyboard macro for an orgmode-slime interaction I was writing. I guess you have an opinion on that. I mean it's trivial to tack these in in elisp interactively and more or less has been since the 80s (70s?), and I guess it's this that Helper Wizards on Windows-like products emphasise. But you rarely actually use these in practice because they are only simple sofaras they are overly specific, and "stubbing" saves a total of zero minutes... I guess that author was talking about 80s-style GUI helper utilities (I guess we could call them Modern Utilities). On 12/22/22, Lawrence D'Oliveiro <ldo(a)geek-central.gen.nz> wrote:
Found this two-part article from Salon magazine of 1998 <https://www.salon.com/1998/05/12/feature_321/>, <https://www.salon.com/1998/05/13/feature_320/>. Choice quotes:
My intention had been to buy an upgrade to Windows NT Server, which was a completely sensible thing for me to be doing. ... But somehow I left the store carrying a box of Linux from a company called Slackware.
...
In six clicks of a wizard, the Microsoft C++ AppWizard steps me through the creation of an application skeleton. ... Of course, I could look at the code that the Wizard has generated. ... But everything in the environment urges me not to. ... In this programming world, the writing of my code has moved away from being the central task to become a set of appendages to the entire Microsoft system structure. I'm a scrivener here, a filler-in of forms, a setter of properties.
...
I once worked on a project in which a software product originally written for UNIX was being redesigned and implemented on Windows NT. Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things.
...
In an ideal world, I would not have to choose between the extreme polarities of dialog box and source code. My dream system interface would allow me to start hesitantly, unschooled. Then, as I used the facility that distinguishes me from the machine -- the still-mysterious capacity to learn, the ability to do something the second time in a way quite different from the first -- I could descend a level to a smarter, quicker kind of "talk." I would want the interface to scale with me, to follow me as my interest deepened or waned. _______________________________________________ wlug mailing list -- wlug(a)list.waikato.ac.nz | To unsubscribe send an email to wlug-leave(a)list.waikato.ac.nz Unsubscribe: https://list.waikato.ac.nz/postorius/lists/wlug.list.waikato.ac.nz
On Sat, 24 Dec 2022 12:36:39 +1300, Jake Waas wrote:
... I guess that author was talking about 80s-style GUI helper utilities ...
GUI builder tools go back to Interface Builder on NeXTSTEP, and likely even before. They all do the same sort of thing: generate a whole lot of boilerplate classes, and then you’re supposed to go in and fill in the gaps specific to your application. But this approach always suffers from the same problem: you cannot do any editing to the automatically-generated code, because typically you cannot bring that code back into the GUI editor to make little tweaks there: instead, it has to regenerate it all, wiping out your customizations.
participants (2)
-
Jake Waas -
Lawrence D'Oliveiro