Forgot your password?
typodupeerror

Comment: PHP on the command line (Score 1) 466

by brausch (#47241771) Attached to: Ask Slashdot: Best Rapid Development Language To Learn Today?

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.)

Comment: Re:1M lines? Really? (Score 1) 435

by brausch (#46880187) Attached to: C++ and the STL 12 Years Later: What Do You Think Now?

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.

Comment: Re:Lower the river, obviously (Score 2) 168

by brausch (#46383049) Attached to: Damming News From Washington State

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.

Comment: Re:Great (Score 5, Informative) 222

by brausch (#45907479) Attached to: Japan To Create a Nuclear Meltdown

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.

Comment: Re:That is a beautiful start of a ... (Score 1) 232

by brausch (#45895377) Attached to: "Clinical Trials" For Programming Languages?

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.

Comment: Re:That is a beautiful start of a ... (Score 5, Insightful) 232

by brausch (#45880149) Attached to: "Clinical Trials" For Programming Languages?

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.

Comment: Re:Looooooong game (Score 1) 308

by brausch (#45655063) Attached to: Google's Plan To Kill the Corporate Network

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.

Nothing is impossible for the man who doesn't have to do it himself. -- A.H. Weiler

Working...