You see, the program "spins" until CheckOKtoProceed() returns true. The alternative is a call to a Yield(), Wait() or Sleep() function that 1) blocks execution until some condition is satisfied, and 2) tries to yield control to some other pending process while that is happening.
The trouble with a spin lock is that it hogs the processor. The trouble with the other kind of lock is that it allows another process to proceed, but it may not be safe to allow that on account of a data structure not being in a coherent state of update. A mutex is a kind of lock that by agreement of its use allows only one such process to proceed. A non-mutex lock doesn't offer such protection.
The argument is that the proposed modification make the kernel much more preemptable and do less spin locking that can kill response, but each element of the proposed modification would need to be checked and tested very carefully that after the change there aren't issues regarding the protection of data structures from multiple processes that could change it along with all kinds of mind-bending subtle bugs that can arise.
The real bad effect of the peremptory challenge is not simply that a person of your qualifications is excluded from a jury, but the next time you see a jury summons, you will grump, "this is a complete waste of time, I will never be permitted to serve on a jury."
My modest proposal is a "three strikes law." If you are challenged a third time, you should get a lifetime pass from having to answer a jury summons. And the judge should have a sheet of potential jurors and know how many lifetime challenges each juror has. The judge could then challenge a lawyer who would want to remove "that juror" (the lawyers should not see the "foul trouble and he sits on the sidelines" list otherwise they will cherry pick).
The current system is demoralizing, it creates the feeling that while we are supposed to do jury duty as citizens, there are different classes of citizenship, and that lawyers are all putzes.
I use Delphi for most of my stuff, but the weak point has to be thin support for collections. There is a list object (works like Java in that you store stuff as object references and have to cast the reference you get back), but it requires linking in the VCL -- what if you are doing a console app or your own Windows classes?
Sooner or later if one wants to adopt a language as a "solution to the programming problem" rather than limiting it is a scripting language, one will want to do numerical computing. And numerical computing means not only partial differential equation solvers, it also means doing any kind of graphics displays more complicated than the rich text-button-control-scroll bar kind of GUI.
To my mind, efficient numerical computing requires an intrinsic array type, because a lot of numerical computing has to operate at high speed on lists of numbers, especially graphics stuff. Interpreted/p-code/JITed languages that have been good with numerics (Matlab, Java) have an array type. Lisp didn't start with an array type but got one by the Lisp Machine/Common Lisp days.
A numerical array type (the built-in list types don't count because of the memory and speed overhead) is a work in progress in Python. The reason I say work in progress is on account of the Numeric/Numarray transition and that not all numeric/graphics packages for Python know about Numeric or Numarray so you take a hit getting lists of numbers in an out of them.
My bottom line for numerical computing (i.e. looking for a Matlab replacement) is 1) some kind of numerical array type that is 2) compatible with graphics routines for plotting graphs as well as bitmaps where I can specify the colors of individual pixels. Python is working on this (for example, TKInter has a bitmap canvas object, but can I get/set the bitmap raster as a Numeric or a Numarray?) Where is Ruby on this?
Well, yeah, I like Delphi too, but one has to face reality.
This dude from Sun gave a slide with language rankings which I never have been able to find on the Web, and I missed the methodology. You have to understand he was pushing Java.
According to him, there were only 3 languages that mattered: VB, C/C++ (this was pre C#), and Java. VB over the last several years had a solid 10 million users (people doing VB programming), C/C++ was around 5 million and also steady, while Java was at 3 million and climbing to pass C/++ in a couple years. Everything else, Lisp, Delphi, Python, etc was at the "noise level" (according to the dude) of the graph. Didn't ask him how Cobol figured.
Since then, I have wondered why VB ranks lower on everyone elses survey. Yeah, yeah, VB brain dead and all of that, but I would kind of believe that VB is the Cobol of this age and that there are lots of VB coders and that while C/C++ is popular, there would be fewer coders because they are more "system programming" than "application programming" languages.
Matlab is a Good Thing (tm) with respect to extensive libraries and an OK graphics package. The C/C++/Fortran extension system is OK, and the Java extension system (write modules in Java callable from Matlab) is pretty good.
From the standpoint of a language, Matlab is, gee, I don't know where to begin. It really has this cobbled-together lets-figure-out-how-to-graft-on-objects feel to it like Visual Basic only more so. The really simple is simple, and the somewhat complicated gets to be rats' nest really fast.
The issue of slave labor is highly important because not only was the V2 a pioneering rocket that went into space in a suborbit on a war mission, the V2 was mass produced, and the fact that it was mass produced meant there were so many "war surplus" V2s to help jump start the U.S. space program.
I have seen web pages talking about how space access is so expensive in comparison to how V2s were made cheaply and in large numbers, but people are forgetting that a tremendous amount of labor went into V2 production at a great human cost.
Also, I think the word "slave labor" doesn't create the right impression of what took place. It creates an image of Germans in officer uniforms sipping mint juleps while camp inmates toiled over work benches and hummed tunes.
The cruelty of the German slave labor system was the food rations and the deliberate undernourishment of the laborers. The rations were almost scientifically calculated to get the maximum amount of work out of a person before they turned into the human skeletons you see in the camp photos and soon died. If they gave the laborers no food at all they would have died much more quickly. While it was a terrible crime to take trainloads of people and kill them right away with poison gas, it was an even greater crime to kill people as slowly as one can imagine by just giving them barely enough food to work on munitions while giving people a false hope that while they were doing this work they were being spared the fate of the others killed by poison.
I don't know if the "human subject experiments" of the Nazis contributed anything to medical knowledge, but it would be a great burden to know that some medical advance that everyone benefits from came from that venue. I think people should be aware of the human cost of the V2 program. As to the argument that the article talks about technology not production, technology and production are intertwined, and the large scale production of V2s made them available at war's end to the American program (don't think the Russians were able to get their hands on the actual V2s, but they did get their hands on some of the mid-level Germans involved in the program -- the high-level Germans worked mightily on ending up in American hands, Operation Paperclip and all of that. Also, if the Germans were unable to produce the V2 in large numbers, their would have been no interest in having developed the technology in the first place, and the slave labor was perhaps and enabler as to why the V2 was allowed to be developed in the first place.
So Pons and Fleischmann violated process, so now there is a science version of ISO 960 or whatever that number is.
Oh and then there are the arguments from authority regarding eminent authorities telling us how Pons and Fleischmann were so second rate.
Cold fusion is either happening or it isn't. If it is happening, I don't care of Pons and Fleischmann are cheating on their wives and their income taxes, and if isn't happening, I don't care if they are as virtuous as saints.
I revised a lab course, and in one unit I asked them to time how long it takes to hook up a simple circuit on a Proto Board than then estimate how long it would take to implement a much more complex circuit that we implement with a FPGA because discrete TTL would take too long for the lab.
The idea was to put some degree of industrial realism into a university course -- in industry you spend more time coming up with estimates and schedules than doing mathematical proofs of Fourier transform properties. But the students didn't seem to "get it" regarding why this "make work" exercise was added to the lab.
Then one day I overheard a student tell his lab partners "We're engineers damnit! Whatever estimate we come up with, we double it!"
That was a very proud moment for me as an engineering educator. Not only did that student understand the exercise, he learned the concept of padding an estimate so you have some engineering margin against the eventual schedule slippage.
I don't have any problems trying to grow a plant on Mars dirt. I do have problems if that plant is anything from the Brassica family (includes all the vegetables you were forced to eat as a kid: cabbage, Brussel sprouts, turnips, broccoli as well as the mustards, which include many highly invasive and hard-to-get-rid-of weed species).
Don't know if many Slashdot people are dairy farmers, but their worst nightmare is having hay fields taken over with yellow mustard. And that isn't half as bad as garlic mustard, which is threatening to take over the entire forest undergrowth in the Great Lakes region.
Do we really want to turn Mars from red to the yellow of a serious mustard infestation?
You hit the nail on the head with "architectural", but I am not sure refactoring (cleaning up procedural code -- I doubt that Word is OO, seems more like bunches of data structure and C code that operates on it).
It seems their data structures are cobbled together and hacked together rather than based on sound theoretical models. The problem is deep in the design rather than just some misplaced lines of code.
The supermarket checkout is lined with "women's magazines" -- Cosmo, People, the health and fitness rags, the tabloids. I could never quite figure out the Cosmo thing (15 ways to turn your man into your sex slave along with the airbrush enhanced model showing yet another aspect of her breasts). Obviously Cosmo is pitched at women as I don't know of any men who buy it to stare at pictures of half-naket women, although the Victoria Secret catalog is iffy regarding being meant for male or female viewing. But then breasts are breasts and women as well as men may find such images comforting as they may play to some deep imprints in our infancy of being succored by our moms.
So if we know what the women's magazines are, what are the men's magazines? I suppose the feminists would snarl "Playboy", but which men above the age of say, 15, have any interest in that.
No, the men's magazines are PS/PM, and the men's magazine all time was the issue with the cover story "We Fly the B-2 Stealth Bomber." Every man wants to know! (By the way, it is side-stick controlled fly-by-wire with computer-generated control laws, and it handles pretty much like the Airbus A320 jet airliner, should that give you any basis for comparison.)
So they made me go sit over there on the Group W bench.
There were mother rapers. And there were father rapers! And then the biggest, meanest, father raper of them all, came up to me and asked, "what you do time for, boy?"
And I said "fer violatin a copyright." And they all slid away from me on the Group W bench.
And then I said "and fer addin' obscene words," And they all slid back towards me on the Group W bench.
My take on LEDs is that their efficiency (lumens/watt) is about the same as an incandescent light bulb, but the LED throws its light in a narrow cone while the light bulb throws its light in all directions.
When the application is putting the light in a narrow cone (i.e. traffic light), the LED comes out on top because the light bulb requires a reflector housing which is far from 100 percent effective in getting all the light to come out in the front. And as an added bonus, the LEDs last so much longer so you don't have to send crews out to change bulbs.
When the application is lighting a room, LEDs offer little or no efficiency advantage. For efficiency, the newer types of fluorescents (electronic ballast, T-8 bulb) are as good as it gets unless you go into some exotic tech or are willing to tolerate pure yellow light.
From the standpoint of starting a computer-geek flame war, the most interesting point of the article was round-robin vs priority-driven. Round robin is preferred by engineering types who don't know any better and want something simple, stupid, and reliable. Priority is preferred by computer science types on account of its elegance and ability to balance work load. I am in the engineering camp and don't know if I would have had the confidence to go with priority-driven in the first Moon lander.
The big thing to worry about is priority inversion, a deadlock that requires at least 3 priority levels. Level 1 asks Level 3 to do something. It turns out that Level 3 needs Level 2 to do something, but Level 2 is lower priority than Level 1 and stays blocked.
The problem is that when Level 1 is blocking on something from Level 3, Level 1 has put itself on the level of Level 3 and should give priority to Level 2. The usual (i.e. Linux, MS-Windows) solution is instead of trying to trace a graph of such circular dependency, you have a system timer that gives temporary priority boost to blocked processes that have been sitting there for quite some time -- I don't care how low your priority, if you have been sitting there long enough you get a turn.
In the right (wrong) circumstances, those kind of systems can gum up and then stuff gets updated in fits and starts -- they run really clunky but at least they run.
I am to assume that the guys were so sure about the LM software because no lower-priority task had any dependency on any higher-priority task, that if no lower-priority task ever got serviced that the higher-priority tasks could always be completed?
PBS did a Secrets of the Dead on the 1918 flu, and they tied it directly to WWI. In war, it is not only that you have people shooting at each other; you also take a lot of people and place them (cram them into) camps and place them under stresses to challenge their immune systems.
The hypothesis is that a British camp in France had a lot of soldiers in close proximity to a lot of pigs (needed to feed that many soldiers), allowing a swine flu virus to cross over to the soldiers, and then you had the soldiers living in cramped barracks allowing everyone to share whatever upper respiratory conditions they had. This took place a couple of "flu seasons" before 1918, but there is historical evidence of the 1918-type pneumonia symptoms in that camp predating 1918, and it takes a couple of flu seasons to set the stage for the big epidemic.
Long before there was a Gang of Four and talk of refactoring there was Glenford Meyers, Reliable Software through Composite Design.
While some of the ideas were controversial at the time (using long parameter lists for function calls instead of passing a pointer to a struct -- gee, I wonder who developed that habit of passing a pointer to a struct containing a glob of function parameters and why did they think there was nothing wrong with that?), and the book predates OO, the book is eye opening with regards to there being more to developing a program than coding.
The real art of software development is not simply knowing sort algorithms or how to traverse a linked list. The most important issue in any body of code more than 1000 lines is "I have a data value over here, and I need to use it over there, and how do I safely get that information from here to there apart from making every data structure global and turning the program into a rat's nest of unconstrained interactions?"
Reliable Software through Composite Design presents a pre-OO procedural look at that problem and is definitely worth looking at today.
I took mechanical drawing during high school summer school, the drafting teacher got to control the radio, his preference was for the "easy listening" station, it was the early 70's, and lets just say whenever I hear "Just like me, they want to be, close to you. Woohoouhhoo, close to you!" all I can think of is 4H and HB leads. It is strictly Pavlovian.
Last time this story got posted, the thread got clogged with whining about NASA funding, worrying about contaminating Titan, lame Borg jokes, and the general Slashdot name calling.
This time we will get it right and only post informative and insightful comments regarding what the pictures show and the possibility for life elsewhere than Earth . . . oops, too late.
Oil, more or less, flows out of the ground (sometimes it gushes under pressure, other times you have to inject brine or steam to recover it). The Canadian heavy oil has to be dug out of the ground just like coal.
There may be some special considerations in Canada -- the cold weather, the gritty sand that wears out mining gear. But the actual mining of coal is not the expensive part -- the biggest cost of Wyoming coal (you can Google for their promo Web site) is rail transport to power plants.
I think that what you do to it to turn it into gasoline, Diesel, and lube oil is probably a much more serious concern than the actual extraction. A big concern is water consumption and waste water disposal.
An alternate fuel that looks great on paper is coal bed methane. The story there is that you consume water for injecting to get the gas and then you have some pretty rough waste water, making you not such a popular neighbor in the desert West.
One thought came to mind on the large size of the Canadian tar sands. I heard that oil drilling extracts perhaps 20 percent of the oil in the ground, depending on extraction methods, water injection, and so on. If you are digging it up, it seems you can get close to 100 percent, and that may account for why the tar sands seem like such a bonanza. I suppose most oil fields are too deep to simply strip mine and get near 100 percent recovery.
As a kid, I and many other like minded kids with a shovel, while we were not going to dig all the way to China, we were going to tunnel pretty far down. I made it as far as the (shallow) water table, and a crayfish made its home at the bottom of the pit that was pretty cool. I think my parents used the hole to plant a tree.
So you can imagine that when I had heard about Project Mohole (c 1960) to dig a really deep hole, I thought it had to be the neatest thing. Thing is, Brown and Root burned through all of the money and Congress pulled the plug. But I heard the Russians are into digging really deep holes.
Slashdot Mirror
while (CheckOKtoProceed());
You see, the program "spins" until CheckOKtoProceed() returns true. The alternative is a call to a Yield(), Wait() or Sleep() function that 1) blocks execution until some condition is satisfied, and 2) tries to yield control to some other pending process while that is happening.
The trouble with a spin lock is that it hogs the processor. The trouble with the other kind of lock is that it allows another process to proceed, but it may not be safe to allow that on account of a data structure not being in a coherent state of update. A mutex is a kind of lock that by agreement of its use allows only one such process to proceed. A non-mutex lock doesn't offer such protection.
The argument is that the proposed modification make the kernel much more preemptable and do less spin locking that can kill response, but each element of the proposed modification would need to be checked and tested very carefully that after the change there aren't issues regarding the protection of data structures from multiple processes that could change it along with all kinds of mind-bending subtle bugs that can arise.
Wasn't that a Streisand song some years back?
The real bad effect of the peremptory challenge is not simply that a person of your qualifications is excluded from a jury, but the next time you see a jury summons, you will grump, "this is a complete waste of time, I will never be permitted to serve on a jury." My modest proposal is a "three strikes law." If you are challenged a third time, you should get a lifetime pass from having to answer a jury summons. And the judge should have a sheet of potential jurors and know how many lifetime challenges each juror has. The judge could then challenge a lawyer who would want to remove "that juror" (the lawyers should not see the "foul trouble and he sits on the sidelines" list otherwise they will cherry pick). The current system is demoralizing, it creates the feeling that while we are supposed to do jury duty as citizens, there are different classes of citizenship, and that lawyers are all putzes.
I use Delphi for most of my stuff, but the weak point has to be thin support for collections. There is a list object (works like Java in that you store stuff as object references and have to cast the reference you get back), but it requires linking in the VCL -- what if you are doing a console app or your own Windows classes?
To my mind, efficient numerical computing requires an intrinsic array type, because a lot of numerical computing has to operate at high speed on lists of numbers, especially graphics stuff. Interpreted/p-code/JITed languages that have been good with numerics (Matlab, Java) have an array type. Lisp didn't start with an array type but got one by the Lisp Machine/Common Lisp days.
A numerical array type (the built-in list types don't count because of the memory and speed overhead) is a work in progress in Python. The reason I say work in progress is on account of the Numeric/Numarray transition and that not all numeric/graphics packages for Python know about Numeric or Numarray so you take a hit getting lists of numbers in an out of them.
My bottom line for numerical computing (i.e. looking for a Matlab replacement) is 1) some kind of numerical array type that is 2) compatible with graphics routines for plotting graphs as well as bitmaps where I can specify the colors of individual pixels. Python is working on this (for example, TKInter has a bitmap canvas object, but can I get/set the bitmap raster as a Numeric or a Numarray?) Where is Ruby on this?
This dude from Sun gave a slide with language rankings which I never have been able to find on the Web, and I missed the methodology. You have to understand he was pushing Java.
According to him, there were only 3 languages that mattered: VB, C/C++ (this was pre C#), and Java. VB over the last several years had a solid 10 million users (people doing VB programming), C/C++ was around 5 million and also steady, while Java was at 3 million and climbing to pass C/++ in a couple years. Everything else, Lisp, Delphi, Python, etc was at the "noise level" (according to the dude) of the graph. Didn't ask him how Cobol figured.
Since then, I have wondered why VB ranks lower on everyone elses survey. Yeah, yeah, VB brain dead and all of that, but I would kind of believe that VB is the Cobol of this age and that there are lots of VB coders and that while C/C++ is popular, there would be fewer coders because they are more "system programming" than "application programming" languages.
From the standpoint of a language, Matlab is, gee, I don't know where to begin. It really has this cobbled-together lets-figure-out-how-to-graft-on-objects feel to it like Visual Basic only more so. The really simple is simple, and the somewhat complicated gets to be rats' nest really fast.
The issue of slave labor is highly important because not only was the V2 a pioneering rocket that went into space in a suborbit on a war mission, the V2 was mass produced, and the fact that it was mass produced meant there were so many "war surplus" V2s to help jump start the U.S. space program. I have seen web pages talking about how space access is so expensive in comparison to how V2s were made cheaply and in large numbers, but people are forgetting that a tremendous amount of labor went into V2 production at a great human cost. Also, I think the word "slave labor" doesn't create the right impression of what took place. It creates an image of Germans in officer uniforms sipping mint juleps while camp inmates toiled over work benches and hummed tunes. The cruelty of the German slave labor system was the food rations and the deliberate undernourishment of the laborers. The rations were almost scientifically calculated to get the maximum amount of work out of a person before they turned into the human skeletons you see in the camp photos and soon died. If they gave the laborers no food at all they would have died much more quickly. While it was a terrible crime to take trainloads of people and kill them right away with poison gas, it was an even greater crime to kill people as slowly as one can imagine by just giving them barely enough food to work on munitions while giving people a false hope that while they were doing this work they were being spared the fate of the others killed by poison. I don't know if the "human subject experiments" of the Nazis contributed anything to medical knowledge, but it would be a great burden to know that some medical advance that everyone benefits from came from that venue. I think people should be aware of the human cost of the V2 program. As to the argument that the article talks about technology not production, technology and production are intertwined, and the large scale production of V2s made them available at war's end to the American program (don't think the Russians were able to get their hands on the actual V2s, but they did get their hands on some of the mid-level Germans involved in the program -- the high-level Germans worked mightily on ending up in American hands, Operation Paperclip and all of that. Also, if the Germans were unable to produce the V2 in large numbers, their would have been no interest in having developed the technology in the first place, and the slave labor was perhaps and enabler as to why the V2 was allowed to be developed in the first place.
Oh and then there are the arguments from authority regarding eminent authorities telling us how Pons and Fleischmann were so second rate.
Cold fusion is either happening or it isn't. If it is happening, I don't care of Pons and Fleischmann are cheating on their wives and their income taxes, and if isn't happening, I don't care if they are as virtuous as saints.
The idea was to put some degree of industrial realism into a university course -- in industry you spend more time coming up with estimates and schedules than doing mathematical proofs of Fourier transform properties. But the students didn't seem to "get it" regarding why this "make work" exercise was added to the lab.
Then one day I overheard a student tell his lab partners "We're engineers damnit! Whatever estimate we come up with, we double it!"
That was a very proud moment for me as an engineering educator. Not only did that student understand the exercise, he learned the concept of padding an estimate so you have some engineering margin against the eventual schedule slippage.
Don't know if many Slashdot people are dairy farmers, but their worst nightmare is having hay fields taken over with yellow mustard. And that isn't half as bad as garlic mustard, which is threatening to take over the entire forest undergrowth in the Great Lakes region.
Do we really want to turn Mars from red to the yellow of a serious mustard infestation?
It seems their data structures are cobbled together and hacked together rather than based on sound theoretical models. The problem is deep in the design rather than just some misplaced lines of code.
The TK part of TCL/TK is another canvas-based approach (also usable as TKInter from Python).
So if we know what the women's magazines are, what are the men's magazines? I suppose the feminists would snarl "Playboy", but which men above the age of say, 15, have any interest in that.
No, the men's magazines are PS/PM, and the men's magazine all time was the issue with the cover story "We Fly the B-2 Stealth Bomber." Every man wants to know! (By the way, it is side-stick controlled fly-by-wire with computer-generated control laws, and it handles pretty much like the Airbus A320 jet airliner, should that give you any basis for comparison.)
There were mother rapers. And there were father rapers! And then the biggest, meanest, father raper of them all, came up to me and asked, "what you do time for, boy?"
And I said "fer violatin a copyright." And they all slid away from me on the Group W bench.
And then I said "and fer addin' obscene words," And they all slid back towards me on the Group W bench.
When the application is putting the light in a narrow cone (i.e. traffic light), the LED comes out on top because the light bulb requires a reflector housing which is far from 100 percent effective in getting all the light to come out in the front. And as an added bonus, the LEDs last so much longer so you don't have to send crews out to change bulbs.
When the application is lighting a room, LEDs offer little or no efficiency advantage. For efficiency, the newer types of fluorescents (electronic ballast, T-8 bulb) are as good as it gets unless you go into some exotic tech or are willing to tolerate pure yellow light.
The big thing to worry about is priority inversion, a deadlock that requires at least 3 priority levels. Level 1 asks Level 3 to do something. It turns out that Level 3 needs Level 2 to do something, but Level 2 is lower priority than Level 1 and stays blocked.
The problem is that when Level 1 is blocking on something from Level 3, Level 1 has put itself on the level of Level 3 and should give priority to Level 2. The usual (i.e. Linux, MS-Windows) solution is instead of trying to trace a graph of such circular dependency, you have a system timer that gives temporary priority boost to blocked processes that have been sitting there for quite some time -- I don't care how low your priority, if you have been sitting there long enough you get a turn.
In the right (wrong) circumstances, those kind of systems can gum up and then stuff gets updated in fits and starts -- they run really clunky but at least they run.
I am to assume that the guys were so sure about the LM software because no lower-priority task had any dependency on any higher-priority task, that if no lower-priority task ever got serviced that the higher-priority tasks could always be completed?
The hypothesis is that a British camp in France had a lot of soldiers in close proximity to a lot of pigs (needed to feed that many soldiers), allowing a swine flu virus to cross over to the soldiers, and then you had the soldiers living in cramped barracks allowing everyone to share whatever upper respiratory conditions they had. This took place a couple of "flu seasons" before 1918, but there is historical evidence of the 1918-type pneumonia symptoms in that camp predating 1918, and it takes a couple of flu seasons to set the stage for the big epidemic.
While some of the ideas were controversial at the time (using long parameter lists for function calls instead of passing a pointer to a struct -- gee, I wonder who developed that habit of passing a pointer to a struct containing a glob of function parameters and why did they think there was nothing wrong with that?), and the book predates OO, the book is eye opening with regards to there being more to developing a program than coding.
The real art of software development is not simply knowing sort algorithms or how to traverse a linked list. The most important issue in any body of code more than 1000 lines is "I have a data value over here, and I need to use it over there, and how do I safely get that information from here to there apart from making every data structure global and turning the program into a rat's nest of unconstrained interactions?"
Reliable Software through Composite Design presents a pre-OO procedural look at that problem and is definitely worth looking at today.
I took mechanical drawing during high school summer school, the drafting teacher got to control the radio, his preference was for the "easy listening" station, it was the early 70's, and lets just say whenever I hear "Just like me, they want to be, close to you. Woohoouhhoo, close to you!" all I can think of is 4H and HB leads. It is strictly Pavlovian.
This is the city. Los Angeles, California. My name's Friday and I work here . . . (cough, cough cough!).
This time we will get it right and only post informative and insightful comments regarding what the pictures show and the possibility for life elsewhere than Earth . . . oops, too late.
The Borg did in their Senate candidate. It was not a pretty sight.
There may be some special considerations in Canada -- the cold weather, the gritty sand that wears out mining gear. But the actual mining of coal is not the expensive part -- the biggest cost of Wyoming coal (you can Google for their promo Web site) is rail transport to power plants.
I think that what you do to it to turn it into gasoline, Diesel, and lube oil is probably a much more serious concern than the actual extraction. A big concern is water consumption and waste water disposal.
An alternate fuel that looks great on paper is coal bed methane. The story there is that you consume water for injecting to get the gas and then you have some pretty rough waste water, making you not such a popular neighbor in the desert West.
One thought came to mind on the large size of the Canadian tar sands. I heard that oil drilling extracts perhaps 20 percent of the oil in the ground, depending on extraction methods, water injection, and so on. If you are digging it up, it seems you can get close to 100 percent, and that may account for why the tar sands seem like such a bonanza. I suppose most oil fields are too deep to simply strip mine and get near 100 percent recovery.
So you can imagine that when I had heard about Project Mohole (c 1960) to dig a really deep hole, I thought it had to be the neatest thing. Thing is, Brown and Root burned through all of the money and Congress pulled the plug. But I heard the Russians are into digging really deep holes.
Hope they have better luck this time.