The aircraft I had in mind is the U2 spyplane. The story I heard (from a Gary Powers "as told to" autobiography) is that the U2 had only a few knots margin between Mach onset and stall at its operational altitude, and it took an enormous amount of concentration over many hours to fly the missions.
The notion behind a coffin corner is that if you fly high enough, you run out of margin. Say you encounter stall onset. Well, you lower the nose, gain speed and then encounter aeroelastic flutter or some other kind of problem. The only way to recover is to lose altitude, but it may be a problem losing altitude in a graceful way without loss of control of the aircraft.
Don't know if most aircraft apart from X-planes and some high-performance military craft even have this effect -- they may lack the performance to get to that "corner" of the speed-altitude flight envelope.
On the original topic, if the airlines serve enough water and if they allow you to bring (dry) foods, my hungry self and people with real medical issues will be OK, its just that airline hospitality has gotten thinner.
The coffin corner of the flight envelope is where you fly so high that V_DNE approaches V_stall, and well, you just fall out of the sky and crash and burn.
Forget about toothpaste. What about, like, packing a lunch -- bottled water, yogurt, some energy bars? Its not like you get anything to eat on the plane anymore, and if you load up on fluids so you don't dehydrate (an issue in the dry, thin cabin air), well, they don't let you go potty on the approach to Washington National.
So I guess the flight experience will be like the Ramadan fast -- no fluids, no food -- for X hours, only X may be unpredictable and open ended given flight delays. A multi-hour no-fluid no-food fast is doable for multi-hours, but we are talking about in an environment where you don't want to be dehydrated because 1) dry-thin air, 2) the cramped seats where you are vulnerable to deep-vein thrombosis, 3) you are packed in with strangers sharing their nasal viruses. So it will be like Ramadan combined with the Hadj.
So the coffin corner is you can't pack lunch, and they won't serve you lunch, so you can sit there and be hungry and thirsty.
The whole C/C++/Java culture is so ingrained that you just can't communicate to people about Delphi compile speed. There is nothing like it out there, and part of it has to be the Object Pascal language -- the Pascal language was originally invented for teaching yes, but also to make for a one-pass compiler back when passes meant something in the type of memory and file models in use. There was once an industrial buzzword of design-for-manufacturing -- you design a consumer product, not just with the consumer in mind but with pounding it out at low cost.
The other part of it could be the Anders Heljsberg is an evil genius who just knew how to craft parsers and compilers better than anyone else. The evil part is that a claim has been made in these parts that the actual Delphi Object Pascal grammer doesn't have a spec the way the original Wirthian railroad tracks Pascal grammer did -- the Delphi grammer is supposedly proprietary and a trade secret, and that no one else can build a parser that handles all of the corner cases -- you might want a parser, not to build a competing Delphi but to build a smart editor, use Object Pascal has a kind of description language, etc.
But if you think Anders Heljsberg a genius, evil or otherwise, how come C++ Builder is dog slow on compiles in comparison. There has to be something to the Pascal language.
I am kinda switching over to Java Swing for the GUI, C++ through the JNI for the hardcore numeric stuff -- a person sees the handwriting on the wall about Borland longevity. I kinda want to get off Windows by the time Vista, Aero, and whatever Windows-specific GUI gobbeldygook takes hold, and Java looks attractive to me. It is easy to get spoiled by GC and some other Java hacks, but I miss the fast compiles -- javac is dog slow.
It seemed that Eclipse has a lightning-fast Java compiler in it -- someone told that it doesn't use javac but uses some hot-rodded IBM thingy. Eclipse, on the other hand, is still something I am struggling with -- it is IBMish in its weirdness about a whole bunch of stuff -- how do you just take a bunch of.java files in a directory and call it a project? It doesn't like a directory that is already there, and it wants to create some other directory in some standard location instead of where you want it. Still working on that one. So even Java needs "make files" of some kind of external metadata to organize multi-file source codes. Object Pascal famously has all of the dependencies specified in source code as a feature of the language.
If there are two features, no, make that three features! that make Delphi problematic for the future, they are 1) Delphi has some real solid Windows lock-in, especially since Kylix didn't go anywhere -- the Delphi extension to Pascal are quite Windows-specific even if you are not doing GUI programming, 2) while Delphi is great and everything, it is behind the times with collection classes and other library richness of everything from Java to Python -- what collection classes are there are also tied into the VCL and bloat non-GUI or GUI-non-VCL programs, and 3) well, Borland and the fact that everyone seems to be jumping off the Borland ship.
We all delete hard disk files, but they are never really completely deleted unless overwritten and then there may be some magnetic trace that some forensic dude could lift.
Just thing of it -- you can't delete a doc from parchment either without some CSI guy scanning it back in.
There was discussion on PBS about the threat to life and limb from explosions (command-detonated mines, IED's), the military-issue tourniquet was shown (a Velcro strap with a plastic handle for applying tension to the strap), and the controversy regarding distributing these medical devices to the ranks instead of only to trained medics was discussed. Watching PBS doesn't make anyone an expert, but to imply that what is reported on PBS is "complete and utter nonsense" is a rather serious critique.
There was an interview with a medic who had saved his own life with one of these devices. He spoke of how he was shot through the leg with an RPG that didn't explode and how he frantically injected himself with the morphine he had on hand so he could apply the tourniquet on himself before fainting. I don't think he went through the "elevation, pressure, pressure point" checklist as he said that he had only seconds to react before passing out, at which point he would have been doomed. Unfortunately, he lost his leg -- I am guessing from the seriousness of the injury than from the tourniquet.
I have no doubts that EMTs and paramedics regard tourniquets with disdain. Widespread issue of the tourniquet devices in Iraq in controversial, but the military surgeons say they are OK with that because of rapid response in getting injured soldiers to field hospitals. Time is of the essence in allowing the surgeon a chance to save the limb.
So why is are the Army and Marines handing out tourniquets to every Private while stateside paramedics wish first-aid providers never heard of such a device? It is the only effective medical response to the IED threat.
The funniest thing out of Peter Schickele was not about the fictitious P. D. Q. Bach but about the very real J. S. Bach. Schickele explained he was doing a poetic and musical tribute to J S Bach in the mode of Carl Sandburg's tribute to John Kennedy.
With Bach's music playing in the background, Schickele intones "These are the words of 'Jack' Bach, this is what he had to say . . . " and then reads from one of J S Bach's letters to a patron, complaining about not getting a promised level of compensation.
Like the GP post said, to be funny you have to know and love the material.
Generally, a tourniquet is a big no-no for first aid as taught by the Red Cross -- the notion is that the first aid provider is making a decision regarding the limb.
The thinking regarding tourniquets among the U.S. military in Iraq is that they have such a rapid response in getting a wounded soldier to a hospital that they are handing out tourniquets to the ranks. The belief is that most wounded will get to surgery fast enough that the effect of the tourniquet is not a factor in deciding to save the limb.
This device appears to make a decision regarding the limb -- it may be a last-resort measure for the field for perhaps an instrument for conducting surgery at the hospital.
I wanted to buy a box of 20 gauge shotgun shells, but that was in a glass case under lock and key while stacks of boxes of high-power 30 caliber hollow point cartridges were on open shelves in anticipation of deer season.
When I finally got someone at Wal Mart to open the glass case, the dude asked "how many boxes?" After the big production to get at them, I meekly asked for one box, but I thought of saying, "How bad a shot do you think I am?"
Back to the original topic, Brooks lists "High level languages" as a "Silver Bullet" -- they are perhaps not a silver bullet, but I am hard pressed to doing everything in macro assembler. OO is perhaps not a silver bullet, but I am so accustomed to that feature that I am reluctant to give that up either.
The one doubt I have about OO is that there will always be a need to bundle data with functions that operate on that data, and the Lisp/Haskell/OCaml people keep talking about closures and related things. I have the uneasy feeling that if OO is not the silver bullet it is then the silver hammer (everything looks like a nail) and that we are reinventing things that had been figured out in Lisp with OO, UML, Design Patterns, and all of the crazy things we do with objects.
If what your really need is to pass a pointer (OK, OK, reference) to a function conforming to a desired signature and what you end up doing is defining a class, creating an object instance, and passing an object reference to get such a thing to get at that one function, OO is the modern Cobol -- it has the functionality you need, but you have to type in a lot of boilerplate code to get it.
Useful as a first stage for an orbital craft
on
Blue Origin Will Be VTOL
·
· Score: 2, Insightful
While it would be nice to have a VTOL rocket craft that can reach Earth orbit, I think there will be more uses for this thing than people let on.
The Redstone rocket was far from capable of achieving orbit -- it was pretty much straight up and back down as you say. Wiley Ley writes that the Redstone in its missile application didn't have range beyond 200 miles. But what the Hunstville people did was put a cluster of solid-fuel rocket stages on top of it, and not only could they reproduce the flight path of the much longer range Jupiter rocket for doing tests, they could get small payloads into orbit. A Redstone first stage followed by three more stages of clustered solid fuel rockets stuck on top was the Jupiter C. Not very high performance but stupid, simple, and reliable for its day. Not only did it fly a test trajectory for the up and coming Jupiter missile (the Jupiter C was not the Jupiter -- it was a Jupiter wannabe), it was capable of earth orbit years before Sputnik, but Ike wanted to go with the untested Vanguard because he did not want to use Army rockets (Jupiter) to avoid militarizing space. Of course Korolev got there first with Sputnik, the Vanguard blew up a couple of times trying to get there next, the Huntsville Germans finally got to fly their Redstone and launch Explorer 1, and a physics professor from Iowa named James Van Allen became a household word.
I see Blue Origin as the new Redstone. If it provides a cheap, reusable access to suborbital space, it can act as a first stage to orbital craft for launching small payloads into orbit. Think of it, people have been talking about "flyback liquid-fueled boosters" for a long time -- this thing is a flyback booster.
The other smart thing about Blue Origin is that the people ride in a separate capsule. It would be neat if the whole thing took off vertically and then landed vertically on rocket thrust with the crew and passengers inside. But this way, if the capsule lands separately on parachutes and landing rockets in the style of Soyuz, you don't have to worry about the people if the guidance system burps on the main spacecraft and the thing crumps on landing. The fact that Blue Origin has a capsule on top makes it just like a Redstone -- in addition to putting Shepherd and Grissom into a suborbit, it was capable of lofting an upper stage to put small instrument packages into orbit.
I would develop or port the algorithms in C++. Numeric algorithms are the most portable, straightforward, readable form of C++ code. It is the GUI part that gets gnarly in C++.
I would do the UI in Matlab or at least keep the UI in Matlab because that is what the dude probably has. The thing to migrate the UI part in is Java Swing -- you can incorporate custom Java Swing widgets into a Matlab GUI.
What you really want for this project is Java. Really.
Matlab is morphing into a Java scripting language. You know why the Matlab UI takes so long to load these days? Its written in Java, so it needs to load a Java VM when it launches with all of the attendant byte code checking of loaded classes.
Did you know that you can launch Java apps from the Matlab command prompt? That you can also create object instances of individual Java classes and invoke function calls on them? That Matlab automatically manages conversions of array types between the Matlab environment and Java objects? That as of Matlab 7 that Matlab can host Java Swing widgets inside Figure Window GUI's in Matlab?
Forget about C++ GUI's, Python, Ruby, all the stuff people are telling you. Develop your application-specific widgets in Java Swing. Host them in your Matlab GUI for now. When you are ready, release stand-alone Java Swing apps using those same Java widgets. Continue to support Matlab as a scripting environment for your stuff.
Need to do some hard-core numerics in C++? The Java implementations may be fast enough. But if you really need C++, link into it from your Java widgets using JNI. You will need to compile your C++ modules for your different target platforms, but the compiled modules will have different names (YourModule.dll under Windows, libYourModule.so under Linux) so you can distribute all of the modules along with the Java class file that calls them and have cross-platform capability. The JNI takes some mastering, but it is no harder than what you do to write MEX files to call C/C++ directly from Matlab, and there are tons of documentation on the Web.
The people telling you to do a C++ GUI don't know what they are talking about -- you are probably doing a Matlab GUI and may be calling down to C++ in MEX functions. There are C++ solutions -- Qt, wxWidgets, (gasp, choke) MFC/ATL/WTL -- but they will look quited unfamiliar to what you are doing right now. Do your GUI as Swing widgets and you will get Matlab interoperability, a path to ween yourself from Matlab, and a way to operate on all the platforms that have Matlab.
First there was the Windows API, then there was COM and ActiveX and MFC, next there was.NET and WindowsForms.
What is this Windows Presentation Foundation? Do I want to learn it or should I go off and do Java and be done with Windows dependency? What is this Windows Presentation Foundation offering for the developer in terms of features to make it worth the while? WindowsForms actually offered fewer features apart from the more streamlined object-oriented framework.
This dude http://sitemaker.umich.edu/mhross has a report titled "Fuel efficiency and the Physics of Automobiles." You have to wade through a lot of formulas and SI units for otherwise familiar quantities, but I have put those formulas into an Excel sheet, and they are amazingly predictive of steady-state highway gas mileage.
The fundamental assumption is that just about all gas-engined cars run the same thermodynamic cycle and about the same compression ratio these days, so the non-ideal Otto cycle runs about 38 percent efficiency. Ross then presents an empirical model of both the manifold vacuum pumping loss and the mechanical friction losses in an engine as a function of speed and load; he also assumes that the transmission is 90 percent efficient, and there is a fixed power loss from engine accessories. Throw in the rolling resistance of a car, the aerodynamic drag, and voila, you get the steady-state highway cruise no-wind fuel economy.
Crunching the numbers on my 97 Camry 2.2 litre, using gas with 115,000 BTU/gal, 80 deg F air temp, no wind, I should get 41.7 MPG at 55 MPH, 40.1 at 60 MPH, and 37.5 MPG at 65 MPH. By comparison, I did a road test both ways on a short section of freeway at 55 MPH and averaged 41.1 MPG on a fuel mileage meter connected to the OBD-II, and I get about 36 MPG on trips where I travel 65.
You would think that the dominant loss at highway speed is the air drag, and going from 55 to 65 you are increasing in speed by 20 percent so your gas mileage should take a 40 percent hit. Well it does not, in large measure because the friction in your engine along with part-load manifold vacuum "pumping loss" in large measure tend to dominate. One way to manufacture vehicles with better highway mileage would be to use smaller engines turning over at slower speeds, and the formulas show that if I put a 0.8 litre engine in the Camry, I would get 47 MPG at 65 MPH but I would not have any reserve to climb a hill without downshifting.
The EPA has their Test Car List Data web page which gives car weight, engine displacement and final drive ratio, and drag coefficient values from which one can try out this model and make predictions of the steady-speed mileage of various cars. They give a coast down time from 55 to 45 MPG in seconds and they also give a dyno drag model of the form F = A + B V + C V^2 where A, B, C are numbers in their table and V is speed in MPH.
The funny thing about their A B C numbers is that some cars have anomolously low C numbers (the V^2 air drag) but suspiciously high B numbers (viscous drag of the transmission in neutral in a coastdown test?) and similar cars (like the Ford Taurus with two different 3 litre engines) have widely different ABC numbers and even noticably different coastdowns. I suspect the whole EPA testing procedures would not hold up to rigorous error analysis -- I wonder if anyone has done any sensitivity/numerical conditioning analysis on their procedure determining the ABC numbers used to program the dyno -- but like legislation and sausage making, you probably don't want to know what is going on.
According to TFA, the "shield" should be useful against a variety of threats, ranging from SCUD-like rockets to man-portable air-defense (MANPAD) shoulder-launched heat-seeking missiles.
You never know if the reporter got it right or if the publicist had an overactive imagination, but the big threat people are worried about is some dude hiding in the weeds and shooting one of those shoulder-launched heat-seeking missiles at an airliner trying to take off or land. There has been talk about equiping airliners with countermeasures against heat-seeking missiles.
The way the countermeasures are supposed to work is that most heat seekers are not full-fledged imaging devices but are instead rotating scan devices, and if you know the nature of the threat, you could pulse a heat source on and off to throw such a missile off target. I really think it is a stretch for a laser to stick in an airport control tower to actually shoot down a missile by zapping it with the laser. I think it would be a much safer thing, especially around a civilian airport, to spoof such a missle by pulsing it with IR to confuse the scanning seeker, or if that doesn't work, to blind an imaging sensor with a thermal pulse.
It kind of makes sense to provide a central, airport-based spoofer/blinder instead of having distributed spoofer/blinders on all of the aircraft. That avoids the old-aircraft retrofit problem, and the planes really only need this protection as they are landing and taking off -- those shoulder-launched missiles don't go very far. It would also make a lot of sense to provide protection against heat-seeking missiles because terrorists in theory could get a hold of them and they are small and portable to sneak around with. It would also make more sense that the laser system would be a spoofer/blinder kind of countermeasure rather than a Star Wars type of shoot-down ballistic missile defense.
Gee, you would think that the people who put that thing together were software developers for all of the unforseen failure path it exhibited.
After an interview by Max Faget where he talked about the very simple, clean interface between the Mercury and the Redstone consisting of a single umbilicle, I had used this as an example of what object-oriented software should strive for. But I guess even this simple interface had its bugs.
That the tail plug on the booster was too short and the booster shut down is one of these things that happens, and that is why you have the escape tower. But I hadn't realized that the space capsule (OK, OK, Mercury spacecraft -- the Russians have this word korabl which I guess translates as "cabin" meaning space capsule) and the escape tower were separate "object classes" that both had methods for "booster failure" but had separate specifications along with implementations of the "booster failure" method that caused them to go their own separate ways, and that no one thought through how those would interact.
Dunno. Since dentists have delegated the primary mouth-care to the hygienist, the hygienist gets to be the bad cop (Remember when hygienists were all young and cute and female? I guess they are all female even though there are now many men flight attendants and even a good number of men nurses. But they have got older and more school-marmish.). The dentist is the good cop, swoops into the room after the hygienist has rinsed all of the blood off your gums, the dentist comes in, probes your old fillings with the explorer for a few seconds, tells you how great your teeth are -- with fluoride, for most of us, teeth are pretty good, the gums are what will get you -- and then swoops out.
As a student pilot I had one of the phase-checks with the head of the flight school who did the FAA tests. I was told in my training that I could hand things to passengers -- maps, pencils, kneeboards, etc to aid with management of what I needed in the cockpit, so I handed the examiner one of those Pentel mechanical pencils I was using to copy air traffic instructions, to get it out of my hands.
Anyway, he was playing with it, clicked out about an inch of lead, and then announced "I broke your pencil." I called out "give me that thing", in one swipe grabbed it, with one hand worked the clicker and stuffed the lead back in, and stuck the pencil in my pocket. I thought he was being an idiot, but on reflection I was worried that I was rude with the FAA guy.
I read later that the FAA examiner is supposed to create a distraction in the cockpit to see if you, well, get distracted by it and let the plane split-S into a corn field while you are fiddling with the distraction. I guess I sort of passed the test by exercising my authority as Pilot-in-Command, ordering my passenger to give back the pencil, and maintaining control over both the plane as well as the pencil I used for copying instructions. But I still feel bad that I was rude to the FAA guy.
The bad health effect of fried chicken is that the high fat content will clog your arteries, leading to a clot that will stop your heart, cause a stroke in your brain, or cause you to lose a leg.
Now if they put a little rat poison in it (Warfarin, Coumadin), well rat poison of this kind is actually used in the treatment of people with clogged arteries to prevent stroke, heart attack, and other clot damage. Maybe if they put the right amount of rat poison in the fried chicken, it would counteract the bad effect of the fat and make for an even slightly healthful product.
The Tucker automobile was manufactured in quantity 50, and every last one of them became a coveted, high-priced collectors item. Tucker (was he played by Jeff Bridges in a movie?) was kind of the John DeLorean of his day -- high-styled, high-living, high-ego, and got in trouble with the law.
The Chrysler Turbine car of the mid 1960s was given out for trials by dealers and loyal Chrysler customers, collected, and cut up for scrap. The excuse not to save even one for a museum was that they avoided paying hefty import duties on the imported, stylish bodies, hand made in Italy.
Apart from the discussion of GM having legal liability, liability to provide parts, etc, I kind of think a reason was that whoever bought one of those cars would have been effectively handed a 6-figure check -- what that thing would be worth to a collector -- for its exotic nature and its unique place in technological and social history.
Think of me as a customer who drives a Delphi, coming into the showroom to look at a Java and compare it with a Python, and perhaps there is another model that I don't know about, and decide which one to start making payments on and drive home. From the response to my remarks, I feel like I was thinking out loud about why I was leaning towards the Java and a raft of salesmen came out to tell me I was ill-informed about cars.
I have experimented with Python, and Python is great. But it lacks an intrinsic array type, and arrays are as necessary as oxygen for numeric, audio signal processing, frame buffer graphics/image processing, and related work. Yes, there is NumArray and Numeric and NumPy, but a defined array type is a work in progress and there is far from universal adoption of any of them with frame buffer packages. Python is compared with Lisp, and even Lisp came around to having an array type which I understand was well-implemented with slices and all of that, but the Python array situation remains a work in progress. Java on the other hand has an intrinsic array type -- arrays are objects, but they are special types of objects where iterating over the subelements is almost as fast as native code.
Matlab -- very popular in the scientific community for data visualization -- also has intrinsic array types and is highly interoperable with Java and interoperable between the Matlab and Java array types. While there is a movement to develop libraries to make Python a FOSS alternative to Matlab, Python and Matlab don't readily interoperate, and Python doesn't interoperate with Java unless you go the Jython route, which is almost a whole other language, or go with some JNI support packages from CPython that are not actively supported.
Java has the much maligned Swing, but the BufferedImage class and the Graphics.copyArea() method are pretty much direct replacements for CreateDIBSection (frame buffer support) and ScrollWindowEx() (scrolling) in Windows -- I don't see anything equivalent in wxPython or in.NET/Mono/C# apart from "unsafe code" for that matters.
So people tell me the browser, not Java is the platform. Great, I am going to have to figure out how to blast arrays to frame buffers in AJAX and get those images to scroll.
Maybe I am jumping on the Java bandwagon too early -- maybe there is this product/project for implementing scientific data visualization called Python on Steroids, Matlab only following sound software development principles, that is this really well integrated object framework for such apps that is just coming out. Don't know. What I do know is that everything has its product development cycle, and Windows flopped around as a toy for 10 years (Windows app: Dog slow! RAM hungry! I can do graphical apps with mouse selection in DOS (I actually went that route)! They are much faster! DOS games, data visualization, even word processors were much faster in DOS). Then Windows 95 came along. Java is about at the same depth into its development cycle.
Python? That too has a development cycle. Maybe in a couple years it will have the features I want. Maybe I should ignore Java and wait for Python to come around.
My point is that everything has its development cycle and it can take a long, long time for products to reach maturity. Java look and feel all wrong, load times too long? There was a time when Windows was a wart on top of DOS with all of those odd fonts that didn't look right on the low resolution monitors of the day, and you had to run Windows first before you could run your Windows app.
Java, like pre-Windows 95, is a wart on top of the OS that seems foreign to the native OS, but it is a wart that runs on top of multiple OS's. Windows was an abstraction of the underlying PC, and oh the complaints about resource usage, slowness, and loss of access to the hardware and especially the graphics frame buffer. Windows fixed that with a combination of Moore's Law and the WinG initiative and later DirectX to
Maple syrup production takes place during times when the sap is running -- I remember pruning a birch tree a little too early in Spring and having sap bleed out all over the place. You need weather conditions where it freezes at night and thaws by day to get the tree to start pumping its stored sugar stores from the roots out to the budding leaves -- or at least that is what the literature from Extension tells me.
You sometimes get ice in the pails hung on the taps, and pulling out those ice chunks helps increase the sugar test of the sap input to your evaporator. But you are not producing in a season when you have a hard freeze, the season for sap is short so you have to produce syrup like crazy, and while it may be technically possible to use nighttime freezing for sap concentration, no one has worked out the details of such a system.
Why use wood or oil-fired evaporators instead of the multi-effect evaporators or the vapor compression equipment of the cane sugar industry? Well, you are talking a really short season, and you just don't get enough use out of such equipment to pay off the loan
These days, I believe just about everyone in the syrup business has given up on oil-fired single-effect evaporators -- they made sense at 50 cent/gallon oil, not at 3 dollar a gallon oil. Reverse osmosis is what everyone has gone to -- much, much more energy efficient, and the price of the units has come way down, and they are the right scale for maple syrup operations (you can't ship sap to a coop on account of spoilage -- it gets made into syrup on site).
Reverse osmosis (RO) doesn't take you all the way to syrup on account of that pesky osmotic pressure the high viscosity of syrup -- nearly pure sugar with a little water to make it liquid -- they have to finish with either wood or propane-fired finishing pans. I have read that vapor compression can go all the way to syrup in one step -- sap in one pipe, syrup out another pipe -- but vapor compression equipment apparently doesn't scale down to the size and cost for the single-farm operation.
It takes about 1000 BTU's to evaporate a pound of water, and about 1000 BTU's are given up when that water condenses. Assuming 140,000 BTU (don't know if it is the high or low heating value, which also depends on water condensation from the H2O of combustion) for a gallon of Diesel fuel, a gallon of Diesel can evaporate 140 pounds or about 18 gallons of water. For people making maple syrup by direct evaporation (requires 30-40 to 1 concentration), it takes about two gallons of Diesel to make a gallon of maple syrup (an appetizing thought when you pour that syrup on your pancakes).
That ocean water scheme is taking much lower grade heat, thermodynamically, than the energy in Diesel fuel, but it still requires 1000 BTU's of heat per pound of water (8000 BTU's per gallon). That is a lot of heat to take out of the environment, and a lot of heat to transfer.
Another way for more efficient desalination is to recycle that 1000 BTU/lb -- use 1000 BTU to evaporate a pound of water to purify it and then condense that water vapor to get back that heat to evaporate more water. Trouble is that water condenses at the same temperature it evaporates, and you need at least a small temperature differential to get heat to flow downhill.
There are two approaches to recycling the heat. One approach is multi-effect distillation. You evaporate at a higher temperature and pressure, and then condense at that same temperature, which you use to evaporate other water at a lower temperature and pressure in a vacuum chamber. You have a cascade of evaporators at successively lower pressures and keep reusing the same heat. This method was developed by Norbert Rillieux, the Louisiana son of a French engineer and an American former slave, and is widely used in food preparation -- sugar from cane or beets, orange juice concentrate, and so on.
The second approach is vapor compression. You boil at one temperature, but you condense at a higher temperature by compressing the vapor to a higher pressure using something akin to an automotive supercharger driven by an electric motor, and that way the heat from condensing at a slightly higher temperature and pressure is recovered by the evaporator. This requires only a single "effect" on account of the vapor pump instead of the multi-effect cascade into successively lower pressure chambers, but it needs the electric motor and vapor pump, and you need to move a lot of heat at low temperature differentials across large surface area plate heat exchangers.
Reverse osmosis is a pure mechanical process that doesn't require exchange of the 1000 BTUs per pound of water, but the osmosis membrane offers resistance to pumping in excess of the natural osmotic pressure (the pressure differential required to overcome the salinity differential, the PV work representing the true thermodynamic cost of desalinating the water, which is much less than the 1000 BTU's per pound). By the way, it is always more cost effective to desalinate slightly-salty (brackish) water from marshes or irrigation runoff or other sources than going for the highly-salty sea water on account of the energy inherent in the dissolved salt as reflected in the higher osmotic pressure).
I think the argument the lawn-waterers are making is that if they pump water out of the ground and sprinkle that water back on the lawn, most of that water will percolate back through the soil back into the ground water. Whether that argument holds up or not depends on such factors as the rate of transpiration and evaporation off the grass, whether the runoff water percolates back into the ground water reservoir or runs off somewhere else. That paper mill may be sucking the water out of the ground and then discharging it in polluted form in a stream, thus depleting the water table.
I am hard pressed that anyone living where there is normal rainfall for growing grass (i.e. Georgia) and has a water table high enough to tap with a private well isn't simply recycling the water by pumping it from below and discharging it on the surface. In fact, ground-source heat pumps are the next big thing in saving energy resources -- some of the systems are closed loop with a coil to pipe in the ground, other systems are open loop, lifting water from a well and discharging it on the surface. The various state DNR's that issue permits for such open loop systems want you to discharge on the surface -- they certainly don't want you pumping water that you have handled directly back into the aquifer without being filtered through the ground.
I agree that lawn watering is a serious use of resources in the desert Southwest U.S. You can be Fremen in your view of lawns on Arrakis, but to argue the same point on Caladan is stretching matters a bit far.
What makes you think Java won't rule the client?
on
The End of Native Code?
·
· Score: 4, Interesting
A lot of people are dismissive of Java as having failed on client GUI apps. What is it now, 2006, and Java came out around 1996? I know we talk about "Internet time", but major software concepts can take years to evolve, and Windows started out sometime in the 1980's but it wasn't until Windows 95 that it started kicking backsides and taking names. So maybe Java will eventually have its day.
I am a Pascal programmer from ancient days and have been pretty much a Delphi person on account of my Pascal affinity and other requirements, but I have implemented GUI apps in C++, C#, Java, Matlab, and VB. I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi. Java simply couldn't do in 1997 what I was doing even at that time in Windows, just plain couldn't from the standpoint of features and performances. Java is not-quite-there-yet with the features I use in Windows, but it is much farther along in 2006 than in 1997 and is closing the gap with graphics acceleration and other features. It may surpass Delphi for what I do if it proves to be easier to do multi-threaded apps to take advantage of multi-core.
While my complex data visualization stuff is a long way off from being done in Java, the sort of simple data visualization stuff that I was doing in 1997 under Windows works quite well under Java, and it works equally well under Linux. If anything will get me to switch to Linux it will be that I have a collection of graphical data visualiztion programs for the work I do written in Java that will work equally well under Linux. While I can write a faster program with more features in Windows, the Java implementation is proving good enough for a lot of stuff that I am doing and it breaks me loose from Windows as well.
SUN seems to be in this Java business for the long haul, seemingly spinning their wheels making it available for free and always being a step behind Windows in features. But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows. This idea that something like Java could transcend the OS may yet happen for client GUI apps.
Maybe what is needed is a dual source code -- one source code specifying what is supposed to happen (specification) and another source code specifying how it is supposed to happen (algorithm). If you had a complete specification, you would think you could automatically generate the algorithm, but in that case, your specification would be a form of programming and would have to be airtight.
But why does the specification have to be a one-to-one mapping into the algorithm? Couldn't the specification be of the form of an assertion? An assertion is a form a runtime test case, and test cases are never exhaustive with regards to what a program does -- otherwise you could form test cases as the specification and automatically generate code from that, although there seems to be a programming style of generate the test cases first and have code monkeys pound on typewriters until they pass the test cases.
So instead of a traditional assertion -- a runtime test case written into the code -- you have a compile time assertion. The assertion could be that for int i, int j, at a certain point in the code i = j, and the result could be true, false, or undecidable. There is a little of that built into compilers today -- warning messages about assigning a value to a variable and never using it, catching uninitialized variables (some of the time), and the like.
Slashdot Mirror
The notion behind a coffin corner is that if you fly high enough, you run out of margin. Say you encounter stall onset. Well, you lower the nose, gain speed and then encounter aeroelastic flutter or some other kind of problem. The only way to recover is to lose altitude, but it may be a problem losing altitude in a graceful way without loss of control of the aircraft.
Don't know if most aircraft apart from X-planes and some high-performance military craft even have this effect -- they may lack the performance to get to that "corner" of the speed-altitude flight envelope.
On the original topic, if the airlines serve enough water and if they allow you to bring (dry) foods, my hungry self and people with real medical issues will be OK, its just that airline hospitality has gotten thinner.
Forget about toothpaste. What about, like, packing a lunch -- bottled water, yogurt, some energy bars? Its not like you get anything to eat on the plane anymore, and if you load up on fluids so you don't dehydrate (an issue in the dry, thin cabin air), well, they don't let you go potty on the approach to Washington National.
So I guess the flight experience will be like the Ramadan fast -- no fluids, no food -- for X hours, only X may be unpredictable and open ended given flight delays. A multi-hour no-fluid no-food fast is doable for multi-hours, but we are talking about in an environment where you don't want to be dehydrated because 1) dry-thin air, 2) the cramped seats where you are vulnerable to deep-vein thrombosis, 3) you are packed in with strangers sharing their nasal viruses. So it will be like Ramadan combined with the Hadj.
So the coffin corner is you can't pack lunch, and they won't serve you lunch, so you can sit there and be hungry and thirsty.
The other part of it could be the Anders Heljsberg is an evil genius who just knew how to craft parsers and compilers better than anyone else. The evil part is that a claim has been made in these parts that the actual Delphi Object Pascal grammer doesn't have a spec the way the original Wirthian railroad tracks Pascal grammer did -- the Delphi grammer is supposedly proprietary and a trade secret, and that no one else can build a parser that handles all of the corner cases -- you might want a parser, not to build a competing Delphi but to build a smart editor, use Object Pascal has a kind of description language, etc.
But if you think Anders Heljsberg a genius, evil or otherwise, how come C++ Builder is dog slow on compiles in comparison. There has to be something to the Pascal language.
I am kinda switching over to Java Swing for the GUI, C++ through the JNI for the hardcore numeric stuff -- a person sees the handwriting on the wall about Borland longevity. I kinda want to get off Windows by the time Vista, Aero, and whatever Windows-specific GUI gobbeldygook takes hold, and Java looks attractive to me. It is easy to get spoiled by GC and some other Java hacks, but I miss the fast compiles -- javac is dog slow.
It seemed that Eclipse has a lightning-fast Java compiler in it -- someone told that it doesn't use javac but uses some hot-rodded IBM thingy. Eclipse, on the other hand, is still something I am struggling with -- it is IBMish in its weirdness about a whole bunch of stuff -- how do you just take a bunch of .java files in a directory and call it a project? It doesn't like a directory that is already there, and it wants to create some other directory in some standard location instead of where you want it. Still working on that one. So even Java needs "make files" of some kind of external metadata to organize multi-file source codes. Object Pascal famously has all of the dependencies specified in source code as a feature of the language.
If there are two features, no, make that three features! that make Delphi problematic for the future, they are 1) Delphi has some real solid Windows lock-in, especially since Kylix didn't go anywhere -- the Delphi extension to Pascal are quite Windows-specific even if you are not doing GUI programming, 2) while Delphi is great and everything, it is behind the times with collection classes and other library richness of everything from Java to Python -- what collection classes are there are also tied into the VCL and bloat non-GUI or GUI-non-VCL programs, and 3) well, Borland and the fact that everyone seems to be jumping off the Borland ship.
Just thing of it -- you can't delete a doc from parchment either without some CSI guy scanning it back in.
There was an interview with a medic who had saved his own life with one of these devices. He spoke of how he was shot through the leg with an RPG that didn't explode and how he frantically injected himself with the morphine he had on hand so he could apply the tourniquet on himself before fainting. I don't think he went through the "elevation, pressure, pressure point" checklist as he said that he had only seconds to react before passing out, at which point he would have been doomed. Unfortunately, he lost his leg -- I am guessing from the seriousness of the injury than from the tourniquet.
I have no doubts that EMTs and paramedics regard tourniquets with disdain. Widespread issue of the tourniquet devices in Iraq in controversial, but the military surgeons say they are OK with that because of rapid response in getting injured soldiers to field hospitals. Time is of the essence in allowing the surgeon a chance to save the limb.
So why is are the Army and Marines handing out tourniquets to every Private while stateside paramedics wish first-aid providers never heard of such a device? It is the only effective medical response to the IED threat.
With Bach's music playing in the background, Schickele intones "These are the words of 'Jack' Bach, this is what he had to say . . . " and then reads from one of J S Bach's letters to a patron, complaining about not getting a promised level of compensation.
Like the GP post said, to be funny you have to know and love the material.
The thinking regarding tourniquets among the U.S. military in Iraq is that they have such a rapid response in getting a wounded soldier to a hospital that they are handing out tourniquets to the ranks. The belief is that most wounded will get to surgery fast enough that the effect of the tourniquet is not a factor in deciding to save the limb.
This device appears to make a decision regarding the limb -- it may be a last-resort measure for the field for perhaps an instrument for conducting surgery at the hospital.
When I finally got someone at Wal Mart to open the glass case, the dude asked "how many boxes?" After the big production to get at them, I meekly asked for one box, but I thought of saying, "How bad a shot do you think I am?"
Back to the original topic, Brooks lists "High level languages" as a "Silver Bullet" -- they are perhaps not a silver bullet, but I am hard pressed to doing everything in macro assembler. OO is perhaps not a silver bullet, but I am so accustomed to that feature that I am reluctant to give that up either.
The one doubt I have about OO is that there will always be a need to bundle data with functions that operate on that data, and the Lisp/Haskell/OCaml people keep talking about closures and related things. I have the uneasy feeling that if OO is not the silver bullet it is then the silver hammer (everything looks like a nail) and that we are reinventing things that had been figured out in Lisp with OO, UML, Design Patterns, and all of the crazy things we do with objects.
If what your really need is to pass a pointer (OK, OK, reference) to a function conforming to a desired signature and what you end up doing is defining a class, creating an object instance, and passing an object reference to get such a thing to get at that one function, OO is the modern Cobol -- it has the functionality you need, but you have to type in a lot of boilerplate code to get it.
The Redstone rocket was far from capable of achieving orbit -- it was pretty much straight up and back down as you say. Wiley Ley writes that the Redstone in its missile application didn't have range beyond 200 miles. But what the Hunstville people did was put a cluster of solid-fuel rocket stages on top of it, and not only could they reproduce the flight path of the much longer range Jupiter rocket for doing tests, they could get small payloads into orbit. A Redstone first stage followed by three more stages of clustered solid fuel rockets stuck on top was the Jupiter C. Not very high performance but stupid, simple, and reliable for its day. Not only did it fly a test trajectory for the up and coming Jupiter missile (the Jupiter C was not the Jupiter -- it was a Jupiter wannabe), it was capable of earth orbit years before Sputnik, but Ike wanted to go with the untested Vanguard because he did not want to use Army rockets (Jupiter) to avoid militarizing space. Of course Korolev got there first with Sputnik, the Vanguard blew up a couple of times trying to get there next, the Huntsville Germans finally got to fly their Redstone and launch Explorer 1, and a physics professor from Iowa named James Van Allen became a household word.
I see Blue Origin as the new Redstone. If it provides a cheap, reusable access to suborbital space, it can act as a first stage to orbital craft for launching small payloads into orbit. Think of it, people have been talking about "flyback liquid-fueled boosters" for a long time -- this thing is a flyback booster.
The other smart thing about Blue Origin is that the people ride in a separate capsule. It would be neat if the whole thing took off vertically and then landed vertically on rocket thrust with the crew and passengers inside. But this way, if the capsule lands separately on parachutes and landing rockets in the style of Soyuz, you don't have to worry about the people if the guidance system burps on the main spacecraft and the thing crumps on landing. The fact that Blue Origin has a capsule on top makes it just like a Redstone -- in addition to putting Shepherd and Grissom into a suborbit, it was capable of lofting an upper stage to put small instrument packages into orbit.
I would do the UI in Matlab or at least keep the UI in Matlab because that is what the dude probably has. The thing to migrate the UI part in is Java Swing -- you can incorporate custom Java Swing widgets into a Matlab GUI.
Matlab is morphing into a Java scripting language. You know why the Matlab UI takes so long to load these days? Its written in Java, so it needs to load a Java VM when it launches with all of the attendant byte code checking of loaded classes.
Did you know that you can launch Java apps from the Matlab command prompt? That you can also create object instances of individual Java classes and invoke function calls on them? That Matlab automatically manages conversions of array types between the Matlab environment and Java objects? That as of Matlab 7 that Matlab can host Java Swing widgets inside Figure Window GUI's in Matlab?
Forget about C++ GUI's, Python, Ruby, all the stuff people are telling you. Develop your application-specific widgets in Java Swing. Host them in your Matlab GUI for now. When you are ready, release stand-alone Java Swing apps using those same Java widgets. Continue to support Matlab as a scripting environment for your stuff.
Need to do some hard-core numerics in C++? The Java implementations may be fast enough. But if you really need C++, link into it from your Java widgets using JNI. You will need to compile your C++ modules for your different target platforms, but the compiled modules will have different names (YourModule.dll under Windows, libYourModule.so under Linux) so you can distribute all of the modules along with the Java class file that calls them and have cross-platform capability. The JNI takes some mastering, but it is no harder than what you do to write MEX files to call C/C++ directly from Matlab, and there are tons of documentation on the Web.
The people telling you to do a C++ GUI don't know what they are talking about -- you are probably doing a Matlab GUI and may be calling down to C++ in MEX functions. There are C++ solutions -- Qt, wxWidgets, (gasp, choke) MFC/ATL/WTL -- but they will look quited unfamiliar to what you are doing right now. Do your GUI as Swing widgets and you will get Matlab interoperability, a path to ween yourself from Matlab, and a way to operate on all the platforms that have Matlab.
What is this Windows Presentation Foundation? Do I want to learn it or should I go off and do Java and be done with Windows dependency? What is this Windows Presentation Foundation offering for the developer in terms of features to make it worth the while? WindowsForms actually offered fewer features apart from the more streamlined object-oriented framework.
The fundamental assumption is that just about all gas-engined cars run the same thermodynamic cycle and about the same compression ratio these days, so the non-ideal Otto cycle runs about 38 percent efficiency. Ross then presents an empirical model of both the manifold vacuum pumping loss and the mechanical friction losses in an engine as a function of speed and load; he also assumes that the transmission is 90 percent efficient, and there is a fixed power loss from engine accessories. Throw in the rolling resistance of a car, the aerodynamic drag, and voila, you get the steady-state highway cruise no-wind fuel economy.
Crunching the numbers on my 97 Camry 2.2 litre, using gas with 115,000 BTU/gal, 80 deg F air temp, no wind, I should get 41.7 MPG at 55 MPH, 40.1 at 60 MPH, and 37.5 MPG at 65 MPH. By comparison, I did a road test both ways on a short section of freeway at 55 MPH and averaged 41.1 MPG on a fuel mileage meter connected to the OBD-II, and I get about 36 MPG on trips where I travel 65.
You would think that the dominant loss at highway speed is the air drag, and going from 55 to 65 you are increasing in speed by 20 percent so your gas mileage should take a 40 percent hit. Well it does not, in large measure because the friction in your engine along with part-load manifold vacuum "pumping loss" in large measure tend to dominate. One way to manufacture vehicles with better highway mileage would be to use smaller engines turning over at slower speeds, and the formulas show that if I put a 0.8 litre engine in the Camry, I would get 47 MPG at 65 MPH but I would not have any reserve to climb a hill without downshifting.
The EPA has their Test Car List Data web page which gives car weight, engine displacement and final drive ratio, and drag coefficient values from which one can try out this model and make predictions of the steady-speed mileage of various cars. They give a coast down time from 55 to 45 MPG in seconds and they also give a dyno drag model of the form F = A + B V + C V^2 where A, B, C are numbers in their table and V is speed in MPH.
The funny thing about their A B C numbers is that some cars have anomolously low C numbers (the V^2 air drag) but suspiciously high B numbers (viscous drag of the transmission in neutral in a coastdown test?) and similar cars (like the Ford Taurus with two different 3 litre engines) have widely different ABC numbers and even noticably different coastdowns. I suspect the whole EPA testing procedures would not hold up to rigorous error analysis -- I wonder if anyone has done any sensitivity/numerical conditioning analysis on their procedure determining the ABC numbers used to program the dyno -- but like legislation and sausage making, you probably don't want to know what is going on.
You never know if the reporter got it right or if the publicist had an overactive imagination, but the big threat people are worried about is some dude hiding in the weeds and shooting one of those shoulder-launched heat-seeking missiles at an airliner trying to take off or land. There has been talk about equiping airliners with countermeasures against heat-seeking missiles.
The way the countermeasures are supposed to work is that most heat seekers are not full-fledged imaging devices but are instead rotating scan devices, and if you know the nature of the threat, you could pulse a heat source on and off to throw such a missile off target. I really think it is a stretch for a laser to stick in an airport control tower to actually shoot down a missile by zapping it with the laser. I think it would be a much safer thing, especially around a civilian airport, to spoof such a missle by pulsing it with IR to confuse the scanning seeker, or if that doesn't work, to blind an imaging sensor with a thermal pulse.
It kind of makes sense to provide a central, airport-based spoofer/blinder instead of having distributed spoofer/blinders on all of the aircraft. That avoids the old-aircraft retrofit problem, and the planes really only need this protection as they are landing and taking off -- those shoulder-launched missiles don't go very far. It would also make a lot of sense to provide protection against heat-seeking missiles because terrorists in theory could get a hold of them and they are small and portable to sneak around with. It would also make more sense that the laser system would be a spoofer/blinder kind of countermeasure rather than a Star Wars type of shoot-down ballistic missile defense.
After an interview by Max Faget where he talked about the very simple, clean interface between the Mercury and the Redstone consisting of a single umbilicle, I had used this as an example of what object-oriented software should strive for. But I guess even this simple interface had its bugs.
That the tail plug on the booster was too short and the booster shut down is one of these things that happens, and that is why you have the escape tower. But I hadn't realized that the space capsule (OK, OK, Mercury spacecraft -- the Russians have this word korabl which I guess translates as "cabin" meaning space capsule) and the escape tower were separate "object classes" that both had methods for "booster failure" but had separate specifications along with implementations of the "booster failure" method that caused them to go their own separate ways, and that no one thought through how those would interact.
Dunno. Since dentists have delegated the primary mouth-care to the hygienist, the hygienist gets to be the bad cop (Remember when hygienists were all young and cute and female? I guess they are all female even though there are now many men flight attendants and even a good number of men nurses. But they have got older and more school-marmish.). The dentist is the good cop, swoops into the room after the hygienist has rinsed all of the blood off your gums, the dentist comes in, probes your old fillings with the explorer for a few seconds, tells you how great your teeth are -- with fluoride, for most of us, teeth are pretty good, the gums are what will get you -- and then swoops out.
Anyway, he was playing with it, clicked out about an inch of lead, and then announced "I broke your pencil." I called out "give me that thing", in one swipe grabbed it, with one hand worked the clicker and stuffed the lead back in, and stuck the pencil in my pocket. I thought he was being an idiot, but on reflection I was worried that I was rude with the FAA guy.
I read later that the FAA examiner is supposed to create a distraction in the cockpit to see if you, well, get distracted by it and let the plane split-S into a corn field while you are fiddling with the distraction. I guess I sort of passed the test by exercising my authority as Pilot-in-Command, ordering my passenger to give back the pencil, and maintaining control over both the plane as well as the pencil I used for copying instructions. But I still feel bad that I was rude to the FAA guy.
Now if they put a little rat poison in it (Warfarin, Coumadin), well rat poison of this kind is actually used in the treatment of people with clogged arteries to prevent stroke, heart attack, and other clot damage. Maybe if they put the right amount of rat poison in the fried chicken, it would counteract the bad effect of the fat and make for an even slightly healthful product.
The Chrysler Turbine car of the mid 1960s was given out for trials by dealers and loyal Chrysler customers, collected, and cut up for scrap. The excuse not to save even one for a museum was that they avoided paying hefty import duties on the imported, stylish bodies, hand made in Italy.
Apart from the discussion of GM having legal liability, liability to provide parts, etc, I kind of think a reason was that whoever bought one of those cars would have been effectively handed a 6-figure check -- what that thing would be worth to a collector -- for its exotic nature and its unique place in technological and social history.
I have experimented with Python, and Python is great. But it lacks an intrinsic array type, and arrays are as necessary as oxygen for numeric, audio signal processing, frame buffer graphics/image processing, and related work. Yes, there is NumArray and Numeric and NumPy, but a defined array type is a work in progress and there is far from universal adoption of any of them with frame buffer packages. Python is compared with Lisp, and even Lisp came around to having an array type which I understand was well-implemented with slices and all of that, but the Python array situation remains a work in progress. Java on the other hand has an intrinsic array type -- arrays are objects, but they are special types of objects where iterating over the subelements is almost as fast as native code.
Matlab -- very popular in the scientific community for data visualization -- also has intrinsic array types and is highly interoperable with Java and interoperable between the Matlab and Java array types. While there is a movement to develop libraries to make Python a FOSS alternative to Matlab, Python and Matlab don't readily interoperate, and Python doesn't interoperate with Java unless you go the Jython route, which is almost a whole other language, or go with some JNI support packages from CPython that are not actively supported.
Java has the much maligned Swing, but the BufferedImage class and the Graphics.copyArea() method are pretty much direct replacements for CreateDIBSection (frame buffer support) and ScrollWindowEx() (scrolling) in Windows -- I don't see anything equivalent in wxPython or in .NET/Mono/C# apart from "unsafe code" for that matters.
So people tell me the browser, not Java is the platform. Great, I am going to have to figure out how to blast arrays to frame buffers in AJAX and get those images to scroll.
Maybe I am jumping on the Java bandwagon too early -- maybe there is this product/project for implementing scientific data visualization called Python on Steroids, Matlab only following sound software development principles, that is this really well integrated object framework for such apps that is just coming out. Don't know. What I do know is that everything has its product development cycle, and Windows flopped around as a toy for 10 years (Windows app: Dog slow! RAM hungry! I can do graphical apps with mouse selection in DOS (I actually went that route)! They are much faster! DOS games, data visualization, even word processors were much faster in DOS). Then Windows 95 came along. Java is about at the same depth into its development cycle.
Python? That too has a development cycle. Maybe in a couple years it will have the features I want. Maybe I should ignore Java and wait for Python to come around.
My point is that everything has its development cycle and it can take a long, long time for products to reach maturity. Java look and feel all wrong, load times too long? There was a time when Windows was a wart on top of DOS with all of those odd fonts that didn't look right on the low resolution monitors of the day, and you had to run Windows first before you could run your Windows app.
Java, like pre-Windows 95, is a wart on top of the OS that seems foreign to the native OS, but it is a wart that runs on top of multiple OS's. Windows was an abstraction of the underlying PC, and oh the complaints about resource usage, slowness, and loss of access to the hardware and especially the graphics frame buffer. Windows fixed that with a combination of Moore's Law and the WinG initiative and later DirectX to
You sometimes get ice in the pails hung on the taps, and pulling out those ice chunks helps increase the sugar test of the sap input to your evaporator. But you are not producing in a season when you have a hard freeze, the season for sap is short so you have to produce syrup like crazy, and while it may be technically possible to use nighttime freezing for sap concentration, no one has worked out the details of such a system.
Why use wood or oil-fired evaporators instead of the multi-effect evaporators or the vapor compression equipment of the cane sugar industry? Well, you are talking a really short season, and you just don't get enough use out of such equipment to pay off the loan
These days, I believe just about everyone in the syrup business has given up on oil-fired single-effect evaporators -- they made sense at 50 cent/gallon oil, not at 3 dollar a gallon oil. Reverse osmosis is what everyone has gone to -- much, much more energy efficient, and the price of the units has come way down, and they are the right scale for maple syrup operations (you can't ship sap to a coop on account of spoilage -- it gets made into syrup on site).
Reverse osmosis (RO) doesn't take you all the way to syrup on account of that pesky osmotic pressure the high viscosity of syrup -- nearly pure sugar with a little water to make it liquid -- they have to finish with either wood or propane-fired finishing pans. I have read that vapor compression can go all the way to syrup in one step -- sap in one pipe, syrup out another pipe -- but vapor compression equipment apparently doesn't scale down to the size and cost for the single-farm operation.
That ocean water scheme is taking much lower grade heat, thermodynamically, than the energy in Diesel fuel, but it still requires 1000 BTU's of heat per pound of water (8000 BTU's per gallon). That is a lot of heat to take out of the environment, and a lot of heat to transfer.
Another way for more efficient desalination is to recycle that 1000 BTU/lb -- use 1000 BTU to evaporate a pound of water to purify it and then condense that water vapor to get back that heat to evaporate more water. Trouble is that water condenses at the same temperature it evaporates, and you need at least a small temperature differential to get heat to flow downhill.
There are two approaches to recycling the heat. One approach is multi-effect distillation. You evaporate at a higher temperature and pressure, and then condense at that same temperature, which you use to evaporate other water at a lower temperature and pressure in a vacuum chamber. You have a cascade of evaporators at successively lower pressures and keep reusing the same heat. This method was developed by Norbert Rillieux, the Louisiana son of a French engineer and an American former slave, and is widely used in food preparation -- sugar from cane or beets, orange juice concentrate, and so on.
The second approach is vapor compression. You boil at one temperature, but you condense at a higher temperature by compressing the vapor to a higher pressure using something akin to an automotive supercharger driven by an electric motor, and that way the heat from condensing at a slightly higher temperature and pressure is recovered by the evaporator. This requires only a single "effect" on account of the vapor pump instead of the multi-effect cascade into successively lower pressure chambers, but it needs the electric motor and vapor pump, and you need to move a lot of heat at low temperature differentials across large surface area plate heat exchangers.
Reverse osmosis is a pure mechanical process that doesn't require exchange of the 1000 BTUs per pound of water, but the osmosis membrane offers resistance to pumping in excess of the natural osmotic pressure (the pressure differential required to overcome the salinity differential, the PV work representing the true thermodynamic cost of desalinating the water, which is much less than the 1000 BTU's per pound). By the way, it is always more cost effective to desalinate slightly-salty (brackish) water from marshes or irrigation runoff or other sources than going for the highly-salty sea water on account of the energy inherent in the dissolved salt as reflected in the higher osmotic pressure).
I am hard pressed that anyone living where there is normal rainfall for growing grass (i.e. Georgia) and has a water table high enough to tap with a private well isn't simply recycling the water by pumping it from below and discharging it on the surface. In fact, ground-source heat pumps are the next big thing in saving energy resources -- some of the systems are closed loop with a coil to pipe in the ground, other systems are open loop, lifting water from a well and discharging it on the surface. The various state DNR's that issue permits for such open loop systems want you to discharge on the surface -- they certainly don't want you pumping water that you have handled directly back into the aquifer without being filtered through the ground.
I agree that lawn watering is a serious use of resources in the desert Southwest U.S. You can be Fremen in your view of lawns on Arrakis, but to argue the same point on Caladan is stretching matters a bit far.
I am a Pascal programmer from ancient days and have been pretty much a Delphi person on account of my Pascal affinity and other requirements, but I have implemented GUI apps in C++, C#, Java, Matlab, and VB. I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi. Java simply couldn't do in 1997 what I was doing even at that time in Windows, just plain couldn't from the standpoint of features and performances. Java is not-quite-there-yet with the features I use in Windows, but it is much farther along in 2006 than in 1997 and is closing the gap with graphics acceleration and other features. It may surpass Delphi for what I do if it proves to be easier to do multi-threaded apps to take advantage of multi-core.
While my complex data visualization stuff is a long way off from being done in Java, the sort of simple data visualization stuff that I was doing in 1997 under Windows works quite well under Java, and it works equally well under Linux. If anything will get me to switch to Linux it will be that I have a collection of graphical data visualiztion programs for the work I do written in Java that will work equally well under Linux. While I can write a faster program with more features in Windows, the Java implementation is proving good enough for a lot of stuff that I am doing and it breaks me loose from Windows as well.
SUN seems to be in this Java business for the long haul, seemingly spinning their wheels making it available for free and always being a step behind Windows in features. But at some point Java/Swing programs will have accumulated enough performance and features that they are good enough for what people want to do, and they have the added advantage of not being tied to Windows. This idea that something like Java could transcend the OS may yet happen for client GUI apps.
But why does the specification have to be a one-to-one mapping into the algorithm? Couldn't the specification be of the form of an assertion? An assertion is a form a runtime test case, and test cases are never exhaustive with regards to what a program does -- otherwise you could form test cases as the specification and automatically generate code from that, although there seems to be a programming style of generate the test cases first and have code monkeys pound on typewriters until they pass the test cases.
So instead of a traditional assertion -- a runtime test case written into the code -- you have a compile time assertion. The assertion could be that for int i, int j, at a certain point in the code i = j, and the result could be true, false, or undecidable. There is a little of that built into compilers today -- warning messages about assigning a value to a variable and never using it, catching uninitialized variables (some of the time), and the like.