Re:Code rot probably not the best analogy
on
Cloning Mammoths
·
· Score: 1
That's true... the only way to go about it would be to build a complete sequence from many cells (several thousand to get a complete enough picture, I would think), encode it, then resynthesize the entire genome from scratch.
The first half of that would require the same kind of effort that went in to the Human Genome Project; the second half a much more advanced development of currently-existing chromosome synthesis techniques. I'd guess we're 10 years away from (a) being cheap enough to do on a bunch of frozen mammoth, and (b) being feasible at all.
Except that GCC for PPC and GCC for x86 are already different beasts. So it's no different. You simply change the test from "which chip is fastest with the GCC compiler for that chip" to "which chip is fastest with the manufacturer's compiler for that chip".
mmm, 10.1 to 10.2, which took my then almost brand-new, $2200 TiBook 550 from unacceptably slow to... still unacceptably slow. What a great way to spend $120.
Any country can invade another up until the World Powers care about it. Unfortunately for the citizens of Tibet, they do not have any oil and are in a country inaccessible to most US military hardware (too far from the coast for carrierborne fighters, too mountainous for tanks and armored vehicles), etc.
Sorry... if it weren't for the Cold War and the development of the ICBM and spy satellites, we probably wouldn't have even gotten in to orbit yet. Hell, if it wasn't for WW2 and the preceding military buildup, we probably wouldn't have the Bomb or the jet engine.
Don't get me wrong, I have no love for war nor for US foreign policy. But there's no denying that war is by far the single biggest engine driving technical innovation.
It's an interplanetary probe, it won't do re-entry. And uranium in an unstarted nuclear reactor is practically harmless anyway. Plutonium, now that's a different matter.
In any case, building a nuclear containment vessel strong enough to withstand external fire followed by a terminal-velocity plunge in to the sea is quite possible. Also, the material in an unstarted (uranium) nuclear reactor is not all that radiotoxic. You wouldn't want to handle it for long periods without protective clothing, but it has nothing like the lethality of plutonium or nuclear waste. Once the reactor has been running a little while it becomes much more dangerous, but I guess they plan to start the main reactor from a much smaller (hot) neutron source once the thing is a safe distance from the Earth.
The problem is not so much sending a human - getting someone to Mars alive is not that difficult, apart from radiation shielding issues. At least, not that much more difficult than a. keeping someone alive on the Space Station for 6 months, or b. getting a man to the Moon and back.
One problem is keeping someone alive once they get there, but the worst problem is getting them back:- once you land on a roughly Earth-sized planet, you need an Earth-sized rocket to get you off again. The big reason for looking for large water supplies on Mars is not for keeping humans alive - though it would obviously help - but as a ready source of hydrogen with which to produce rocket fuel via solar electrolysis.
So, first you have to get a Soyuz-size rocket, albeit unfuelled, off the Earth's surface and safely down to the surface of another planet, along with suitable gear to produce tens of gallons of hydrogen an hour from water and solar or nuclear energy (otherwise you'll be waiting literally years for your rocket to fill up). Then once you get it on to the planet's surface, you have to hold out 'til it's got enough fuel to launch succesfully, and then launch the thing with a crew of perhaps 6 men and women, not the hundreds of technicians that would attend a normal Earth launch.
The reason the Moon was relatively "easy" is that its gravity is very weak and hence it only takes a relatively small amount of energy to escape it - small enough that we could send the escape vehicle there ready-fuelled atop a Saturn rocket. Mars has a gravitational field not much less than Earth's, and so the escape vehicle has to be big and powerful.
Maybe true of a Russian nuclear facility, but what of all the other CIS states that have left-over Soviet nukes? Russia has most or all of the military stuff, but civilian power plants is an entirely different matter.
I'm a moderately heavy caffeine drinker, but I tend to escalate and build up tolerance over a few months (strangely enough it coincides with the project cycles here at work...:))
I wouldn't call it addictive, but if I go cold turkey after drinking approx. five *strong* cups a day for a month [I'm naturally fairly wired to begin with] I'm pretty much wiped out for a day, and sluggish the day after, but after 10 days or so my caffeine tolerance is right back down again. I think it has a lot to do with mild sleep deprivation, and generally putting ones' autonomic nervous system off balance.
Having said that, caffeine is not that far removed from amphetamines, and in really high doses could potentially have the same effects - again, dependency-forming rather than addictive, but seriously bad for your health (heart problems, paranoia, crank bugs..) - I'm honestly surprised that the LD50 is as high as 4 grams, I ate 500mg in tablet form once and felt seriously bad (headrushes, heart palpitations), I would have thought 2-3x that could easily be lethal.
Actually there was a case very recently over here (UK) where a woman was jailed for poisoning her young child with common salt.
A healthy adult with adequate access to water would have to eat a lot to suffer acute toxicity, but for a small child - especially if you add dehydration to the picture - a much smaller dose - of the order of 10 grams, can be lethal.
That's the tough part. And not just hardened a little bit, either. It's kinda the same situation as "industrial" strength laptops (and even those are probably not space-ready). I don't know the exact requirements for space-hardening, but if it were easy then at the current $4000/lb or so it costs for LEO launch, some rich geek would surely have already put a small laptop-size server in orbit.
Building batteries, electronics and mechanical parts that work over a massive temperature range, harsh radiological conditions, and alien gravitational and atmospheric conditions, is always going to be difficult and expensive, and is bound to lag behind mainstream robotics by several years (btw, I doubt the average interplanetary probe has even Pentium II-class processors for their onboard computers:)).
Not to mention you have really strict power requirements on a vehicle that has to run for several weeks in an environment where power either has to be taken with you (batteries are heavy; nuclear sources - which offer much more energy for weight - either do not scale down small enough (reactors) or do not have a high enough output per hour (hot isotope sources)) or you have to run on solar power which on Mars is going to be pretty marginal for a self-propelled system.
One option would be a larger fixed solar installation that a robot can return to to recharge, but that means more complexity and more to go wrong, and again you have to have a rechargeable power system that will work reliably and predictably across a wide temperature range. Not easy.
Then there's communications.. I believe the current generation of Mars landers will relay messages to Earth via the various Mars orbiters, but you have a -huge- round-trip time for commands (several hours, possibly > 1 day).. it's not like having a radio-controlled robot! That's why NASA is doing a lot of research on autonomous UAVs for the next-generation "Mars flyer" craft.. actually "flying" the thing manually would be completely impossible.
I'm not saying that I think a walking rover is a bad idea, mind you, but to suggest that a "slightly modified AIBO" would do the job is way off beam.
Likewise, only I'm more in the market for:-
1. a hard drive (or wait until Flash gets so cheap I can put 2GB+ in the thing). Being limited to one or two MP3 albums' worth of expensive Flash memory sticks is not acceptable.
2. programmability. I don't care if the OS is Linux, but it certainly wouldn't hurt. If the OS is Linux, I don't have to care about the number of keyboard keys or the bundled software as I know they kbd can easily be remapped and new s/ware installed. However, at the minimum, it has to allow the development of apps that can access the local filesystem, TCP/IP and whatever I/O the machine supports (I suspect the gaming-oriented Java VMs included with "smart" phones lock out some of this?)
3. a usable-quality colour digital camera (I'd buy at 320x200 and stills-only, but would prefer 640x480 and motion capture).
4. a high-enough resolution screen for readable-but-ugly text at 80x25. 320x200 *just* scrapes by as acceptable there; in any case it's hard to build much more than that in to such a small form factor.
5. reasonably quality (better than your average cellphone) external connectivity for audio I/O, preferably on standard 3.5mm connectors.
I'm starting to get frustrated with what I see as a lack of innovation with regards to integrating this stuff.. we all know it's possible with current technology. Right now, I carry around a semi-smart (actually pretty dumb) phone, an iPod and a small digital camera. Each of these has probably 85% of its components and weight (casing, screen, battery, mobile CPU, buttons, connector jacks, memory) in common, so it MUST be possible to build something like this that's no more than 30% bigger and heavier than a new-style iPod.
I suspect it may in part have to do with the cellphone companies having rather stringent rules on what can connect to their networks.. I don't suppose they'd much like their protocol stacks running in the same address-space as any old code.
You've missed the point.. however much they pay, the 80-year (or whatever) maximum term of copyright imposed by Congress still stands (unless Congress is shortsighted enough to extend it to infinity, which would not entirely surprise me). The act is an effective way of setting a "lower bound" for the copyright term so that unexploited work passes in to the public domain. The upper bound remains unchanged.
Don't be so surprised... there are already USB desktop speakers and microphones, it's a short leap from digital audio devices to DRM-enabled ones.
Fortunately the analog electrical rendering of audio - which is going to have to happen at SOME point before it hits the speaker membrane - is such a simple, idiot-friendly thing that any electronics hobbyist can build a device capable of tapping and capturing it at pretty good quality. The same is not true of video - tapping a TFT panel's internal signals or capturing them at high fidelity (by mating said panel with a giant CCD?) is a much trickier and more expensive business. Thank g-d for Break Once, Run Anywhere.
Having just lost a bunch of time (although fortunately little valuable data) when one of my IBM DeathStars died, I went out and bought Maxtors 'cause they seemed to be the choice for reliability.
So what make are we all supposed to buy now? Cheap hard drives all of a sudden aren't so cheap when you have to buy two of them and a RAID controller to get an acceptable level of reliability...
Yes, and all the music out there would be dull, lowest-common-denominator prole fodder. Like 99% of the stuff that DOES get recorded on million-dollar SSLs.
ProTools brings about a small reduction in quality (not insignificantly small, but small enough that most folks besides sound engineers and audiophiles neither know nor care) but a great increase in the diversity of music recorded to "professional" quality (whatever that is).
I agree with your analysis of the problem of using OO code, but I don't think it'll die because of this. Rather, we'll see a maturing of "text-plus" tools (IDEs, smarter text editors), where the underlying data are text but you're able to manipulate sources in a higher level way. Microsoft are perhaps leading the way here with Visual Studio.net. If your IDE is smart enough, you either don't have to have header and interface files at all (because the compiler will pull out all the functions and generate them appropriately just before compile or whenever necessart), or you have them and you don't have to worry (because the IDE will update them in sync with your main code body).
As to parallelism, quite right. From a logical point of view, and on modern and near-future systems a performance point of view also, it's very useful to be able to tell the machine about dependencies at the task level. C gives you no real way of expressing "do X and Y in any order or at the same time, but make sure both are done before you start doing Z" other than diving in to manual thread programming, which is far from ideal, never mind performance or portability issues.
At the end, then, my money has to be on a partially object-oriented language descended originally from C via Java or C++, compiled to bytecode and that generates programs with at least some level of self-reference / self-extensibility (Java has this already, to some degree). We'll see some kind of parallelism constructs built in to the language (occam's ser and par, anyone?), and a sophisticated visual IDE.
A valid question... really depends on how much is done in hardware and microcode vs software.
ASM these days is not really the machine language most people think it is.. every time you write x86 code and run it on a Pentium Pro/II/III/4 or Athlon, you're actually running it through a combination of hardware and software that acts as an interpreter before your code hits the "raw metal" of load/store, ALU and FPU.
x86 encoding is a reasonably good way of representing programmer intention at that level to current-generation microprocessors, but there's every reason to suppose that in a few CPU-generations' time, the best binary execution encoding may package instructions up in more complex semantic bundles, and that the CPU-level hardware/software will do much more in the way of language->raw-instructions conversion at execution time.
Java is already showing the way here; it will be interesting to see how the performance differences of C/C++ vs Java scale as machines become increasingly un-von Neumannlike (superscalar cpus, speculative execution, multiple cores on-die, simultaneous thread execution, unpredictable execution timings, huge latency to main RAM). The problem with a language like C is that the compiler has to make a lot of assumptions about what conditions are going to look like at execution time.. something it increasingly cannot know. At some point down the line, I would expect hardware-assisted bytecode to catch up with and then overtake compiled C in most cases.
For a while, there will still be tightly controlled environments where C and machine code will rule (low-cost embedded being the obvious example), but if high-efficiency hardware-assisted bytecode is dominant on the desktop in 10-20 years, it will presumably follow on small-footprint chips for pretty much any application within another 10-20 years of that.
The problem with visual languages is that their overall paradigm tends to be somewhat restricted and specialised. There are numerous visual or part-visual tools that have many of the features of a programming language (especially in fields relating to signal processing, but arguably also in CAD, business process modelling, databases, prototyping, multimedia authoring..) but none have ever really caught on as a general solution.
The sort of visual paradigm you'd want for an authoring app is decidedly different to what you might want for signal processing, for example.
Except that people want CHEAP flights, and AIRSPACE over NW Europe is becoming the limiting factor, not fuel or other costs. Either people will have to take these big planes - possibly with a lower daily frequency - or prices will have to go up.
I don't know about the situation in the main body of the USA, but the air corridors over NW Europe and the north-eastern corner of the US are right at the limit of capacity. Bigger planes is the only way to accommodate everyone that wants to travel.
Slashdot Mirror
That's true... the only way to go about it would be to build a complete sequence from many cells (several thousand to get a complete enough picture, I would think), encode it, then resynthesize the entire genome from scratch. The first half of that would require the same kind of effort that went in to the Human Genome Project; the second half a much more advanced development of currently-existing chromosome synthesis techniques. I'd guess we're 10 years away from (a) being cheap enough to do on a bunch of frozen mammoth, and (b) being feasible at all.
Except that GCC for PPC and GCC for x86 are already different beasts. So it's no different. You simply change the test from "which chip is fastest with the GCC compiler for that chip" to "which chip is fastest with the manufacturer's compiler for that chip".
mmm, 10.1 to 10.2, which took my then almost brand-new, $2200 TiBook 550 from unacceptably slow to... still unacceptably slow. What a great way to spend $120.
Any country can invade another up until the World Powers care about it. Unfortunately for the citizens of Tibet, they do not have any oil and are in a country inaccessible to most US military hardware (too far from the coast for carrierborne fighters, too mountainous for tanks and armored vehicles), etc.
Sorry... if it weren't for the Cold War and the development of the ICBM and spy satellites, we probably wouldn't have even gotten in to orbit yet. Hell, if it wasn't for WW2 and the preceding military buildup, we probably wouldn't have the Bomb or the jet engine. Don't get me wrong, I have no love for war nor for US foreign policy. But there's no denying that war is by far the single biggest engine driving technical innovation.
Just a thought... is it likely that the fields of Jupiter would prove suitable for using space tethers as a source of power?
We'll probably still need nuclear to get there in the first place, of course..
It's an interplanetary probe, it won't do re-entry. And uranium in an unstarted nuclear reactor is practically harmless anyway. Plutonium, now that's a different matter.
It's a design study, not the building of a complete operational spacecraft.
:(
The pessimist in me says this one will be cancelled long before it ever launches
In any case, building a nuclear containment vessel strong enough to withstand external fire followed by a terminal-velocity plunge in to the sea is quite possible. Also, the material in an unstarted (uranium) nuclear reactor is not all that radiotoxic. You wouldn't want to handle it for long periods without protective clothing, but it has nothing like the lethality of plutonium or nuclear waste. Once the reactor has been running a little while it becomes much more dangerous, but I guess they plan to start the main reactor from a much smaller (hot) neutron source once the thing is a safe distance from the Earth.
The problem is not so much sending a human - getting someone to Mars alive is not that difficult, apart from radiation shielding issues. At least, not that much more difficult than a. keeping someone alive on the Space Station for 6 months, or b. getting a man to the Moon and back. One problem is keeping someone alive once they get there, but the worst problem is getting them back:- once you land on a roughly Earth-sized planet, you need an Earth-sized rocket to get you off again. The big reason for looking for large water supplies on Mars is not for keeping humans alive - though it would obviously help - but as a ready source of hydrogen with which to produce rocket fuel via solar electrolysis. So, first you have to get a Soyuz-size rocket, albeit unfuelled, off the Earth's surface and safely down to the surface of another planet, along with suitable gear to produce tens of gallons of hydrogen an hour from water and solar or nuclear energy (otherwise you'll be waiting literally years for your rocket to fill up). Then once you get it on to the planet's surface, you have to hold out 'til it's got enough fuel to launch succesfully, and then launch the thing with a crew of perhaps 6 men and women, not the hundreds of technicians that would attend a normal Earth launch. The reason the Moon was relatively "easy" is that its gravity is very weak and hence it only takes a relatively small amount of energy to escape it - small enough that we could send the escape vehicle there ready-fuelled atop a Saturn rocket. Mars has a gravitational field not much less than Earth's, and so the escape vehicle has to be big and powerful.
Maybe true of a Russian nuclear facility, but what of all the other CIS states that have left-over Soviet nukes? Russia has most or all of the military stuff, but civilian power plants is an entirely different matter.
I'm a moderately heavy caffeine drinker, but I tend to escalate and build up tolerance over a few months (strangely enough it coincides with the project cycles here at work... :))
I wouldn't call it addictive, but if I go cold turkey after drinking approx. five *strong* cups a day for a month [I'm naturally fairly wired to begin with] I'm pretty much wiped out for a day, and sluggish the day after, but after 10 days or so my caffeine tolerance is right back down again.
I think it has a lot to do with mild sleep deprivation, and generally putting ones' autonomic nervous system off balance.
Having said that, caffeine is not that far removed from amphetamines, and in really high doses could potentially have the same effects - again, dependency-forming rather than addictive, but seriously bad for your health (heart problems, paranoia, crank bugs..) - I'm honestly surprised that the LD50 is as high as 4 grams, I ate 500mg in tablet form once and felt seriously bad (headrushes, heart palpitations), I would have thought 2-3x that could easily be lethal.
Actually there was a case very recently over here (UK) where a woman was jailed for poisoning her young child with common salt. A healthy adult with adequate access to water would have to eat a lot to suffer acute toxicity, but for a small child - especially if you add dehydration to the picture - a much smaller dose - of the order of 10 grams, can be lethal.
"It would obviously have to be "hardened""
:)).
That's the tough part. And not just hardened a little bit, either. It's kinda the same situation as "industrial" strength laptops (and even those are probably not space-ready). I don't know the exact requirements for space-hardening, but if it were easy then at the current $4000/lb or so it costs for LEO launch, some rich geek would surely have already put a small laptop-size server in orbit.
Building batteries, electronics and mechanical parts that work over a massive temperature range, harsh radiological conditions, and alien gravitational and atmospheric conditions, is always going to be difficult and expensive, and is bound to lag behind mainstream robotics by several years (btw, I doubt the average interplanetary probe has even Pentium II-class processors for their onboard computers
Not to mention you have really strict power requirements on a vehicle that has to run for several weeks in an environment where power either has to be taken with you (batteries are heavy; nuclear sources - which offer much more energy for weight - either do not scale down small enough (reactors) or do not have a high enough output per hour (hot isotope sources)) or you have to run on solar power which on Mars is going to be pretty marginal for a self-propelled system.
One option would be a larger fixed solar installation that a robot can return to to recharge, but that means more complexity and more to go wrong, and again you have to have a rechargeable power system that will work reliably and predictably across a wide temperature range. Not easy.
Then there's communications.. I believe the current generation of Mars landers will relay messages to Earth via the various Mars orbiters, but you have a -huge- round-trip time for commands (several hours, possibly > 1 day).. it's not like having a radio-controlled robot! That's why NASA is doing a lot of research on autonomous UAVs for the next-generation "Mars flyer" craft.. actually "flying" the thing manually would be completely impossible.
I'm not saying that I think a walking rover is a bad idea, mind you, but to suggest that a "slightly modified AIBO" would do the job is way off beam.
Likewise, only I'm more in the market for:- 1. a hard drive (or wait until Flash gets so cheap I can put 2GB+ in the thing). Being limited to one or two MP3 albums' worth of expensive Flash memory sticks is not acceptable. 2. programmability. I don't care if the OS is Linux, but it certainly wouldn't hurt. If the OS is Linux, I don't have to care about the number of keyboard keys or the bundled software as I know they kbd can easily be remapped and new s/ware installed. However, at the minimum, it has to allow the development of apps that can access the local filesystem, TCP/IP and whatever I/O the machine supports (I suspect the gaming-oriented Java VMs included with "smart" phones lock out some of this?) 3. a usable-quality colour digital camera (I'd buy at 320x200 and stills-only, but would prefer 640x480 and motion capture). 4. a high-enough resolution screen for readable-but-ugly text at 80x25. 320x200 *just* scrapes by as acceptable there; in any case it's hard to build much more than that in to such a small form factor. 5. reasonably quality (better than your average cellphone) external connectivity for audio I/O, preferably on standard 3.5mm connectors. I'm starting to get frustrated with what I see as a lack of innovation with regards to integrating this stuff.. we all know it's possible with current technology. Right now, I carry around a semi-smart (actually pretty dumb) phone, an iPod and a small digital camera. Each of these has probably 85% of its components and weight (casing, screen, battery, mobile CPU, buttons, connector jacks, memory) in common, so it MUST be possible to build something like this that's no more than 30% bigger and heavier than a new-style iPod. I suspect it may in part have to do with the cellphone companies having rather stringent rules on what can connect to their networks.. I don't suppose they'd much like their protocol stacks running in the same address-space as any old code.
You've missed the point.. however much they pay, the 80-year (or whatever) maximum term of copyright imposed by Congress still stands (unless Congress is shortsighted enough to extend it to infinity, which would not entirely surprise me). The act is an effective way of setting a "lower bound" for the copyright term so that unexploited work passes in to the public domain. The upper bound remains unchanged.
Don't be so surprised... there are already USB desktop speakers and microphones, it's a short leap from digital audio devices to DRM-enabled ones. Fortunately the analog electrical rendering of audio - which is going to have to happen at SOME point before it hits the speaker membrane - is such a simple, idiot-friendly thing that any electronics hobbyist can build a device capable of tapping and capturing it at pretty good quality. The same is not true of video - tapping a TFT panel's internal signals or capturing them at high fidelity (by mating said panel with a giant CCD?) is a much trickier and more expensive business. Thank g-d for Break Once, Run Anywhere.
Perhaps.. although there's probably not a lot of difference in the price of 2x IDE disk + RAID controller vs 1x SCSI disk + SCSI controller.
Having just lost a bunch of time (although fortunately little valuable data) when one of my IBM DeathStars died, I went out and bought Maxtors 'cause they seemed to be the choice for reliability. So what make are we all supposed to buy now? Cheap hard drives all of a sudden aren't so cheap when you have to buy two of them and a RAID controller to get an acceptable level of reliability...
Yes, and all the music out there would be dull, lowest-common-denominator prole fodder. Like 99% of the stuff that DOES get recorded on million-dollar SSLs. ProTools brings about a small reduction in quality (not insignificantly small, but small enough that most folks besides sound engineers and audiophiles neither know nor care) but a great increase in the diversity of music recorded to "professional" quality (whatever that is).
I agree with your analysis of the problem of using OO code, but I don't think it'll die because of this. Rather, we'll see a maturing of "text-plus" tools (IDEs, smarter text editors), where the underlying data are text but you're able to manipulate sources in a higher level way. Microsoft are perhaps leading the way here with Visual Studio.net. If your IDE is smart enough, you either don't have to have header and interface files at all (because the compiler will pull out all the functions and generate them appropriately just before compile or whenever necessart), or you have them and you don't have to worry (because the IDE will update them in sync with your main code body). As to parallelism, quite right. From a logical point of view, and on modern and near-future systems a performance point of view also, it's very useful to be able to tell the machine about dependencies at the task level. C gives you no real way of expressing "do X and Y in any order or at the same time, but make sure both are done before you start doing Z" other than diving in to manual thread programming, which is far from ideal, never mind performance or portability issues. At the end, then, my money has to be on a partially object-oriented language descended originally from C via Java or C++, compiled to bytecode and that generates programs with at least some level of self-reference / self-extensibility (Java has this already, to some degree). We'll see some kind of parallelism constructs built in to the language (occam's ser and par, anyone?), and a sophisticated visual IDE.
A valid question... really depends on how much is done in hardware and microcode vs software. ASM these days is not really the machine language most people think it is.. every time you write x86 code and run it on a Pentium Pro/II/III/4 or Athlon, you're actually running it through a combination of hardware and software that acts as an interpreter before your code hits the "raw metal" of load/store, ALU and FPU. x86 encoding is a reasonably good way of representing programmer intention at that level to current-generation microprocessors, but there's every reason to suppose that in a few CPU-generations' time, the best binary execution encoding may package instructions up in more complex semantic bundles, and that the CPU-level hardware/software will do much more in the way of language->raw-instructions conversion at execution time. Java is already showing the way here; it will be interesting to see how the performance differences of C/C++ vs Java scale as machines become increasingly un-von Neumannlike (superscalar cpus, speculative execution, multiple cores on-die, simultaneous thread execution, unpredictable execution timings, huge latency to main RAM). The problem with a language like C is that the compiler has to make a lot of assumptions about what conditions are going to look like at execution time.. something it increasingly cannot know. At some point down the line, I would expect hardware-assisted bytecode to catch up with and then overtake compiled C in most cases. For a while, there will still be tightly controlled environments where C and machine code will rule (low-cost embedded being the obvious example), but if high-efficiency hardware-assisted bytecode is dominant on the desktop in 10-20 years, it will presumably follow on small-footprint chips for pretty much any application within another 10-20 years of that.
The problem with visual languages is that their overall paradigm tends to be somewhat restricted and specialised. There are numerous visual or part-visual tools that have many of the features of a programming language (especially in fields relating to signal processing, but arguably also in CAD, business process modelling, databases, prototyping, multimedia authoring..) but none have ever really caught on as a general solution.
The sort of visual paradigm you'd want for an authoring app is decidedly different to what you might want for signal processing, for example.
Except that people want CHEAP flights, and AIRSPACE over NW Europe is becoming the limiting factor, not fuel or other costs. Either people will have to take these big planes - possibly with a lower daily frequency - or prices will have to go up.
I don't know about the situation in the main body of the USA, but the air corridors over NW Europe and the north-eastern corner of the US are right at the limit of capacity. Bigger planes is the only way to accommodate everyone that wants to travel.