What are the hardest things to program?

[ElliotSmith]

TL;DR

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