If somebody showed me two randomly chosen numbers and asked me to come up with a number between those two, it would take me at least 7 seconds to do that? I doubt it.
When you model human behavior in terms of deterministic principles (i.e. the laws of physics and the metaphysical assumptions that underlie them) What else did you want to model it with?
This looks like a weird combination of the "second system effect" (introduce a Java-like class system because supposedly that's what people want now), fixing what wasn't broken (introduce a Java-like class system to a language that didn't need it), not fixing what was broken (the strange constructor function/"this" semantics), and, inventively, breaking what wasn't broken (operator overloading). There's also a tiny bit of actual fixing what was broken (namespace system), but I don't think that that will save the day:-P
First-class functions and methods? Yup, it's got that... with some *really weird* semantics when it comes to 'this'....
The fact that Javascript has closures is its one redeeming feature, IMO.
Yeah, but closures and first-class functions constitute a more universal concept than OOP and weird "this" semantics. So, if you know what you're doing, you can pretty much forget "this" and JS's weird built-in OOP semantics and use the closures feature to implement your own way of doing OOP with it. Basically, the designers of JS grounded the language on a Smalltalk/Lisp-like feature set, and in the end tacked some Java syntax as well as familar-looking keywords like "this" on top of it to make the whole thing more appealing to Java people.
The common terrorist next door hell-bent on building a bomb himself probably wouldn't use this anyway. Something like the "gun design" (used in the Hiroshima bomb, and obsolete ever since) is, in all likelihood, a lot easier to get right.
So it does seem to be better" than google sky as this system will be allowed continue to collect images published in astronomical papers and add these pages to the world wide telescope system.
Well, Google Sky loads stuff off various servers all the time as you pan and zoom into the map, just like Google Earth and, probably, MS Virtual Earth or Nasa WorldWind do. So, with the buzzwords stripped, I can't find anything substantial in your post about what's so different, let alone "world changing", in WWT. But maybe that's just me.
If you can find a way to magically thread javascript in a way that allows multiple windows and tabs to communicate with each other (as the DOM requires), I'm sure the mozilla folks would absolutely *love* to hear about it.
How about just implementing it? No magic needed. If the whole UI is slow and tends to lock up because it uses only a single thread, and the reason for that is that the language/runtime the UI is written in doesn't support threads, then you have three options:
keep everything as it is, maybe pretend the problem doesn't exist
rewrite in a language that does support threading
extend Javascript resp. its runtime/libraries to support threading
The last one is probably the best option if you want to solve the problem, minimize the amount of work required to do so, and don't want to force all the plugin writers to use another language.
You can just run a terminal emulation in Emacs, inside which you can run any "decent" text editor you want, including another Emacs, thereby achieving technological singularity.
Well, first of all, decoding application layer protocol information is too slow to be done on really large border routers. Second, if you do that, all routers will have to know all IP-based protocols (and even many TCP-based ones if they want to support connection initiation in both directions) they want to be able to route, which is basically impossible, kills end-to-end connectivity and (and this point is very important) prevents newcomers/startup companies from freely inventing new, innovative services and protocols on the net.
Yes, they would. People on the ground will always be at some danger when you put an 11-ton satellite in low earth orbit.
You can minimize the danger if you inflict a sudden loss of momentum on the satellite such that it will come down in an unpopulated area, such as an ocean, with a high degree of predictability. If you can at the same time destroy the satellite's tank, which contains a highly poisonous substance, all the better. If you just let it come down on its own, it can come down anywhere (equator +/- the orbit's inclination), with the tank likely to be still intact.
But it's easier to predict the impact point of a body that has a well known shape and orbit than that of a body that has been torn apart and pushed in random ways by an explosion.
They're dealing with an out-of-control, non-aerodynamic object in orbit. Predicting the impact point of such a thing with an accuracy of less than a few thousand miles is impossible until the last one or two orbits (i.e. one our two hours before it comes down). Predicting it with an accuracy that would allow for any reasonably attempt at warning, let alone evacuating, people on the ground is well-nigh impossible.
If they let this satellite come down without intercepting it, it's very likely that the hydrazine tank would survive the re-entry. It would breach (fuel lines ripping apart) and release the hydrazine into the environment. By shooting it down you're ensuring that the tank is blown apart in orbit and burns up, including the hydrazine, on re-entry. So shooting it down *is* a reasonable option.
As for the space junk, my understanding is that almost all the pieces that are produced by the explosion will re-enter within the next few orbits. Even the pieces that are accelerated by the explosion (and by far the most ones will be decelerated because the missile hits the satellite at front (seen in flight direction) at high velocity) will just enter an elliptic orbit whose perigee will be at the same altitude as the one where the explosion occured, where the atmospheric drag is high enough to bring the piece down in a short time.
...and while nobody is going to use its native interface, maybe we can use it to get rid of the Alsa Mess[tm] by burying it under a hopefully less messy stack of 5 userspace modules that may introduce 2 seconds of latency, but provide an emulated/dev/dsp on top! Sure, you have to run the OSS-using app under an obscure wrapper named "padsp", which probably means you'll have to run the whole X session under padsp and hope it doesn't crash too often, but oh well...:-P
Smart programmers may use Eclipse and the command line at the same time, but not for the same things, so this is not an "either-or" issue or a "lack of better tools" issue. In my Java projects (developed with Eclipse) I use to use BeanShell, which, when used interactively, is run from the command line (which in turn is running inside Emacs...). You can run the Beanshell Console in the Eclipse console, but it's quite painful. Similarly, when grepping or analysing line-oriented log files created by your Eclipse-developed applications, there's hardly anything better than the Unix toolchest (I challenge you to show me an equally efficient set of tools inside the Eclipse or VStudio environment).
AFAIK, the Galileo dispute was more about Galileo's observation that Jupiter had moons that revolved around it (as opposed to the church's idea that everything must revolve around the earth), for which Galileo did have empirical proof.
I can't think of one good reason why passengers should have any access whatsoever to command/control networks used by the airplane.
Accessing current position/altitude/velocity/flight direction/weather information/outboard camera images from the flight entertainment system (not sure that's a "good" reason, but it's a reason...).
On the plus side, no passenger has to install flight simulator programs on his/her laptop anymore when he or she can just as well use the real thing.
Now lets say usable processing power doubles every 5 years, and it shrinks to something small enough it can walk into our living rooms. That would be at least 150 years from now.
That's only as long as you simulate neurons in software, which is probably as inefficient as it gets, as opposed to building and connecting artificial neurons in hardware directly. The fact that the brain manages to cramp the intellectual differences between reptiles and humans into a few cubic centimeters should tell you something.
You could just use weak references (does C# support that?) for all references that the event sender uses to reference its event receivers. In that case, as soon as a receiver has been removed from all those "obstacle lists" and all other objects that held references to it, the weak reference would be the only reference pointing to the receiver, which would make the receiver eligible for garbage collection.
Looks like this stops working when you introduce some state:
>>> def make_adder(number): ... def adder(arg): ... number = number + arg ... return number ... return adder ... >>> >>> >>> >>> a2=make_adder(5) >>> a2(8) Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in adder UnboundLocalError: local variable 'number' referenced before assignment >>>
Python has several features that e.g. Javascript lacks, for example full OO-suppport, polymorphism, namespaces and modules.
The lack of namespaces is a problem, yes -- but there are way to deal with that (basically, use "namespace objects"). I don't know what you mean by lack of polymorphism -- you can dynamically overwrite/replace methods all the time, so there's polymorphism all over the place.
Python bashers usually know little about Python and largely perceive it as a toy language, something like PHP with whitespace and without the deployment. The fact is, you can write fast, robust, object-oriented software in Python without losing your mind with prototypes in the process.
You don't need to use prototypes at all to do OOP in JS. In fact, closures in combination with open objects are arguably a more general concept than "traditional", class based OOP. Look here for a possible approach (I came up with this recently for a relatively large JS/AJAX project):
JS has several features that e.g. Python lacks, for example prototypes, open/classless objects and closures. JS bashers usually know little about JS and largely perceive it as a web toy, something like VBA with Java syntax and without the IDE. The fact is, you can write real, reusable, object-oriented software in JS, without going crazy in the process. There are deficiencies and incompatibilities in the various browser runtimes, but those are neither JS's fault nor will they magically be avoided by inventing some new language.
I heard that the length of the pauses between the beeps encoded the air pressure inside the sphere (thus, presumably, giving useful, albeit rough, data about the presence or absence of micrometeorites in LEO). In addition to that, any radio transmitter in earth orbit provides data about the transmission of radio waves in the ionosphere...
Slashdot Mirror
If somebody showed me two randomly chosen numbers and asked me to come up with a number between those two, it would take me at least 7 seconds to do that? I doubt it.
This looks like a weird combination of the "second system effect" (introduce a Java-like class system because supposedly that's what people want now), fixing what wasn't broken (introduce a Java-like class system to a language that didn't need it), not fixing what was broken (the strange constructor function/"this" semantics), and, inventively, breaking what wasn't broken (operator overloading). There's also a tiny bit of actual fixing what was broken (namespace system), but I don't think that that will save the day :-P
Yeah, but closures and first-class functions constitute a more universal concept than OOP and weird "this" semantics. So, if you know what you're doing, you can pretty much forget "this" and JS's weird built-in OOP semantics and use the closures feature to implement your own way of doing OOP with it. Basically, the designers of JS grounded the language on a Smalltalk/Lisp-like feature set, and in the end tacked some Java syntax as well as familar-looking keywords like "this" on top of it to make the whole thing more appealing to Java people.
The common terrorist next door hell-bent on building a bomb himself probably wouldn't use this anyway. Something like the "gun design" (used in the Hiroshima bomb, and obsolete ever since) is, in all likelihood, a lot easier to get right.
Well, Google Sky loads stuff off various servers all the time as you pan and zoom into the map, just like Google Earth and, probably, MS Virtual Earth or Nasa WorldWind do. So, with the buzzwords stripped, I can't find anything substantial in your post about what's so different, let alone "world changing", in WWT. But maybe that's just me.
Well, maybe the database is bigger. Or not. Oh, and you can switch the view to infrared and radar.
How about just implementing it? No magic needed. If the whole UI is slow and tends to lock up because it uses only a single thread, and the reason for that is that the language/runtime the UI is written in doesn't support threads, then you have three options:
- keep everything as it is, maybe pretend the problem doesn't exist
- rewrite in a language that does support threading
- extend Javascript resp. its runtime/libraries to support threading
The last one is probably the best option if you want to solve the problem, minimize the amount of work required to do so, and don't want to force all the plugin writers to use another language.You can just run a terminal emulation in Emacs, inside which you can run any "decent" text editor you want, including another Emacs, thereby achieving technological singularity.
You could have used your reader's search function :-P
Well, first of all, decoding application layer protocol information is too slow to be done on really large border routers. Second, if you do that, all routers will have to know all IP-based protocols (and even many TCP-based ones if they want to support connection initiation in both directions) they want to be able to route, which is basically impossible, kills end-to-end connectivity and (and this point is very important) prevents newcomers/startup companies from freely inventing new, innovative services and protocols on the net.
You can minimize the danger if you inflict a sudden loss of momentum on the satellite such that it will come down in an unpopulated area, such as an ocean, with a high degree of predictability. If you can at the same time destroy the satellite's tank, which contains a highly poisonous substance, all the better. If you just let it come down on its own, it can come down anywhere (equator +/- the orbit's inclination), with the tank likely to be still intact.
But it's easier to predict the impact point of a body that has a well known shape and orbit than that of a body that has been torn apart and pushed in random ways by an explosion.
They're dealing with an out-of-control, non-aerodynamic object in orbit. Predicting the impact point of such a thing with an accuracy of less than a few thousand miles is impossible until the last one or two orbits (i.e. one our two hours before it comes down). Predicting it with an accuracy that would allow for any reasonably attempt at warning, let alone evacuating, people on the ground is well-nigh impossible.
As for the space junk, my understanding is that almost all the pieces that are produced by the explosion will re-enter within the next few orbits. Even the pieces that are accelerated by the explosion (and by far the most ones will be decelerated because the missile hits the satellite at front (seen in flight direction) at high velocity) will just enter an elliptic orbit whose perigee will be at the same altitude as the one where the explosion occured, where the atmospheric drag is high enough to bring the piece down in a short time.
...and while nobody is going to use its native interface, maybe we can use it to get rid of the Alsa Mess[tm] by burying it under a hopefully less messy stack of 5 userspace modules that may introduce 2 seconds of latency, but provide an emulated /dev/dsp on top! Sure, you have to run the OSS-using app under an obscure wrapper named "padsp", which probably means you'll have to run the whole X session under padsp and hope it doesn't crash too often, but oh well... :-P
Sure. Use the right tool for each job, I say.
Smart programmers may use Eclipse and the command line at the same time, but not for the same things, so this is not an "either-or" issue or a "lack of better tools" issue. In my Java projects (developed with Eclipse) I use to use BeanShell, which, when used interactively, is run from the command line (which in turn is running inside Emacs...). You can run the Beanshell Console in the Eclipse console, but it's quite painful. Similarly, when grepping or analysing line-oriented log files created by your Eclipse-developed applications, there's hardly anything better than the Unix toolchest (I challenge you to show me an equally efficient set of tools inside the Eclipse or VStudio environment).
AFAIK, the Galileo dispute was more about Galileo's observation that Jupiter had moons that revolved around it (as opposed to the church's idea that everything must revolve around the earth), for which Galileo did have empirical proof.
Accessing current position/altitude/velocity/flight direction/weather information/outboard camera images from the flight entertainment system (not sure that's a "good" reason, but it's a reason...).
On the plus side, no passenger has to install flight simulator programs on his/her laptop anymore when he or she can just as well use the real thing.
That's only as long as you simulate neurons in software, which is probably as inefficient as it gets, as opposed to building and connecting artificial neurons in hardware directly. The fact that the brain manages to cramp the intellectual differences between reptiles and humans into a few cubic centimeters should tell you something.
You could just use weak references (does C# support that?) for all references that the event sender uses to reference its event receivers. In that case, as soon as a receiver has been removed from all those "obstacle lists" and all other objects that held references to it, the weak reference would be the only reference pointing to the receiver, which would make the receiver eligible for garbage collection.
Looks like this stops working when you introduce some state:
Python has several features that e.g. Javascript lacks, for example full OO-suppport, polymorphism, namespaces and modules.The lack of namespaces is a problem, yes -- but there are way to deal with that (basically, use "namespace objects"). I don't know what you mean by lack of polymorphism -- you can dynamically overwrite/replace methods all the time, so there's polymorphism all over the place.
Python bashers usually know little about Python and largely perceive it as a toy language, something like PHP with whitespace and without the deployment. The fact is, you can write fast, robust, object-oriented software in Python without losing your mind with prototypes in the process.
You don't need to use prototypes at all to do OOP in JS. In fact, closures in combination with open objects are arguably a more general concept than "traditional", class based OOP. Look here for a possible approach (I came up with this recently for a relatively large JS/AJAX project):
http://user.cs.tu-berlin.de/~klischat/mydocs/javascript/closure-based-oop.txt.html
You wouldn't believe what big leaps you can make with this :-P
JS has several features that e.g. Python lacks, for example prototypes, open/classless objects and closures. JS bashers usually know little about JS and largely perceive it as a web toy, something like VBA with Java syntax and without the IDE. The fact is, you can write real, reusable, object-oriented software in JS, without going crazy in the process. There are deficiencies and incompatibilities in the various browser runtimes, but those are neither JS's fault nor will they magically be avoided by inventing some new language.
That won't matter much anymore as soon as we have those portable 100GW cold fusion reactors available :-P
Maybe it'll turn out to be easier to just keep the oil-combusting engines but re-implement photosynthesis using large-scale technology though!
I heard that the length of the pauses between the beeps encoded the air pressure inside the sphere (thus, presumably, giving useful, albeit rough, data about the presence or absence of micrometeorites in LEO). In addition to that, any radio transmitter in earth orbit provides data about the transmission of radio waves in the ionosphere...