Even on slightly fancier processors you can have limited JTAG debugging support. Severe limitations on the number of instruction breakpoints and data breakpoints can limit the usefulness of the debugger for everyday work. Even in not-particularly-time-critical software single-stepping through the code can be impossible - either the bug is time dependant (e.g. errors in hardware drivers or race conditions) or normal execution relies on timing (e.g. communications). The debugger is useful only for a very narrowly defined set of bugs.

When the debug-with-printf approach is used the program speed can be badly affected. Changes in program speed can affect the occurance of the bug being investigated. Output may be going to a serial UART running at no more than 115200 baud. Even the GPIO toggling method can have this problem; the processor we use has the GPIO in a separate clock domain that runs several times slower than the instruction clock. One workaround for this is to write to RAM (if available) or to additional hardware connected to the external memory bus. At worst you're reduced to paper debugging.

I've used an inexpensive commerical PC-based logic analyser. It had a combination of terrible software and frustrating hardware limitations (e.g. only being able to set the timebase in powers of two and a very limited number of samples).

This particular logic analyser can only make a limited number of samples. A limitation like this can make some debugging problems harder. E.g. I2C/SPI serial data where it may be impossible to trigger at the required moment. A cheap logic analyser may make sense for a private individual but in a commerical setting they are a false economy.

The limitations of compiled executables are becoming more apparent with today's diverse hardware. One generation of mobile device may not use the same instruction architecture (processor type) as the next generation of mobile device. And the other devices connected to the processor change frequently. A new executable would have to be compiled for every major variant of the device. With something like Java bytecode the program can be one-time optimised when the program is loaded onto the device, which is a good comprise between efficiency and portability.

I program in C. In C there is normally a good correspondence between C code and machine code. But there are many ways that C is less efficient compared to more modern languages, especially when writing well structured code.

Virtually every device has substantial amounts of code written in C or C++. Javascript would be useless on the microcontroller I write C code for. If C and C++ were to vanish overnight we'd be back in the stone age. I won't comment on whether C and C++ belong in the stone age, but it's great that many programmers don't have to think at the lower levels of machine abstraction.

An even better solution would be a physical recorder on the aircraft and transmission of that data from the aircraft. In this way the information will be protected from either loss of the physical recorder, problems that affect the transmission equipment (e.g. aircraft damage in the region of the antenna) or problems with the ground stations. Also, the volume of data that could be logged on a physical recorder could exceed what could be reasonably transmitted continuously (because it might not possible to transmit anything after the fact).

I believe that it says more about politics than innovation that few engineers and scientists choose to enter politics. Perhaps engineers and scientists feel that they can't succeed with a well researched fact-based viewpoint against the slippery populist rhetoric of typical politicians. It's either that, or politicians have provided the ideal environment for engineers and scientists such that they feel there is no need to effect change through politics.

Recursive use of the trademark symbol could make things a little interesting.

The "kill-switch" is intended for businesses and governments - the cost of a computer is negligible compared to the potential cost of a data breach. Encryption should be standard for these organisations. If the encryption is done properly then it should be tied to both the hardware and the user, so that data can only be accessed on authorised computer systems. Hence the "kill-switch" which will prevent data from being decrypted (by denying access to the hardware) even if the user's passwords are known. This is far more security than the average person wants or needs.

Discrete tracking may allow equipment to be recovered. But just like anti-theft ID chips in Caravans etc. it isn't necessarily the thief that is out of pocket when the equipment is recovered.

One reason is the lack of sounds in Japanese resulting in huge numbers of homophones. Both Katakana and Hiragana encode each of the homophones in a fixed way unlike in English (e.g. in English "One" vs "Won"). The use of Kanji reduces the amount of ambiguity in the written language. The Chinese characters were used first anyway.

Disclaimer: I don't speak Japanese, yet.

The current generation has put aside plenty for the archaeologists. But they will need to reinvent the digger in order to shift through it all.

Jonathan Paton

Driving in the direction you are looking is a terrible idea.

Here in the UK you don't pass a driving test without using your rear view mirror, your side mirrors; and looking when appropriate through the side or rear windows. Just because you are looking for potential dangers doesn't mean you want to steer into them (e.g. a car overtaking you). Applying makeup etc. or tuning the radio would be unusually lethal.

Jonathan Paton

I program for an embedded system with 64K of on-chip RAM and 256K of external RAM. There is less than 256MB of RAM shipped per 3 months of sales. There is also FLASH memory in our system but only a few megabytes.

The great thing about more RAM is that programming gets much easier. But many, many things are still possible with tiny amounts of it. At the lowest end of microcontrollers is the likes of the PIC10F200, which has just 375 bytes of program memory and 16 bytes of data memory. Real multi-tasking isn't possible at that level but a few orders of magnitude above it is often not just desirable to have real multi-tasking but necessary.

Apple must trade off the hardware cost vs. the development cost. For them each cent trimmed off the hardware cost is enough to hire a few more software developers to work-around the limitations imposed.

Jonathan Paton

I wrap as much of my code to 80 columns as possible but I may be doing the wrong thing.

The main problem is that 80 columns can be a fight between meaningful variable/function names and actually getting anything done on a line of code. Just changing a variable name can mean spending time getting everything back under the 80 column self-imposed limit. And that's a problem if you've done A=B+C and can't do much more to shorten the line without using +=. Rigid use of a small column limit may lead to less readable code.

The diff tool is another battle ground: shorter lines help when differencing files (e.g. 3 files side by side) but at the same time a shorter column limit often means more changed lines.

I think that the goal in programming is to write obviously correct code. Whatever achieves this is the right approach. Which is why programmers often can't agree on anything because there isn't one correct approach (except their own!).