Also, maneuverability, as I just don't see most of those sailing techniques working in a vacuum.
Solar sails don't, and have never been intended to, use "sailing techniques". In that sense "solar sail" is an unfortunate misnomer. Solar sail maneuvers typically take advantage of the fact that changing the sail orientation enable you to direct the resultant force from the solar radiation pressure either along or counter to the orbital velocity vector. Depending on which way you point the sail you either increase or decrease your orbit energy. Increases in orbit energy correspond to increases in orbit radius (or semi-major axis if in a non-circular orbit), while decreases in energy decrease the radius of the orbit. There's no "tacking" in the sense of ocean sailing.
The problem is that bleeding off energy with a solar sail isn't like just jumping onto a sunward elliptical orbit. You're likely to spiral in towards the sun, rather than zip around it. More importantly, a "slingshot" takes advantage of planetary motion relative to the sun to achieve a large trajectory change: a "slingshot" around the sun won't do anything except get you onto the outbound leg of the trajectory you're already on (i.e. it won't help you get further out from the sun than you were already going anyway). You'd probably be better off conserving the energy you already have, and using the sail to spiral out into a higher orbit.
Corporate CEOs are no friends of the free market...
Of course they're not. They wouldn't exist in an actual free market. Corporations themselves exist as the result of government interference in the free market, by way of laws that allow corporations to exist, to have legal rights that permit them to make transactions in the market, and to limit the liability of the owners. Corporate CEOs who lobby the government are simply trying to tweak the government's distortion of the regulated market even further in their favor.
Ruby and Python have only been "mainstream" for a few years, while static languages have been around since the ancient days.
Right. But Lisp, which is dynamically typed, has been around since the late 50s (second oldest high level language). And Smalltalk, which was a strong influence on Ruby, dates from the early 70s. Erlang has been around since the mid 80s. So "dynamic" languages have been around since the ancient days too. There's a place for both in the modern development environment. Horses for courses.
Some would argue that dynamic/duck + extra testing has the same effect with less cost than static + less testing.
Indeed. Others would argue that (good) static + more testing gives you the best of both worlds. This is a time-worn debate, and is unlikely to be resolved any time soon. Ultimately, the choice will come down to a combination of developer preference, and the cost/benefit/reliability issues associated with the specific domain you're working in. The biggest problem with debates like the static/dynamic one is that everyone seems to assume that the way software is developed in their specific application domain is suitable for every other application domain too. In practice, that's hardly ever true.
Er... Snow Crash was first published in around 1992. Some 8 years after Neuromancer. So I fail to see how Stephenson could be a "predecessor" of Gibson.
It's more than just quality hardware and a good OS though. What you're getting when you buy an Apple product is a well-designed system. Aristotle said that "the whole is greater than the sum of its parts", and he's right in the sense that the quality of the whole depends on how the parts are combined and how they interact with each other. That's the bit that Ballmer doesn't seem to get. MS sells some of the parts. Apple sells the whole. Apple as a company may have some warts. It's products are not always perfect. But they, more than most companies, strive to develop good systems that do what the end-user needs, instead of just good parts that need to be fitted into a whole by the end-user. That's part of what makes Apple fans so loyal to the brand.
I found much the same thing when shopping around for laptops back in 2004. Compare like-for-like, and suddenly that Powerbook didn't seem as expensive after all.
The reader who has persevered this far must by now be a cultivator of mathematics, even if he was not at the start of the endeavour. He will therefore appreciate that, while it may be ancient and venerable, it is far from complete; that not all of it is dry; and that its reasoning has not always been either unambiguous or irrefutable - nor is it yet.
Which really captures what the book is about. It's an extremely accessible introduction to abstract algebra, topology, probability, and several other topics. It does a great job of presenting the overall structure of mathematics, and giving just enough of an idea of what's going on to make you want to learn more, without being dry, boring, or bogged down in details. I found it quite an inspiring book, and several friends that I lent it to found the same. Judging from the Amazon reviews, we weren't the only ones. All that, plus it's available as a low-cost Dover book:-)
Yeah...uh...that might be the "overshoot and collapse" that the Limits to Growth report seems to indicate we can expect some time in the mid to late 21st century.
That was not what they were teaching in schools 20 years ago. Oil was supposed to have run out about 1997 or 1998 and tin 1990ish.
Regardless of what you were taught in school 20 years ago, that's not what the actual Limits to Growth report said. There was a lot of bogus information propagated about the Limits to Growth report at the time it came out, largely by people who didn't like what it actually had to say. The reality is that the Limits to Growth report explored a number of different possible scenarios (varying assumptions such as the impact of technological change and of social policies), and found that most (but not all) scenarios seem to lead to some kind of "overshoot and collapse" in the mid to late 21st century. These were never meant to be precise predictions, but rather to provide some idea of the global system's behavioral tendencies. Interestingly, a recent study has found that the Limits to Growth "standard run" scenario tracks quite well with the actual observed behavior of the world over the last 30 years. As the abstract of that report says:
Contrary to popular belief, The
Limits to Growth scenarios by the team of analysts from the Massachusetts Institute
of Technology did not predict world collapse by the end of the 20th Century. This
paper focuses on a comparison of recently collated historical data for 1970-2000
with scenarios presented in the Limits to Growth. The analysis shows that 30 years
of historical data compares favorably with key features of a business-as-usual
scenario called the "standard run" scenario, which results in collapse of the global
system midway through the 21st Century. The data does not compare well with other
scenarios involving comprehensive use of technology or stabilizing behaviour and
policies.
Sure, I suppose "the People" have the right to control who enters "their" country. But if they exercise that right, they are imposing artificial constraints on the labor market, making the overall economic system something other than "free".
In a truly free market, government and Microsoft would not talk to each other at all. Microsoft would have to deal with its labor shortages in a different manner (perhaps hire some U.S. engineers w/o jobs, instead of willfully ignoring them).
In a truly free market, the government wouldn't apply any restrictions to the flow of goods or workers into and out of the country. There'd be no need for MS to beg for H1Bs because the government wouldn't be preventing workers from other countries entering the US in the first place. What you're describing as "truly free" is simply a different set of restrictions than the current ones.
Actually, the sun does set in GEO. Just not for very long, and only at certain times of the year. Eclipse seasons for a geostationary satellite occur around the vernal and autumnal equinoxes. The seasons last around 40-50 days, with maximum sun-occultation duration of about 72 minutes. A discussion of the relevant orbit geometry can be found here.
To me, a prototype is a small-scale implementation (potentially with reduced functionality) intended to prove out a concept. The prototype may do less, but it's developed at the same level of abstraction as the final implementation. In contrast, a model is an abstracted idealization of the final implementation (i.e. developed at a higher level of abstraction than the implementation). Of course, there's a lot of room for interpretation in those definitions. The difference between prototyping and modeling isn't quite so clean-cut in the world of software as it is in engineering domains that build physical systems. So it's entirely possible that you may view models as a kind of prototype (or perhaps prototypes as a kind of model).
Funny thing, it is typically the other way for me, eg. I make model and close loopholes in it during coding
Hardly surprising. I didn't say that you wouldn't find holes while you're coding. Each step of the design and development process inevitably involves resolving new issues as you learn more about the problem you're trying to solve. That's part of what makes development such a fun activity:-)
But how many more holes would you find in coding if your "model" was just a vague idea in your head, rather than something more explicit? And how many of the those holes would be structural problems with the basic design that require complex changes to the code? The act of making your design ideas explicit as a model of some sort (be it UML, test suites, or Z schemas) helps to elaborate and clarify them. Paraphrasing Richard Guindon's comment about writing: "[Modeling] is Nature's way of showing us how sloppy our thinking is."
We often find the "loopholes" in our methodology by drawing it out first. We plug those glaring holes. Then start coding.
Pretty much anything you do to think through your design before committing to code will help to uncover inconsistencies and holes. It's just a question of what medium you use as your motivating tool to spur the "design analysis". Diagramming in UML is one approach. For the TDD fetishists, writing a bunch of tests tends to help uncover facets of the design that hadn't previously considered (subtle aspects of particular use cases, corner cases that the design needs to handle, etc.). A large part of the value to be found in modeling the design in a precise language like Z, Alloy, or CSP is the thought about the design that's required in order to construct a model (the other part of the value being the model-checking or other automated analysis that helps you to find holes that aren't quite so "glaring"). Almost any kind of "design analysis" (read "thinking about how the design operates and whether it will work as intended") will help. The more interesting question is "which approaches to analysis give me the most bang for the buck?"
A single launch (i.e. the rocket, plus the expense of launch operations) can cost around $150-200M. The satellite itself is probably on the order of $100-150M to build and operate. These are not GPS-specific figures. They're probably about right most commercial commsats too. So the two satellites mentioned in the article will potentially get you close to 1/2 of the total figure. Throw in some NRE to account for what you trivialize as "access control and an amplifier" (the jam-resistant high-power signal alone is far more complex than just adding an amplifier, and GPS III involves a lot of other system upgrades as well), and you'll quickly reach the $1.4B mark.
A GPS upgrade simply doesn't sound very humanitarian to me.
Er, you do realize that the civilian uses of GPS probably far outweigh the military uses these days, don't you? Most camping stores stock GPS units. Many cars come with them. Some cellphones. GPS receivers are being integrated into all sorts of products that require location or precise time information. Future FAA "free flight" rules for civil aviation are (IIRC) reliant on GPS. Indeed, several of the changes to GPS that are being made as part of GPS III are specifically intended to help civilian users.
And indeed antenna directionality is exactly what GPS III is doing. The intent, AFAIK, is to provide a high-power jam-resistant signal in a given theater of operations, not to provide global jam-resistance.
Around 30 years ago NASA was messing with the Multimission Modular Spacecraft (MMS), which was in use for 10+ years. Some 10 years ago there was a lot of activity around the highly modular SMEX-Lite bus for smaller missions. On the other side of the pond, Surrey Satellite Technology Ltd. has been doing cheap, highly modular spacecraft buses since the early 1980s. The US DoD and its various contractors have played with the idea at various times in the last couple of decades as well, most recently in the guise of "operationally responsive space" and "plug-and-play spacecraft". Needless to say, the concept is not particularly new. It just waxes and wanes in popularity depending on what kind of tradeoffs between mission cost and mission performance are acceptable.
hmm, 1960s? That sounds very early for CCS or CSP.
Indeed. Hoare's original CSP paper dates from 1978. IIRC Milner's first published work on CCS was around 1980. He'd previously done some other work on process-based concurrency, but I think even that goes back only to the early 70's.
You mean like Yaws? To quote from their website: "...one Erlang light weight process is used to handle each client...". Of course, they also say: "...performance comes from the underlying Erlang system and its ability to handle concurrent processes in an efficient way...". Using "processes" doesn't necessarily mean using heavyweight OS processes. It mostly means avoiding shared state, which is the root of the problems with threads. Languages like occam and Erlang provide lightweight processes with extremely fast context switching and quick interprocess communication.
What is more important? Is developer time and productivity over the software lifetime more valuable than CPU cycles? If the price of that productivity imposes a maximum limit on performance, how much optimization should be undertaken?
The answer to that question depends on the customer, the project, and the end-user. The tradeoff (to the extent there is one - and as others have already pointed out, there doesn't have to be) must be resolved in the context of whatever project you're working on. For some customers, performance will be critical, and they'll be willing to pay large amounts to get it. Others just want something cheap that runs "fast enough". Finding the right answer for a particular customer and project is part of the software engineering effort.
Ironically, Whedon has explicitly said that Firefly was heavily influenced by B7. Of course, to be fair, he also threw a bunch of other ideas into the mix. And he certainly didn't try to bank on an established brand the way the "reimaginings" do.
C seems to be holding ground, the slight loss seems to be within the fluctuations other languages that are holding steady are seeing. It's too powerful, too close to bare-metal programming and too close to the actual machine architecture to fade for some time yet.
Not to mention that it's still the lingua franca of embedded development. Other languages have made some inroads, but C seems to have lion's share of the embedded market.
Slashdot Mirror
Solar sails don't, and have never been intended to, use "sailing techniques". In that sense "solar sail" is an unfortunate misnomer. Solar sail maneuvers typically take advantage of the fact that changing the sail orientation enable you to direct the resultant force from the solar radiation pressure either along or counter to the orbital velocity vector. Depending on which way you point the sail you either increase or decrease your orbit energy. Increases in orbit energy correspond to increases in orbit radius (or semi-major axis if in a non-circular orbit), while decreases in energy decrease the radius of the orbit. There's no "tacking" in the sense of ocean sailing.
The problem is that bleeding off energy with a solar sail isn't like just jumping onto a sunward elliptical orbit. You're likely to spiral in towards the sun, rather than zip around it. More importantly, a "slingshot" takes advantage of planetary motion relative to the sun to achieve a large trajectory change: a "slingshot" around the sun won't do anything except get you onto the outbound leg of the trajectory you're already on (i.e. it won't help you get further out from the sun than you were already going anyway). You'd probably be better off conserving the energy you already have, and using the sail to spiral out into a higher orbit.
Of course they're not. They wouldn't exist in an actual free market. Corporations themselves exist as the result of government interference in the free market, by way of laws that allow corporations to exist, to have legal rights that permit them to make transactions in the market, and to limit the liability of the owners. Corporate CEOs who lobby the government are simply trying to tweak the government's distortion of the regulated market even further in their favor.
Right. But Lisp, which is dynamically typed, has been around since the late 50s (second oldest high level language). And Smalltalk, which was a strong influence on Ruby, dates from the early 70s. Erlang has been around since the mid 80s. So "dynamic" languages have been around since the ancient days too. There's a place for both in the modern development environment. Horses for courses.
Indeed. Others would argue that (good) static + more testing gives you the best of both worlds. This is a time-worn debate, and is unlikely to be resolved any time soon. Ultimately, the choice will come down to a combination of developer preference, and the cost/benefit/reliability issues associated with the specific domain you're working in. The biggest problem with debates like the static/dynamic one is that everyone seems to assume that the way software is developed in their specific application domain is suitable for every other application domain too. In practice, that's hardly ever true.
Er... Snow Crash was first published in around 1992. Some 8 years after Neuromancer. So I fail to see how Stephenson could be a "predecessor" of Gibson.
It's more than just quality hardware and a good OS though. What you're getting when you buy an Apple product is a well-designed system. Aristotle said that "the whole is greater than the sum of its parts", and he's right in the sense that the quality of the whole depends on how the parts are combined and how they interact with each other. That's the bit that Ballmer doesn't seem to get. MS sells some of the parts. Apple sells the whole. Apple as a company may have some warts. It's products are not always perfect. But they, more than most companies, strive to develop good systems that do what the end-user needs, instead of just good parts that need to be fitted into a whole by the end-user. That's part of what makes Apple fans so loyal to the brand.
I found much the same thing when shopping around for laptops back in 2004. Compare like-for-like, and suddenly that Powerbook didn't seem as expensive after all.
You might try Ian Stewart's Concepts of Modern Mathematics. Quoting from the end of the book:
Which really captures what the book is about. It's an extremely accessible introduction to abstract algebra, topology, probability, and several other topics. It does a great job of presenting the overall structure of mathematics, and giving just enough of an idea of what's going on to make you want to learn more, without being dry, boring, or bogged down in details. I found it quite an inspiring book, and several friends that I lent it to found the same. Judging from the Amazon reviews, we weren't the only ones. All that, plus it's available as a low-cost Dover book :-)
Yeah...uh...that might be the "overshoot and collapse" that the Limits to Growth report seems to indicate we can expect some time in the mid to late 21st century.
Regardless of what you were taught in school 20 years ago, that's not what the actual Limits to Growth report said. There was a lot of bogus information propagated about the Limits to Growth report at the time it came out, largely by people who didn't like what it actually had to say. The reality is that the Limits to Growth report explored a number of different possible scenarios (varying assumptions such as the impact of technological change and of social policies), and found that most (but not all) scenarios seem to lead to some kind of "overshoot and collapse" in the mid to late 21st century. These were never meant to be precise predictions, but rather to provide some idea of the global system's behavioral tendencies. Interestingly, a recent study has found that the Limits to Growth "standard run" scenario tracks quite well with the actual observed behavior of the world over the last 30 years. As the abstract of that report says:
Sure, I suppose "the People" have the right to control who enters "their" country. But if they exercise that right, they are imposing artificial constraints on the labor market, making the overall economic system something other than "free".
In a truly free market, the government wouldn't apply any restrictions to the flow of goods or workers into and out of the country. There'd be no need for MS to beg for H1Bs because the government wouldn't be preventing workers from other countries entering the US in the first place. What you're describing as "truly free" is simply a different set of restrictions than the current ones.
Actually, the sun does set in GEO. Just not for very long, and only at certain times of the year. Eclipse seasons for a geostationary satellite occur around the vernal and autumnal equinoxes. The seasons last around 40-50 days, with maximum sun-occultation duration of about 72 minutes. A discussion of the relevant orbit geometry can be found here.
To me, a prototype is a small-scale implementation (potentially with reduced functionality) intended to prove out a concept. The prototype may do less, but it's developed at the same level of abstraction as the final implementation. In contrast, a model is an abstracted idealization of the final implementation (i.e. developed at a higher level of abstraction than the implementation). Of course, there's a lot of room for interpretation in those definitions. The difference between prototyping and modeling isn't quite so clean-cut in the world of software as it is in engineering domains that build physical systems. So it's entirely possible that you may view models as a kind of prototype (or perhaps prototypes as a kind of model).
Hardly surprising. I didn't say that you wouldn't find holes while you're coding. Each step of the design and development process inevitably involves resolving new issues as you learn more about the problem you're trying to solve. That's part of what makes development such a fun activity :-)
But how many more holes would you find in coding if your "model" was just a vague idea in your head, rather than something more explicit? And how many of the those holes would be structural problems with the basic design that require complex changes to the code? The act of making your design ideas explicit as a model of some sort (be it UML, test suites, or Z schemas) helps to elaborate and clarify them. Paraphrasing Richard Guindon's comment about writing: "[Modeling] is Nature's way of showing us how sloppy our thinking is."
A single launch (i.e. the rocket, plus the expense of launch operations) can cost around $150-200M. The satellite itself is probably on the order of $100-150M to build and operate. These are not GPS-specific figures. They're probably about right most commercial commsats too. So the two satellites mentioned in the article will potentially get you close to 1/2 of the total figure. Throw in some NRE to account for what you trivialize as "access control and an amplifier" (the jam-resistant high-power signal alone is far more complex than just adding an amplifier, and GPS III involves a lot of other system upgrades as well), and you'll quickly reach the $1.4B mark.
Er, you do realize that the civilian uses of GPS probably far outweigh the military uses these days, don't you? Most camping stores stock GPS units. Many cars come with them. Some cellphones. GPS receivers are being integrated into all sorts of products that require location or precise time information. Future FAA "free flight" rules for civil aviation are (IIRC) reliant on GPS. Indeed, several of the changes to GPS that are being made as part of GPS III are specifically intended to help civilian users.
And indeed antenna directionality is exactly what GPS III is doing. The intent, AFAIK, is to provide a high-power jam-resistant signal in a given theater of operations, not to provide global jam-resistance.
Around 30 years ago NASA was messing with the Multimission Modular Spacecraft (MMS), which was in use for 10+ years. Some 10 years ago there was a lot of activity around the highly modular SMEX-Lite bus for smaller missions. On the other side of the pond, Surrey Satellite Technology Ltd. has been doing cheap, highly modular spacecraft buses since the early 1980s. The US DoD and its various contractors have played with the idea at various times in the last couple of decades as well, most recently in the guise of "operationally responsive space" and "plug-and-play spacecraft". Needless to say, the concept is not particularly new. It just waxes and wanes in popularity depending on what kind of tradeoffs between mission cost and mission performance are acceptable.
You mean like Yaws? To quote from their website: "...one Erlang light weight process is used to handle each client...". Of course, they also say: "...performance comes from the underlying Erlang system and its ability to handle concurrent processes in an efficient way...". Using "processes" doesn't necessarily mean using heavyweight OS processes. It mostly means avoiding shared state, which is the root of the problems with threads. Languages like occam and Erlang provide lightweight processes with extremely fast context switching and quick interprocess communication.
You may want to take a look at C--. It's got some good justifications for claiming to be a better assembly language than C.