It's even worse than you think! :-) White space is significant (reminds of makefiles and tabs vs spaces). The above source isn't quite right. There need to be TWO spaces after the Q:'X in the line beginning with a C.

Having said that, I love programming in this language (well, Intersystems Caché actually). The database and language are fully integrated with a very powerful standard library.

In MUMPS, now mostly used in Intersystems Caché, white space is significant in a strange way. There are places where one space is required and other places where two spaces are required.

Yes. This.

You said: "as web apps using PHP"

How about just using PHP from the command line? It's dead simple and just extends all of the things you already know how to do: sed, grep, shell scripts and C. Just read from stdin and write to stdout and you have access to a lot of capability with very little new learning. You don't need web pages to write PHP. It can be used like any other scripting language (Perl, awk, etc.)

:-) Wasn't trying to be virtuous. Merely sticking up for the first poster.

I think it could be true. I wrote over 200,000 lines of C in one three year burst in the early 90s. A multi-tier client server thing, everything from user interface to SCSI control code. It is running still in production 20 years later. So a million lines in a decade is at least feasible.

8 m of thermal expansion/contraction would make that the biggest bridge in the universe!

Point: there are quite a few Columbia River dams downstream of Wanapum, not just one. There is only one below Wanapum and above the free-flowing stretch of the Columbia, but that is only about 60 miles or so. Then there are a few hundred more miles of river with several more dams.

Point: there are many buried reactor cores at Hanford. Hanford is large though, over 500 square miles, and they are not subject to flooding even if the dam was gone.

Biggest concern at the moment is the potential fluctuations in the cost of electricity.

although radix is a close second. Depends on the mess I'm dealing with at the time.

:-) Almost happened once. Some sensors got wired wrong. Somehow the QA failed. When the temps started going up it got noticed instantly. We fixed it in software in an hour and continued.

RTFA: "He said it will be the first such experiment to be carried out by the Japanese agency, although similar projects have been done in major nations with atomic power such as the United States and France."

It was done decades ago.

Pacific Northwest National Laboratory conducted in-reactor experiments that involved total fuel failure in a controlled environment. The series of experiments took place in the Canadian research reactor NRU located at the Chalk River Laboratory in Ontario. There were a series of experiments over about a six year period in the 1980s.

Three Mile Island's accident was the trigger for this research program. There was financial support for the project from the US, Canada, Japan, Germany, and a consortium of around 20 other nations.

The most severe of the accidents that we simulated involved simulating a Loss Of Coolant Accident (LOCA) that resulted in fuel rod cladding failure (including melting in the worst cases) to try to recreate the near total blockage of coolant flow in the fuel bundle. There were around 200 thermocouples in the test rig, along with lots of flow meters, etc. The idea was to gather enough detailed data to allow the regulatory agencies to properly evaluate the computer programs developed and used around the world that would try to predict the test results.

We actually used full 12-foot commercial reactor sized fuel rods. The reactor had only a 3-meter long core so our experimental containment actually stuck out the top and bottom of the regular core. We had a tiny bundle of rods, fully instrumented, inside a specially designed containment and the whole thing was then inserted into a process tube inside the reactor.

You can do a Google (or other) search using the words "pnl nru loca" and you can find a lot of information.

I was the lead programmer for the data acquisition and control system for the experiments.

I have an encrypted file which has lots of important info. My wife has a piece of paper with the password for that file. Simple.

It's just that there are so many different kinds of problems. :-)

I personally like the C-style languages, and actually use the plain C subset of C++ for much of my programming. And with the wide variety of libraries available for C/C++ you can solve most any problem. However, different languages, and more specifically, the different ways of thinking that they encourage, are useful. It's no longer just procedural vs object or compiled vs interpreted, there are lots of different old and new approaches. (Think Prolog or Erlang.) Each approach has strengths and weaknesses for different kinds of problems.

I agree with your basic implication that there are probably too many languages. But, like evolution, some species/languages will thrive and some won't. Personally, I'm glad there are lots of choices. It's like literature; I like reading sci-fi, but I'd be unhappy if that was all there was available to read. I also like mysteries, westerns, historical fiction, non-fiction, etc.

The real problem is that different languages are often created to solve different problems. You can't really compare them very easily with any single program, no matter what non-trivial program that you use. For example, C is a better programming language than Javascript for some problems; Javascript might be better than C for some other problems.

I'm advanced to expert in about six languages and have decent experience in a dozen others. I've settled on about four that I use a lot, and that fit the kinds of problems that I work on. Other equally skilled and experienced programmers (programming for over 40 years) would choose a different set of languages better suited to solving the problems they routinely work on.

It's kind of like trying to compare the toolbox of a plumber with the toolbox of a mechanic. There is overlap of course but there are also specialized tools.