It is about time that somebody (hopefully some of the commercial vendors AND the open source community too) get wise to the problems of digital storage.

I always create files with unique headers and consistent version numbering to allow for minor as well as major file format changes. For storage/exchange purposes, I make the format expandable where each subfield/record has an individual header with a field type and a length indicator. Each field is terminated with a unique marker (two NULL bytes) to make the format resilient to errors in the headers with possible resynchronisationthrough the markers. The format is in most situations backward compatible to a certain extent as an old program can always ignore fields/subfields it does not understand in a newer format file. If that is not an option, the major version number is incremented. This means that a version 2.11 program can read a version 2.34 file with only minor problems. It will not be able to write to that format, though. The same version 2.11 program would not be able to correctly read a version 3.01 file either.

I have not implemented ECC in the formats yet, but maybe the next time I do an overhaul ... I will have to ponder that. Maybe not, my programs seem to ephemeral for that ... Then again, so did people think about their 1960es COBOL programs.

Today I had a nice, long bath with John Grisham.

Well, not the author in person, but his book, The Street Lawyer. Paperback version.

I would have been rather more reluctant to do the same with a Kindle (or equivalent) edition, as I am pretty sure a dip in the water would render it beyond repair.

I cannot be the only one who occasionally loses a paperback to whatever unfortunate events that pass me by. (Temporary insanity and such.) I have provided Dublin Airport with one (I got my camera back, which had been impounded by security guards), an assortment of hotels, planes and trains have got their share and for some odd reason I have never found my lost PDA. (The interesting stuff was encrypted, thank you very much.)

The thing for me (and quite a few other people, I am sure) is that the loss of a paperback may be unfortunate but not a major setback, whereas the loss of an eBook reader is more than just annoying.

It seems that the p-System -- the underlying OS for UCSD Pascal -- is no more.

It had a number of features like direct feed-back from the compiler to the editor, highlighting lines in error, which was a major step forward, especially for me, as I had done most of my programming on my Apple ][ in 6502 assembler. (Digression: Steve Wozniak is a genius in my humble opinion.)

UCSD Pascal was unique in the way that it compiled to pseudo-code (p-code, why does that make me think of Java?) and was mostly written in p-code itself, apart from machine-dependent parts.

Other "features" made the system a bit quirky, like contiguous files only, which meant you had to pre-allocate space for files if you wanted to write to more than one on a disk.

But hey, I could exercise my theoretical knowledge, gleaned from Niklaus Wirth's Pascal book (red and white and from Springer Verlag) on my Apple!

Drat!

I caught one error only to trip up later :-(

Has anybody actually checked their calculations????

I just eyed the numbers and it seems to be off by three orders of magnitude; they estimate the energy collection to be about 9.19 Billion Kilowatts -- am I wrong or does the calculation actually give 9.19 Trillion Kilowatts????

And they say they calculate ((25,000 mi^2) x (5280 ft / mi)^2) / (200W/15.16 ft^2) but do in fact calculate ((25,000 mi^2) x (5280 ft / mi)^2) x (200W/15.16 ft^2) -- which they should.

Not very assuring, is it? ... Or rather, WOW!, with only an efficiency of 0.015% we can still supply USA three times over ... Or, with 15% efficiency, a fifteenth of the world consumption (2005 numbers, total world energy consumption 500 exajoules = 5 x 10^20 J or about 139 x 10^12 kWh divide into output, 9.19 x 10^12 kWh, and voila roughly 1/15).

This is probably a rehash (pun intended :-) of other people's answers, but all the same, I cannot help myself ...

My best programming work is done in a drawing application like Inkscape or Visio.

Long before the first line of code is committed to the harddisk, I have (bar for the simplest of programs) made one or more drawings depicting the interrelations between the modules of the program I am making. Not only does this ensure a modular approach to the problem solving, but it also gives a nice documentation to present to other people. With a bit of verbal grease (knowing me, people would probably say: verbiage), it often makes it possible for me to explain to non-technical people, how the program is supposed to work and that I have ensured scalability, usability ... or whatever other -ability the customer wants.

The selection of the actual program language for implementation comes later and is often based on other parameters, like Perl for quick (and often "dirty") solutions that need pattern matching, associative arrays and object orientation, PHP if the solution is not too heavy on pattern matching and associative arrays but is web-oriented, C (or C++ or C#) if I need a fast and efficient solution without (too much) pattern matching and associative arrays, COBOL for one of my customers, who uses no other language (oh yes, they DO exist!) ...

Sometimes the language is given by the customer, based on whatever capability the customer's organisation has. I honestly do not care. I can program in most major languages like {patting my shoulder} ALGOL, FORTRAN, COBOL, RPG, APL, Ada, COMAL, Simula, BASIC (that covered most of my teenage years and early twenties), assembler (IBM, x86, 6502, M6800, M68000, RCA1802, ... -- that covered some of my first grey hairs), Pascal, C, C++, C#, Java, JavaScript, Perl, PHP, Ruby, Python, and whatever languages I have forgotten (like FORTH, LISP and Prolog). Most of these languages (being functional) are basically the same with slightly different syntax and semantics. Some of the languages are radically different like FORTH (reverse Polish notation made into a programming language), LISP (List processing) and Prolog, where you basically tell the computer what you want, not how you want it done. (I cannot wait until quantum computers gives Prolog or a similar derivative a new lease of life.)

So (at long last) the conclusion is: The method is much more important than the programming language. The more you know the better prepared you are for whatever an employer (or customer) may throw at you. And I cannot count the number of times I have created a quick proof of concept in Perl, only to have it programmed in some other language for actual implementation.

Remember, programming languages can be taught, programming can not. (OK, do not flame me! I do know, some programming can be taught, but the most elegant and efficient programming is more akin to creating mathematical proofs or composing beautiful poems or painting stunning pictures, an art, not a craft!)

As always this is a relatively simple problem wrapped in layers of -- to a certain extent unnecessary -- complexity.

The simple idea is to have a system that records the patients history of illnesses and treatment (including medication, obviously) and which is easily communicated across different places of diagnose and treatment (GP, specialists, consultants, hospitals, ...).

This specific problem could easily be solved with standard software like Lotus Notes, Microsoft SharePoint and similar systems, but that is where the simplicity stops and the layers of complexity start.

Sorry if I am going down a well-travelled trail here.

Firstly, it is very difficult to get people and organisations to standardise on a single system for good and for bad reasons. (Like "We've already got Lotus Notes, why should we get a Microsoft product?" -- plug in whatever conflicting product/system names you can think of.) This means that a single system probably is out of the question, which leaves us with a standardised interchange format instead.

OK, now we have a gazillion systems happily exchanging information in a standardised format, so everybody is happy, right?

Wrong!

Because secondly, who is responsible for the safekeeping of the data? This is two-fold: Who is responsible for storing the data and who is responsible for who has access to the data?

So 2a, Responsibility for storing the data: If every place of diagnose and treatment is responsible for storing own data, how can a patient be sure that any specific institution treating her has access to all the information? This needs some centralised storage or at least "mediating" (much like peer-to-peer systems, e.g. torrents, need a "meeting place", like The Pirate Bay, where they can find the trackers so they know where to find the peers). Either system suffers from the problem of connectivity dependence, i.e. if they cannot get access to either the storage, the "mediator" or the peers, information cannot be retrieved. This is still better than paper-based systems, if you are treated in different places, geographically.

This leads to 2b, Responsibility for who has access to the data: I would obviously like for my GP to send information directly to the hospital and for the nurses, doctors, consultants and surgeons treating me to see my records, but -- being the famous person, I am ... not -- I would be quite weary if just about anyone could look at my records. How is this problem solved?

Thirdly, who would be responsible for correcting errors and mistakes in the records? This problem is not really an issue relating only to electronic records, but is a general issue, which crops up all the time. Should you, as the patient, be allowed to correct mistakes you know about? If that is the case, how do the professionals make sure that you are not trying to tamper with the system for some ulterior motive (everything from trying to cover medical problems for insurance purposes to hypochondria)? If you are not allowed to correct mistakes, how do you tell them that you did not receive a certain medication two years ago and, in fact, is allergic to it?

Fourthly, a system relying on doctors, specialists and consultants to type would probably be doomed, at least for now. It seems that doctors, etc. at all the hospitals I have seen, rely on dictation, having a pool of secretaries typing it in and updating the records, which introduces unnecessary delays and adds an extra risk of introducing errors.

These are some of the many problems facing such a system and I am sure I have left out many, just as relevant. I honestly do not believe that the fear of transparency regarding the treatment is the major stumbling block for the introduction of electronic medical records, but rather the diverse types of problems facing the system.

I was not trying to imply anything about the cause(s) of the tragic crash of A447, rather about the complexity of the system and what that means.

Many years ago (before GPS) i developed a navigation system for a customer, based on the at that time available positioning systems (like Pulse/8, Syledis, and active and passive Decca). The system was used in a surveillance ship and had to plot a route to follow and to show the position of the centre of mass of the ship in relation to the desired position, which meant that I had to get input about pitch, yaw and roll as well as the positions from the different positioning systems.

Due to a number of factors, it was far from straightforward as the sensor readings could be noisy (I once had a nightlong discussion with the First Officer about a problem with the gyro, which the FO claimed couldn't be malfunctioning as it was a Robinson Gyro -- but it was, malfunctioning, that is), the readings from each navigation system would vary from the actual position and the ship would roll up to 45 degrees to each side due to severe weather.

My job then was a difficult task and what I am trying to say is that it is probably orders of magnitude more difficult for a system like the Airbus and thus much more prone to errors, human as well as technical.

The computers may be multiple redundant with graceful degrading of performance in case of failures and may try to guard the plane from the pilots (like preventing the pilot from decreasing speed to below stall-level or performing manoeuvres that would jeopardize the plane or its passengers), but the system is dependent on input from sensors and, if I remember correctly, Airbus has had a number of problems with sensors and I just read that Air France are going to replace all airspeed sensors and that pilots should refuse to fly unless two of the three airspeed sensors have been replaced.

Multiple redundant systems do not change the GIGO (Garbage In, Garbage Out) principle.

No need for all those newfangled ideas, when good old MagicSpell (TM) can do the work.

... and where?

It has to stop somewhere.

When does the policymakers (and the public) realise that death from terrorism is negligible compared to other (more or less) avoidable causes.

How many lives could be saved in the USA alone by free flu vaccines? How many are killed from gun-related shootings? Traffic deaths? ... Come on, terrorism is hardly noticeable in the big scheme of deaths.

We do not need much airport security, really. Just think about the time, when you could board a plane without being checked, double checked and then frisked. Do not just take my word for it, Bruce Schneier has mentioned it several times, including here.

"Microsoft was accused of preying on Borland's staff and hiring them away"

I do not know if Microsoft preyed on Borland's staff, but it is a fact that the creator of Turbo Pascal (a fellow Dane) Anders Hejlsberg is now employed by Microsoft and is lead architect of C#.

Sorry Sir, but it seems that a transistor has gone in the controller circuit and your data cannot be retrieved!

You are so absolutely right ... only I spend too much time in airplanes, and so far no one have allowed me to drag out my 3G-based network card and use it on board.

To boot, some of the companies I work for have not got a proper VPN setup either, thus preventing that approach! (Bummer, that.)

Regarding loss of data, I carry a copy of all essential files (encrypted, naturally) on a diminutive USB-drive, which I keep on me at all times. (Please don't tell the people at the airport security control!) Furthermore I unload data to my clients' servers, whenever I can (at least I am not responsible for their security :-). To facilitate the backup to the USB drive, I have some homegrown scripts (did I hear somebody groan?) that automatise everything, apart from entering a password now and again.

Oh and I have not lost any data yet (apart from computer or software breakdowns while entering data before backup like when Windows does a BSOD after I have composed a masterpiece of a report) in my almost forty years of working with computers.

All of this does not change the fact that you are right: Whenever possible keep your data in a secure environment and access it remotely through a VPN tunnel.