Polywell Funding Confirmed By Major Media
Dave Price
Most of those interested already know that Bussard's fusion project was funded in August, but this is the first published report from a major media organization that I've seen, and seems worth linking given the conflicting reports in the past:
Bussard received nearly $2 million under a U.S. Navy contract in August to continue work on an inertial electrostatic confinement reactor he had developed. The reactor uses magnetic fields to confine electrons, whose negative charge causes protons and Boron 11 atoms to fuse. The fusion sets off a chain of reactions that produces electricity.Should the current project produce the expected results, Bussard had indicated funding might be available for a major project in the $100M - $200M range to attempt the building of a 100MW net power Polywell fusion reactor, which, if successful, would of course be a world-changing event. I'm actually now studying Forth, a computer language that might be used for the critical control software, in addition to some remedial physics/engineering, in hopes of perhaps being relevant enought to work on this project (should it materialize) myself, though that might be problematic in terms of my career/financial goals.
Discussion of Polywell continues in several forums. You can see the video of Bussard's Google presentation here.
Well, M Simon swears by it. Eliminates the stack thrashing you get in C, and you can allegedly be far more productive in some applications.
It's a fully stack-oriented language. Syntactically extremely simple.
IMO better for simple one-time control programs than complex systems, especially ones that are expected to change over time and be maintained.
The advantage Forth has for Polywell, as I understand it, is fast execution time. Of course, the downside is sloppy programmers can make an unreadable mess in Forth.
But if there's a need for it, I have a coworker who loves Forth, did it for years as a Boeing subcontractor. Maybe I should send him this info.
I have used it on very complex problems and had the software vetted by a US government checker.
He said it was the best documented, easiest to understand software he had seen in years. BTW I rarely commented the software. I let the WORDS speak for themselves. People with a good literary knack tend to be the best FORTHers.
Well written FORTH is easy to maintain. In fact we used to change displays and input methods on the project I was working on monthly (the customer didn't know what he wanted). The competing guys using C were still struggling 6 months later. And they had 15X the staff I had. (30 programmers vs 2 and my programmers also were my technicians.)
Here is why FORTH (other than the fact that it is the best way to bring up cold iron - Sun Microsystems uses it for that).
24 1 GHz processors in one chip. Selling price $1 to $2 in volume. Probably $20 to $50 in tens to hundreds. Each core running at full clip uses 9 mW. Power management is automatic. All sections idle = 1 uW drain. You have a problem one chip can't solve? Use 10. They are less than 5 mm on a side. Compare that with the footprint and power consumption of a high end DSP or one of AMD's lovelies.
My guy inside the company (you knew I had to have something going on) tells me that they are on track to meet their delivery promises. (ship prototyping volumes in 4 Q). Their primary focus is on high volume stuff (100,000 and up). He humors me for the publicity value of being The Fusion Processor and because we are long time friends.
I will not tolerate poorly written FORTH production code in my shop.
I have a bunch of FORTH resources on the side bar at:
IEC Fusion Technology blog.
Including two of the best books ever written on the subject. "Starting FORTH" by Brody and "Thinking FORTH" also by Brody. The are FREE.
Forth love if, honk then.
Got my copy of Starting Forth yesterday, btw.
Really? I thought it was, "If honk Forth, love then. Stop. Twice. Repeat."
Which reminds me of an old joke, but since this is a family channel, there's no sense in that kinda thing.
Dave, I have serious personal reservations that Bussard's process will actually work in the way claimed (that is will produce the type of power stated). But as anyone who knows anything about invention also knows, one road overlaps another, and experimentation often leads to new discovery, sometimes totally unlooked for, and very profitable in and of itself. And if it does work as claimed, then prove me wrong, I'll be happy to play the fool. Never let it be said I let a good theory get in the way of real progress, even my own. (By the way, if what I said just seemed confusing totally, then I guess all this talk of programming just brought back some funny memories in language. Like that or something.)
In either case Godspeed and good fortune. Hope it leads to good work for ya.
By the by, has anybody ever noticed how juvenile the grammatical construction of old style, and even many current, programming languages? You could write Shakespeare in text, but to program the text to do that you had to talk like a newborn who learned English from a Romanian wetnurse. It's just always struck me as funny, and maybe it says more about the linguistic skills of the original programmers, than the capacities of the machines they employed, or maybe it just means that everything, machines included, always start out talking goo-goo before they can ever become gah-gah. Either way it just strikes me as interesting.
I often wonder, no matter how much we know about everything, is it ever possible to really begin anything anywhere other than at the start. In the fetal position I mean.
Curled up and babbling. Of course, I reckon you could ask the same thing about the end of the end of things.
You just can't expect much of an intelligible answer coming or going I guess. It's only in the middle that your ends are worth talking about.
I, Robot, Touch Me, Man
It occurred to me that if you could create a computing/communications and programming language (because in my opinion programming languages should not just be programming languages, but interactive and inter-reactive transceiver languages - running in all directions, not just at target) which consisted of graphic/visual, linguistic/auditory, hymnological, mathematical, and tactile elements/components then you could solve many of the restrictions of current language schemes. Of course that will probably require, if not a biological interfacing system, at least a semi-biological or imitative biological sensory input system, but at least it would have a crude or precursor mechanism for both linguistic fluidity and true linguistic innovation.
Anywho, I thought the article might interest some of ya.
Speaking of mixing sucky computing and langauge, Lord I hates me some Microsoft.
That should be symbological, of course, not hymnological.
Bob, that seems like a fancily assembled oxymoron to me, but I think you're probably on to something saying it that way.
See ya later folks.
Don't ya know Java is the best programming language?
One of the last revisions of the Java Virtual Machine corrected about 3,000 bugs. Therefore it must be good now, eh?
It's 12 years old, so it must be mature and reliable and easy to debug.
In fact, I gotta say I just love java on the desktop, because I get so many billable hours because of it.
We use C - it's the fastest language available that is portable (if used right) and is reasonably widely known and well-supported by debugging environments and other tools. I haven't seen FORTH on a resume in many years, although it may be because our embedded work is mostly consumer electronics, infotainment, and networking gear, mostly for Asian customers.
FORTH is used on the Fed-Ex "sign here" machines. They are very happy with it as it reduced the time for a major change from 2 years ("C") to 6 months.
There are a number of Government programs that use it - mostly space stuff - where resources such as memory and power are tightly constrained.
====
I could see a big market for 24 GIPS (peak) processor that runs on less than 1/4 W at full rip.
It is really too bad we have gone the route of complexifying to solve problems.
Complexity requires very smart people. Simplicity requires genius.
===
There will come a time (we may be there already) where the only efficient way to add speed is in the reduction of the number of interacting elements.
We have pipeline fillers and emptiers. Branch predictors to help the fillers and emptiers. Near cache. Far cache. Power management. Clock tree management.
There has to be a simpler way.
Of course we all lose our tempers now and then. Dean freely admits to being imperfect in this regard, which is why regulars to this establishment will generally be cut more slack than people who we don't know very well.
Still: behave like an adult, or go find somewhere else to play. Thanks.