Hacker News new | past | comments | ask | show | jobs | submit login

I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though!

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.




You were still deploying a DOS application in 2004 ? Do you mind telling us more about the reasons why ?


That was the only programming environment (CA-Clipper) I knew at the time. VB6 was a thing, but I had some GUI-antipathy, coming from the older, "purer?" world of DOS. Also POS terminals needed first-class keyboard accessibility. SQL wasn't welcome either - you had to give up the fine grained control of row-level cursors in the flat-file xBase database and use a rather unwieldy looking language.

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.


Well, if you would be using Turbo Vision, then there was mouse, callbacks, events, the whole stuff. And async would just be a couple of chained interrupts.

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.


I had a pascal turbo vision accounts app. The client decided to share the data between two machines over a 10baseT network. With the exception of an occasional, but fully recoverable write issue (the user just had to retry their last save operation), I didn't have to lift a finger to get it past y2k. Mouse, printer (serial and parallel) were no problems. Good times.


Good times indeed!


Yeah I used to look longingly at Turbo Vision GUIs, but C++ was scary at the time. Do you think building TUIs with TV was qualitatively better than approaches popular today? Any insights why?


I used Turbo Pascal's variant of Turbo Vision.

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.


Nice to hear that!


Having been on both ends of this (developer and user), I've seen all kinds of reasons that bug reports drop off, after the first couple years, that have nothing to do with software quality improving. A few actual examples I've seen:

- 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.


It’s like a plumber or a home builder. You only go back if something isn’t right.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: