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.
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.)
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.
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.
:-) 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."
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.
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.
Absolutely agree. I just use my remote machine as a device to connect to my at-work machines where all the work is actually done. No corporate data is ever stored on my laptop, just personal stuff in a few encrypted files.I occasionally tinker with code on my laptop but everything serious is done on my real servers.
Four years from now I'll be using a one year old machine.:-) Any developer that I'm paying good money to is worth a new computer every three years. Compared to salary and benefits the cost of hardware is minimal.
Well, I did walk up hill both ways to and from the high school!:o) Our house was on a hill and I walked through the valley about a mile and a half to the high school up on another hill. LOL
Bill
PS: I did program analog computers in college (you know, plugging in actual wires and turning knobs with the output on an oscilloscope), and also a PDP-8 that required using the front panel switches to bootstrap the loader program to read the paper tape. Can't say that "I liked" either of these but I sure learned a lot.
My high school was part of a pilot project for rural schools in Minnesota in 196x. We got boxes of pre-punched, numbered (in columns 73-80), FORTRAN statements and would assemble programs from them. The teacher would send the student programs down to the Univ. of Minn. via bus and we'd get the printouts back for the next week's class. It got me hooked for life.
Absolutely agree with this. I accumulated things for over 25 years and have spent the last 10 slowly throwing things out. I'm a lot more selective now on what is actually worth the space in my house.
Slashdot Mirror
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.
This would be on my short list as well.
Also add "I, 2, 3, Infinity" by George Gamow
Absolutely agree. I just use my remote machine as a device to connect to my at-work machines where all the work is actually done. No corporate data is ever stored on my laptop, just personal stuff in a few encrypted files.I occasionally tinker with code on my laptop but everything serious is done on my real servers.
Four years from now I'll be using a one year old machine. :-) Any developer that I'm paying good money to is worth a new computer every three years. Compared to salary and benefits the cost of hardware is minimal.
Earlier this year HP announced the end of the line for VMS. That was certainly connected with the Itanium retirement as well.
Well, I did walk up hill both ways to and from the high school! :o) Our house was on a hill and I walked through the valley about a mile and a half to the high school up on another hill. LOL
Bill
PS: I did program analog computers in college (you know, plugging in actual wires and turning knobs with the output on an oscilloscope), and also a PDP-8 that required using the front panel switches to bootstrap the loader program to read the paper tape. Can't say that "I liked" either of these but I sure learned a lot.
My high school was part of a pilot project for rural schools in Minnesota in 196x. We got boxes of pre-punched, numbered (in columns 73-80), FORTRAN statements and would assemble programs from them. The teacher would send the student programs down to the Univ. of Minn. via bus and we'd get the printouts back for the next week's class. It got me hooked for life.
Civil War had more American military deaths than WW2 by around 50%.
Hanford has nothing to do with nuclear power. It has everything to do with nuclear weapons.
Not unless they've got a contract that says so. Their authority stops at my router unless I've given them permission.
They can ask me to conduct my own testing or they can ask if they can test.
I'm not a clinic but banks have similar laws.
Absolutely agree with this. I accumulated things for over 25 years and have spent the last 10 slowly throwing things out. I'm a lot more selective now on what is actually worth the space in my house.