Computer systems actually consist of different layers. Each of these layers can and frequently does have errors. Working from lowest to highest, the layers are:

Microcode (executes inside most CPUs). Microcode errors can and do happen, as shown by the Pentium floating-point error back in the mid 1990s. That's by no means the only microcode error likely to exist in a chip as complicated as the Pentium.

Hardware layer (my term for the physical design, including things like the motherboard and interfaces to support chips). Errors here can be caused by faulty design or manufacture, such as a weak joint that causes an intermident connection.

BIOS layer - the Basic Input Output Services consists of software burnt into a ROM, PROM, EEPROM, etc. It can and does have errors.

OS layer - operating systems can and do have errors, sometimes thousands of them. Real-time systems typically use a scaled down OS or none at all, but any system that depends on an OS is going to encounter errors, including the kernel code, device drivers, etc.

Application layer - this is where the applications actually execute. In multi-tasking systems, more than one process can be loaded and running at any given time. Sometimes, errors in one process can influence the behavior of another process.

Source code - this is the code for the applications.

Compiler, supporting libraries, and components - these can and do have errors. Sometimes, they can lay dormant for years before the right set of circumstances triggers these errors. Back in 1990, I was the Space Surveillance Crew Commander on the Cobra Dane Intel radar. One day, we were performing normal operations when the computer system crashed. After recovering the system, we resumed operations. The system crashed again. And again. And again. It turned out that a dormant bug in the FORTRAN compiler's math library had laid hidden for over 15 years before the right set of circumstances made them visible that day. Bugs are sneaky.

As a software engineer, the only bug control that I can exercise is over my own code. I can do little or nothing about the bugs at all of the other layers in the system other than to make my code as robust as possible.

When NASA and IBM developed the General Purpose Computers (GPCs) for the Shuttle, the key criteria was real-time responsiveness and reliability, not maximum performance. The systems don't use ordinary operating systems or devices with unpredictable performance like hard drives. Error detection and correction occurs at every step in the processing to prevent things like an SEU or data corruption to cause problems. By modern PC standards, the GPCs are ancient, huge, heavy, and very expensive. I'd wager that an iPaq PDA has more processing power (and I know it has more memory) than the Shuttle GPCs. Still, when you're betting several lives and over a billion dollars of hardware on the computer systems, well, GPCs are very reliable and extremely robust.

Both the Shuttle and ISS use essentially off-the-shelf computers (mostly rack mounted) for secondary functions while in orbit. These computers don't control life-critical systems so if they need to be rebooted, it isn't a big deal. That just isn't the case for life-critical systems like you'd need during launch, reentry, or a lunar landing.

To give you an idea how careful NASA is with the Shuttle software, every single line of code is reviewed in detail before it goes into the system. The software is tested extensively before it is used. Even then, the main PASS software is only loaded into 4 of the 5 Shuttle GPCs. The other GPC software is written by an independent company in complete isolation from the other software. They do this to prevent any single error from causing all of the computers to fail. This kind of development is extremely expensive but that's what you have to do when so much is at stake.

Going to a higher level language can reduce some errors. Studies have shown that the number of errors per thousand lines of code is relatively constant regardless of language, so using a higher level language should result in fewer errors. However, until the compiler and supporting languages are validated, you could well end up with a lot more errors in the end.

A lot of the software development expense will depend on who is developing the lander. If a private company is paying for the lunar lander, they can feel fairly free to use cheaper hardware and software development techniques. However, the odds are that the government will be paying for the hardware, so you can pretty well be assured that the current software and hardware techniques will continue to be used.