We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major change after the second year.
This transiency of our work as programmers is something I am yet to come to terms with. I can't recollect where, but there was an interesting consolation in that while the code might be transient, the value created was real, and that's what matters. But the code is an artifact of our waking hours; it matters, like memories matter.
I would still love to go back to the ergonomics of building user interfaces in DOS. No mouse, no events, no callbacks - just straight imperative programming where everything, including user input, blocks. Nothing async - even network communication was thru Novell Netware file writes, using shared locks. And a single screen to design: 25 rows and 80 columns, and just 16 colors.
After doing GUI work for many years after DOS, thru VB6, jQuery DOM manipulation, Angular etc., ReasonReact and Hooks are the closest I've come to recapturing the ease of building UIs again. I'm also looking forward to trying out concur one of these days (https://github.com/ajnsit/concur-documentation/blob/master/R...) -- it is a Haskell GUI library that lets you do evented handling in an imperative-looking manner.
I also used CA-Clipper, Summer '87 and the OOP variants 5.x.
Most of the stuff did use a mouse and some TUI navigation, with menus and stuff, we had a couple of libraries for it.
Now doing those forms it was pretty neat.
As for building TUIs not really, other than the usual Clipper entry forms.
For example, when I moved from Turbo Vision (MS-DOS) into Object Windows Library (Turbo Pascal for Windows 1.5) I did not regret it.
One thing I do conceed, a full keyboard experience is much better for data entry forms and on GUIs the mouse is given too much focus, although the same approach could be easily implemented as on TUIs.
- I reported 5 bugs, and they were all ignored, so I'm not going to report any more now. It'd just be a waste of my time.
- I reported a bug, and in the process of fixing that, the developer broke something else even worse. (In one case, it turned a "delete some" button into a "delete all" button which caused a minor catastrophe for all users.) Now I want the developer to not touch anything. I know what little bugs exist in the system, and I've come up with my own ways to work around them, thank you very much.
- As a consequence of some other bug fix, it came to light that the developer has no backups. (I don't have sufficient pull to fix that underlying problem.) I want the developer to not touch anything.
- The users aren't the buyers, and it's easy for the buyers to know where to report bugs, but that information is hidden from the users. As a result, all of the bugs that cropped up during demos (for or by C-level execs and VPs) are fixed, but nothing beyond that.
- We brought on new users, and they don't know that the software is custom built (2 months ago!), so they don't know it's possible to file bug reports. Or they don't know where to report them. Or they're afraid it's going to be onerous. Whatever the reason, they think this program has always been around and can't be changed.
- Maybe the process really is onerous. One company has gotten increasingly naggy about all bug reports including a 1/2GB blob of logs and other PII that takes several minutes to generate. Even when I just want to report "there's no way to do X, and there should be a way to do X", I get nagged 3 or 4 times to include this diagnostic blob, and it's implied that my bug won't get much attention without one. I only rarely report bugs to that company these days.
- Since the early days of a popular website, the keyboard shortcuts were supremely annoying. In the interests of being supportive of that great new venture, I only reported issues which caused the system to be completely unusable. Later, when the major issues had been ironed out and people did report that stealing and remapping all the standard OS text editing keys was maybe not the nicest thing to do, we were told the system was 3 years old already and by now someone else "would surely complain if it was an annoying problem".
In other words, everyone from users to developers comes to depend on the status quo. The softness of software is a benefit during initial development, but mostly just a liability later. We value the status quo even more than quality.