ElliotSmith said:
Summary: In your opinion, which software is the trickiest to program?
In your opinion, what are the most difficult things to program?
"Trickiest" usually refers to the algorithm itself. Complicated algorithms can pop up in unexpected places. Take this example where all that needed to be done was to put print to paper:
It was a word processing system I wrote before there were word processing systems.
This one was actually tied specifically to the publication of military airmen periodicals.
A "signature" is a group of pages that are printed onto one sheet of paper. The paper is then folded multiple times and trimmed so that form a booklet. Then the booklets are bound together to form the whole book.
Some of these publications were hundreds of pages long - and their signatures were groups of 16 or 32 pages.
One requirement was to avoid blank pages and a lot of blank space at the end of each page. Within each page, there multiple columns and within each column there could also be items listed in columns. So you had four levels: signatures, pages, columns, lists - all requiring similar balancing. In each case, paragraphs and pictures could only be broken across different levels according to different rules (photos couldn't broken, paragraphs could only be broken between lines - or not at all - or not on the last line, etc). Moreover, the entire process had to be completed on a Data General Nova with 64Kbytes of main memory and about 20Mbytes of disk space.
To avoid having to handle the large publication file while performing the paragraph balancing, I started by reading through the entire file to create a list of placement instructions. Then I wrote a function that could place paragraphs at any level with or without concern for balancing. Both with and without balancing were recursive functions - the program invoking itself whenever the level dropped from signature to page, page to column, etc. Without balancing was fast and it produced the minimum signature count or page count or the corresponding info for columns and lists. Once the minimum count was established, the next step was to find out how much you could trim from each page without going over that minimum. This was done with a page length binary search - exercised independently at each level of recursion.
On top of this, the entire list could not be held in memory at one time, so the process needed to be stopped, reorganized, and restarted as it progressed.
Soon there will be a whole class of programming jobs that are well beyond the skills of almost all current computer programmers. The first entry in this class is Peter Shor's factoring algorithm - requiring numerical analysis and an understanding of how basic qubit operators can be combined to form useful results. But there will be other algorithms developed for chemistry, management, etc. Fortunately, it will only take a small number of programmers to create tool libraries that can be applied to a wide variety of applications. But the concepts involved with quantum programming are a full step above what is needed for von Neumann machines.Your next question is about the most difficult programming. There are a lot of things that make programming difficult - the trickiness of the algorithm usually being the least of them. And a lot of those difficulties such as ambiguous requirements have already been mentioned in this thread. To that list, I would add process visibility and tools. "Visibility" is my term for being able to see what the program is doing - especially when there is a bug. As an example (not from my experience): Bad is when your code is on an airplane and there is a problem you can't reproduce. Worse is when the problem cannot be reproduced even when the plane has landed. In such cases, the amount of code you may need to instrument the problem could exceed the amount of code being debugged. It gets to be an unexpected issue requiring unplanned resources and an unmanageable time line.
One project does come to mind. It was for a flooring distributor in the Baltimore area. About 30 employees would be taking phone orders, entering them into the computer, and the system would organize them into instructions for the warehouse employees. The system was completed ahead of time, tested by myself, and then tested with 3 employees for 3 days. It worked just fine. So the entire sales force was switched over to it - and it started failing at 11am. It took an unhappy week to track it down - during which time some 20 orders were lost each day. The problem was eventually tracked down to a bug in the memory resource handling by the OS. From a programming point of view, the only way to recreate the problem was to allow the system to be used under the most intense conditions - when system memory was being rapidly used, released, and reused in a multi-threaded environment.
