What are the hardest things to program?

Right, but often it only works because of a lot of mistakes cancelling each other out.
or its never called. Sometimes that's the worst thing to happen. You do a bunch of detailed changes only to discover that it was dead code.
Sayre’s Paradox is a dilemma encountered in the design of automated handwriting recognition systems. A standard statement of the paradox is that a cursively written word cannot be recognized without being segmented and cannot be segmented without being recognized.[1] The paradox was first articulated in a 1973 publication by Kenneth M. Sayre, after whom it was named.[2]

For details, see Kenneth M. Sayre, “Machine Recognition of Handwritten Words: A Project Report,” in Pattern Recognition, Vol. 5, 1973, pp. 213-28.

It's hard to program the ability to tell where one letter ends and the next begins -- there are other approaches, but this was 1973, and machines didn't have as much processing capacity or storage as is readily available today -- and cursive handwriting recognition is still difficult.

Stephen Tashi

Science Advisor
If we interpret "difficult" to mean tedious and unpleasant, the most difficult things to program are those that involve arbitrary conventions and standards - for example, things involving the conventions and libraries written by other programmers, or conventions about how files are formatted - or conventions issued by people who are vague or keep changing their minds.

If we interpret "difficult" to mean hard to accomplish but interesting to attempt, there are lots of difficult problems.
Related to that are callable modules where one module is based on metric units and another is based on english units and someone else wrote the code to bind them now you must add functionality while preserving the sanctity of the mixed units of measure.
A friend of mine when I was a kid wrote a Dynamo to Fortran converter/compiler -- for portability, he wrote it in Fortran -- the string handling was difficult ...


Homework Helper
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.
I think the key word is "complexity." We need to deal with enormous complexity. Humans are not always good at handling complexity. Simple implies easy, complex implies hard.

That is why I am working on an AI "programming expert system." Lisp is vital in this effort.

Another difficulty is developing for certain modern operating systems. To quote William Blake, "I must create my own system or be enslaved by another man's."

Add variations in hardware and of course networking, and we have a problem.

Here are a couple of interesting examples of people who understand the perils of complexity.

Wirth's Oberon is particularly good for people who think an OS must be a bloated opaque monstrosity. He proves otherwise. (See his essay "A Plea for Lean Software.") Not only is he a renowned pioneer of software, but he decided to get into chip design as well. What a hero!

I enjoyed watching this video about one man's eZ80 project.

Last edited:

Want to reply to this thread?

"What are the hardest things to program?" You must log in or register to reply here.

Related Threads for: What are the hardest things to program?

  • Posted

Physics Forums Values

We Value Quality
• Topics based on mainstream science
• Proper English grammar and spelling
We Value Civility
• Positive and compassionate attitudes
• Patience while debating
We Value Productivity
• Disciplined to remain on-topic
• Recognition of own weaknesses
• Solo and co-op problem solving