What are the hardest things to program?

[ElliotSmith]

TL;DR Summary

In your opinion, which software is the trickiest to program?

In your opinion, what are the most difficult things to program?

People have said that it's things like operating systems, hardware drivers, physics simulators, and game engines.

 

[Klystron]

In your opinion, what are the most difficult things to program?

People have said that it's things like operating systems, hardware drivers, physics simulators, and game engines.

I have designed and written software for all your examples with the exception of 'game engines' without notable difficulty. An unresolved programming issue encountered in artificial intelligence (AI) classes and discussions concerns modeling human emotions.

Creating matrices containing integers that represent an emotion such as anger fail to model the most basic human response to emotional conditions. Consider so-called "lie detectors" that measure pupil dilation, galvanic skin response (gsr), pulse rate, breathing patterns, even micro-tremors and other involuntary speech patterns. None of these measurements reliably indicate emotions, past emotional states or veracity of responses.

 

[DaveE]

People. People are the hardest thing to program.

 

[Ibix]

Programs with no bugs.

 

[DavidSnider]

People. People are the hardest thing to program.

Yep. It really boils down to this in the end. Operating Systems, Physics Engines, Games, etc are not written by a single person. Every complex program is a collection of simpler programs and the hard part is getting them to communicate and cooperate with each other. To get the programs to communicate well you have to get the people writing them to communicate well.

 

[hutchphd]

If you are making an embedded system the USER INTERFACE is always the hardest to get right in my experience.

 

[DaveE]

IMO, it's not really about the language or the final product. It's more about the development environment, coding standards, debugging tools, specifications and such. It's easy and quick to write bad code, or to code the wrong functions.

 

[anorlunda]

The most difficult projects are the ones with the poorest requirement definitions.

I was once forced to make a system A interface with a preexisting system B. But they refused to tell me anything about B.

 

[jedishrfu]

There are some mathematical games that defy programming. One was Sprouts the line segment from midpoint to midpoint game where you weren't allowed to cross a line segment.

http://www.papg.com/show?1TMQ




https://en.wikipedia.org/wiki/Sprouts_(game)
The difficulty was the program had no sense of spatial connections and would have to exhaustively search for them. So while you might write a program the computer will take way too long to be a formidable player playing the best move.

https://senseis.xmp.net/?OtherGamesConsideredUnprogrammable
This gets back to Millenium Problem: P vs NP Conjecture and whether timely solutions can be found or at least verified in a timely fashion.

http://news.mit.edu/2009/explainer-pnp

 

[jedishrfu]

Here's some code to start with although it has no computer player:

http://www.math.utah.edu/~alfeld/Sprouts/

 

[ElliotSmith]

What about an artificial general intelligence (AGI)?

 

[jedishrfu]

Well of course, since no one has done it yet. Similarly for an ASI ie Artificial Super Intelligence.

 

[Tom.G]

Summary: In your opinion, which software is the trickiest to program?

In your opinion, what are the most difficult things to program?

Anything you haven't previously succesfully completed!

 

[Rive]

I think the hardest things to program are the poorly made specifications made during inadequate general management staff meetings, with short, strict deadline ...

 

[Svein]

The hardest things to program...

Since most of my programming lies in the hardware interface ("drivers"), the hardest things to program are the cases where the hardware has some idiosyncrasies that are badly documented or where the higher-level programs have some odd requirements.

The worst case:

An ARM 32-bit processor (cannot remember which one) required all longs to be aligned on a 32-bit memory boundary. Accessing a long on a 16-bit boundary did not give an error message but instead returned a scrambled version of the previous long and the required long.

An Ethernet data packet has a 14 byte header followed by the data payload.

The IPv4 protocol assumes that the protocol header (about 20 bytes) is aligned on a 32-bit boundary.

The malloc function for the ARM processor returns a memory block aligned on a 32-bit boundary.

So - as I had done lots of times for Intel processors - I allocated a memory buffer and told the Ethernet controller to use that buffer. When a data packet arrived, the driver checked the packet type (the leading two bytes) and (discovering that it was an IP packet) gave the IP protocol handler a pointer to the data part of the packet.

The IP protocol failed every time. It did not recognize the IP address even though I could see the correct address in the data packet. It took a while to pin down the fault - the IP data packet was not aligned on a 32-bit boundary. The solution was a real kludge - copy the complete data part on to another buffer that was aligned on a 32 bit boundary. A better solution would have been to have the Ethernet controller start on a 2 byte offset, but hardware limitations precluded that.

Why was the copy solution a bad one? Simply stated: Copying a data block internally took longer than transmitting the data packet across Ethernet!

 

[strangerep]

I was once forced to make a system A interface with a preexisting system B. But they refused to tell me anything about B.

Wow, that's an ultimate AI system. Plug it into anything, and it has to learn (all by itself) how the other thing talks and what it does.

 

[somega]

I think the hardest programs are big programs.
As they get bigger you might lose track.
Or you might have underestimated the effort.

 

[anorlunda]

I think the hardest programs are big programs.
As they get bigger you might lose track.
Or you might have underestimated the effort.

That's very true. The converse is also true that the move beautiful and coherent programs are those which can be conceived, implemented and tested in a single session. Obviously, that puts limits on how big the program can be. It also explains why all-night sessions are common among software developers, and why the young have the advantage over the old in that profession.

I used to wish that we could hire programmers at age 13, work them mercilessly until age 23, then pay for their primary school and college education after their retirement at 23. But of course, that is not allowed in software, although we come close to that in athletics. Nearly 100 years ago, my uncle was removed from his family and school at age 8 to live at a baseball farm that belonged to the Boston Braves.

 

[ElliotSmith]

I think the hardest programs are big programs.
As they get bigger you might lose track.
Or you might have underestimated the effort.

Big programs, like Microsoft Windows 10, has roughly 50,000,000 lines of code.

 

[Rive]

I think the hardest programs are big programs.

Well, I think above a/the (human) limit the difficulty (for an individual) is actually a lot lower, since the load will be distributed to teams instead of individuals and most of the responsibility will be shifted to the engineering phase and testing.
Of course if what the engineering phase produces is a mess then it is #14.

 

[Chris Miller]

In my 40 or so years of experience, the hardest things to program are modifications to other programmers' reports using other programmers' libraries and utilities.

 

[jedishrfu]

Especially if the code never worked but no one knew it until you looked at it.

 

[Chris Miller]

Right, but often it only works because of a lot of mistakes cancelling each other out.

 

[Shane Kennedy]

If you are making an embedded system the USER INTERFACE is always the hardest to get right in my experience.

Probably because there is no universal "right". It is impossible to make everyone happy, and trying is more of an art than a science.

 

[jedishrfu]

Two things commonly happen with UI development for a client:

1) The client sees your design and expects the finished product to look exactly like what you showed them in your mockup because it was too precise looking. Some designers I know, advocated showing a client crayon based designs so they couldn't build any unreasonable expectations.

2) The client changes their mind or the project has feature creep which affects the design causing delays and changes to be made.

 

[jedishrfu]

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.

 

[sysprog]

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]

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.

 

[jedishrfu]

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.

 

[sysprog]

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

 

[.Scott]

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.

 

[Aufbauwerk 2045]

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.

 

[hilbert2]

On a more grass root level, this task is something that is a higher level of abstraction than you can write in a simple way in most programming languages:

https://stackoverflow.com/questions/18165937/variable-number-of-nested-for-loops
There's no single conditional loop command in C++ that can easily produce a variable number of nested loops.