There's nothing in the constitution that denies Bill Gates the right to own a nuclear weapon is there?
No, but the NRC currently has legal standing to regulate and license private possession of that much fissile material. One suspects that the NRC would not license "assemble a nuclear weapon". It might be entertaining to listen to the Supreme Court questioning, but it seems unlikely that the Court would rule Bill's second amendment rights trump the NRC's authority to regulate. After all, the Court has never ruled that the second amendment overrides the states' authority to regulate high explosives.
Technically, no, they can't arbitrarily "police" any vessel they wish. But private possession of that much fissile material without an appropriate license from a signatory government also certainly violates some UN treaty. That they can enforce (although they might want to make sure that one of the US, UK, France, Russia or China is willing to back them up on their interpretation of the treaty).
We could have more small, local generation of power from wind and solar...
With the emphasis on local.
Bell Laboratories didn't create a million jobs (maybe 26,000 people at the peak, and the vast majority were not involved in research).
AT&T created a million jobs involved in manufacturing the equipment and installing and operating the network.
Primarily the local network --
AT&T Long Lines, the long-distance piece of the business, employed relatively few people.
If wind and solar energy provide a million jobs,
the large majority will be manufacturing, installation, and maintenance of the equipment --
not the research.
Yes, I have ISO file systems that I burned on CDs 15 years ago and current computers have no difficulty mounting them. I would still choose that over UDF (ISO 13346) on DVD for two reasons: lower density recording is typically more tolerant of physical degradation, and the video industry seems more likely to abandon DVD for higher capacity media than the music industry to abandon CD.
The formats for individual files are important too. On those oldest disks, I can still view the HTML, images in JPEG and GIF, and flat ASCII text files. Interestingly, groff handles the troff/mm files on the disk without any difficulties, but extracting the Word files took a bit more effort. The PostScript files on the disk still render just fine (no PDF files to try). The MPEG files on the disks play.
Some years back, this Slashdot story included several anecdotal examples of substantial bills for import duties showing up from the US Customs Service after a few months. For books purchased from individuals, probably not a large risk. If purchased from a business, which risks losing its export licenses, such sales are more likely to be eventually reported.
Some years ago, I developed a small box for the research organization in one of the cable companies that monitored the IR remote control to track button presses and did screen grabs of the STB output in order to allow in-home monitoring of customers' use of the various UI features (needed both because the STB in question was notorious for missing button presses). One version of the little box added a camera pointing out at the viewers and grabbed those images at the same time. The original intent was to allow researchers to check who was in the room when strange button sequences were encountered in the data; while testing the box in a researcher's home, the odd sequences turned out to occur when the three-year-old got her hands on the remote control. The human factors types loved having the snapshots available; again during in-house testing, the image sequences jogged peoples' memories: "Yeah, Bobby was there and that was when this odd thing happened..."
The version that took pictures of viewers never got used in customers' homes. The legal department was seriously concerned about how to write an agreement regarding the use of those images. I certainly have to wonder whether Comcast's legal department has looked at what needs to be added to the terms of service, and what the privacy requirements will be. If I believe my spouse has been cheating on me, can I get access to what was observed while I was out of town?
The members of the research group and I did have some odd conversations about whether the viewer snapshots should be disabled based on which channel was being watched...
I use XML to wrap oil and gas pipeline data and then display it as a type of document. Am I going to get sued by Microsoft? Am I a personal example of prior art?
No, and no.
Microsoft's patent covers representation of certain data related to word processing.
As you have wrapped something quite different in your document,
you do not infringe on their patent
nor is your application prior art for wrapping the kind of data covered by the MS patent.
After reading the claims,
this strikes me as a classic "defensive" patent.
MS is using XML in a particular way for something critical to their products
(help files?)
and since that particular use might be patentable,
took steps to insure that no one else was going to get a patent for it
and then extort money from MS.
A company I worked for obtained patents on a couple of things I had developed
with exactly this intent --
not to stop other people from using it, but
to keep other people from stopping us from using it.
I have looked over the years, but it doesn't appear to have ever been written up for publication.
I think that there are some arguments against teaching mark-up methods today, at least at the undergraduate level.
With limited exceptions, it's not what the students are going to find when they go out into the real world. In many fields, a graduate who can't do Word/Excel is functionally illiterate.
Unless it's a common practice used in several classes, the students' investment in time to learn a mark-up system (and a good text editor) will probably never be recovered.
Students don't write every day. There are plenty of studies that show that user interface features that make infrequent users more productive get in the way of experienced users, and vice versa.
The obvious compromise is software like LyX, that has a GUI interface suitable for infrequent users but uses LaTeX to actually do page layout. I also think it will never be widely adopted because people who think in terms of WYSIWYG will be disturbed that the final page doesn't look like what they've been working on.
The learning curve to systems like LaTeX is very steep, but you have a tremendous amount of control over the formatting and layout.
Or in some cases, much less control over the formatting and layout, which can be a good thing.
Many years ago, there was a development project at Bell Labs so large that there was an entire department for maintaining the technical documentation.
The department head wanted to dump troff and the macros then in use and go to WYSIWYG.
To justify his decision, he had the research people set up a controlled experiment with two groups of new people that received equal training in their respective tools.
The troff people were about 25% more productive than WYSIWYG, and had significantly fewer formatting errors.
When the psych people got done with their interviews and examining keystroke logs,
they concluded that with formatting control available to them,
almost everyone spends 20-25% of their time futzing with fonts, line and page breaks, etc.
All of which is wasted time until very close to the end of the process.
Personally,
when creating new text,
I feel like I'm more productive
if I can write flat files with a mark-up language,
because I do get distracted by an ugly line break in a WYSIWYG tool.
But I'm an old UNIX geek, and
I don't expect the rest of the world to ever go away from WYSIWYG.
The entire legislative branch of the State of Colorado uses WordPerfect. In their case, it's (a) that the entire work-flow management system generates WordPerfect templates for the formal documents, and no one wants to pay to replace the system and (b) there are some millions of pages of official state records whose only soft copy is in WordPerfect, and much of whose formatting is dependent on insane macros.
The only real "feature" in WordPerfect tables that isn't in Word is that they can be used as baby spreadsheets with formulas and macros. "Baby" in the sense of simple, I've seen WordPerfect tables that run to several hundred rows. There are times, particularly under deadline, when it's very, very nice to have text and live tables all in one document. This was a bigger deal ten years ago than it is now.
PerfectScript for macros is a nightmare. If anyone asks you to maintain old PerfectScript code, run away screaming.
I'm assuming this class is part of a bigger degree program...
Doesn't the department have some soft of coherent policy about software?
I've taken classes at four colleges over the years
(three degrees in three different fields),
and the department always had
a fairly narrow policy about
what was acceptable and what was not.
If simulation is a required part of the circuit design classes,
I would expect the department to have a position on the software tools
that was independent of instructors or textbooks.
If for no other reason than if you got hit by a bus six weeks into the class,
a substitute would be able to take over and know
what tools the students were using.
To expand on that point, because it's inexpensive, it uses common materials, and it scales.
The problem of "I have an object here that produces lots of heat energy, I'd like to convert that heat to useful work, please"
is harder than it sounds.
My hand writing was always bad to the point of taking notes in classes was pretty much useless.
Seriously, how do people who don't write quickly and clearly (cursive or printing)
get through classes with heavy-duty math in college?
I took a sequence of graduate economics classes within the last five years,
and only about half the material covered was in the textbook.
Much of the half not in the texts
involved complex expressions involving integrals, differentiation, and matrix expressions.
Most students notes for a 90-minute class ran to 3-5 pages of the stuff.
Is this going to be another reason for not producing engineers and scientists
in the US?
That we don't teach enough math because the students can't write fast enough
to take notes on the material if taught at a reasonable pace?
I learned a few things. The first is to get exact specifications.
==========
This is not realistic. You _can't_ get the requirements right up front because the users don't even know what they want until they have a system that doesn't have it. They think they told you what they want, but they didn't because they don't know themselves.
I have to agree with the parent. I've had an opportunity to watch the post-mortems on several large, failed software procurements by my state's government. My opinion is that the fundamental reason all of them failed was inadequate (sometimes grossly so) specification. I also agree with you, that the customer generally can't (or won't) do it. I believe the way I put it to one director was "If you can't specify the interfaces, the protocols, and a reasonably complete conceptual model of the data, you're paying $78 million for the vendor to guess." Given the price tags on large state software systems these days, government is going to have to figure out how to avoid buying $78 million prototypes that aren't going to be even close to right.
I'm an old grumpy guy, but am still looking for at least two features. Have they managed to put floating displays in this version? How about intelligent vertical white space, that gets suppressed as being unnecessary at the top of a column or page? Stuff should start at exactly the same place at the top of each page or column (excepting possibly the first page). And with the exception of a handful of cases involving the end of sections, there should never be more than a couple of blank lines at the bottom of a page. Fill the pages intelligently for me, please.
What they absolutely suck on is self-discharging. Your average zinc-air hearing air battery will discharge in about a week exposed to oxygen... This would pretty much sabotage applications where you would prefer regular batteries over rechargeable ones right now...
For many applications, this would certainly be a killer. What many of the researchers have in mind for high Wh/kg batteries is, of course, traction applications: cars, trucks, buses, etc. This class of application is characterized by frequent -- daily in most cases -- recharging. Even if 10-15% of the charge I start with in the morning is lost to self-discharge, the roughly 2:1 thermal efficiency gain of a commercial power plant relative to a typical ICE still leaves the electric vehicle ahead overall. Plus, the electric car lets me "burn" coal, uranium, wind and solar in the vehicle.
For a suburban electric car, the industry desperately needs something inexpensive that will give them 15-20 kWh to start the day with...
Both articles pointed to by the original post note that rechargeable lithium-air batteries are in "early development". It may be worth noting that zinc-air batteries (fuel cells, more accurately, as these lithium devices are currently) have been available for some years now. The problem is the recharging step, ie, making it a battery instead of a fuel cell. Splitting zinc oxide to get relatively pure zinc back, all within the original container, remains an unsolved problem, in practice. These lithium devices will face the same problem: how do you use electricity to efficiently split lithium oxides to get lithium and oxygen again? If they have indeed solved that problem, and can apply it to other metals, zinc may be a better solution overall, even with somewhat lower energy density. The global mineral reserves are much larger and the problem with water goes away.
3) Determine the absolutely smallest possible component of this job that you need to do. Maybe a 5 minute job. If you can't break down a big job into smaller jobs, you're in the wrong business. Pick that smallest little job and do it. Write it down on a physical list and tick it off. Actually do this step.
4) Determine the next little job. Work a bit to find the next smallest task. Rinse and repeat.
Second this. I always find the biggest hurdle to be writing enough code for the application to do something. Once there, adding a feature/capability at a time is much easier. There is a down side to this approach (as there are to all approaches): it's easier to "code yourself into a corner". At some point you'll find that your data design doesn't support something you need, or that you've factored code badly. I accept that, and periodically set aside a day or two just to go back and clean up or reorganize.
Notice what the student is prepared for at the various points where they might leave this sequence: balance the checkbook, accounting/business planning, construction/design, medieval mechanical/civil engineering. Math in the public schools has never been about creating mathematicians, but creating crafts people of various sorts (just as the art program is not about creating real artists). Not math as an end to itself, but strictly math as a tool. Even when I was an undergraduate at a public university 30 years ago, there were calculus sections for math majors (small, where I was) and calculus sections for engineers (large, where most of my friends were). And we learned very different things in "calculus": they learned how to apply it, I learned how to prove it.
If I were going to change this sequence, I would drop geometry before I added anything. I loved geometry, for all the reasons that the essay identifies: an opportunity to create something beautiful out of ideas alone. Frustrated when the teacher asked, "How would all this change if we were doing it on the surface of a sphere, instead of on a plane?" and then didn't pursue it. But it's simply boring as hell for most people, and at least from my anecdotal experience, chases more kids out of applied math than anything else in the curriculum.
There are several idioms in F77 that must not be taught to future generations. Probably most importantly, the use of "common blocks", and "entry" points, and the hacks needed to get around the lack of dynamic memory allocation.
I know "computed goto" has been declared to be obsolete, but has it ever actually disappeared from the language? If not, I nominate them for inclusion on your list. I recall porting about 10,000 lines of code from one OS/compiler to another around 1977 that was simply riddled with the damned things. The original programmer had left comments indicating that he thought they were faster than function calls. Moving the code blocks into actual functions, and untangling the spaghetti that had grown up around the gotos, reduced the run time on the test cases by a consistent 25%.
Common blocks had their place at that time, although they could certainly be abused. The same program had a collection of subroutines (consistency was not the original coder's strong point) that each took 30-40 arguments, all but two or three being global state variables. A common block cleaned out all of that mess. As I recall, that change alone resulted in the program succeeding on several test problems that had been failing, due to multiple places where the variables in the argument list appeared in the wrong order.
But you have to give APL a bit of a pass in some respects. Like vi, it was designed in 1963 to work well within the constraints of a paper teletype.
The symbolic debugging capabilities built into IBM's APL system by the early 1970s spoiled me: breakpoints, stack traces, interactive examination of data structures on errors, etc. I recall getting permission from the professor to use APL instead of Fortran for third-semester numerical analysis. He considered it a failed experiment because I was treating assignments that were supposed to be two-week nightmares to code as weekend projects.
OTOH, you needed all of that because APL's name-scoping rules created situations where the simple bug of failing to make a variable name local to a function could result in all kinds of erratic behavior that was very difficult to track down.
The numbers involved in realistic energy production are so large, it's almost always worth doing some simple scale calculations. Consider a small nuke with 500 MW faceplate capacity. 500 MW times 365 days/year times 24 hours/day times availability of 0.8 (allow for repair and maintenance) is 3.504e9 kWh/year.
On the hemp side, a variety of sources give 9.0 dry tons/acre/year in temperate latitudes, 1.46e7 BTUs/ton, 2.928e-4 kWh/BTU at 100% efficiency, assume 0.4 thermal efficiency (traditional coal-fired plants are about 0.33), and availability of 1.0. These numbers are all on the generous side of their ranges. Multiply that and get 1.539e4 kWh/acre/year. Call it 227,680 acres to match the output of the small nuke. A square about 19 miles on a side.
OTOH, assume cheap low-efficiency solar panels. Assume daily solar flux of 5.0 kWh per square meter per day (parts of the US are better than that), efficiency of 0.05, and availability of 1.0. Multiply that all out and get 3.693e5 kWh/acre/year. About 9,488 acres to match the output of the small nuke. Overall, an efficiency gain of 24 in favor of the panels.
Sanity check: non-crop plants are about 1% efficient in converting solar flux to biomass, so a factor of 5.0 for solar panels; assumed thermal efficiency for biomass to electricity is a factor of 2.5 for panels; growing season of five months is a factor of roughly 2.0 for panels (five month growing season in temperate latitude, but it's the five months with greatest flux); that gives a factor of about 25 in favor of panels, which matches.
Dye-sensitized solar cells can be manufactured in a roll-to-roll process, have demonstrated efficiencies greater than 5% when produced in that fashion, and depending on advances in the materials that can be used, may drastically change the cost per watt for solar PV. And solar PV can use land that's much more "marginal" than what's needed to support hemp: deserts, semi-arid high plains, and rooftops.
Automatic figure placement
more like the floating bodies idea.
Indeed.
If it doesn't have floating displays,
it's still a toy.
If the new Word features will let me define a display that includes (for example) a graphic and the proper short descriptive material that is appropriately formatted, possibly including an end note,
and will automatically position the display at the next available point where there is adequate space,
with no extraneous white space at either the top or bottom of any page,
I might consider using it for preparing an academic textbook.
Certainly it's a useful toy,
but it's still a toy.
Early 1992, Manchester Computer Center (MCC) distribution on a half-dozen floppies, on a laptop with a 20 MHz 386 with external floating point unit, 4M of RAM, 40M hard disk, 640x480 monochrome display. Added a port of (then) Bellcore's MGR light-weight windowing system.
On an evening flight from New Jersey to Denver, I had the machine out with an analog clock in one window, was compiling something in another, and editing a document in a third. A guy headed back to his seat from the restroom stopped and yelled up the length of the plane, "Hey! This guy's got UNIX on a laptop!" Next thing I knew there were half-a-dozen people hanging over me, elbowing each other and some of the other passengers, all trying to see and asking questions at the same time. The flight attendants were NOT happy.
IIRC, recompiling the kernel on that machine took about 45 minutes.
Even if you could convince management that you can create wonderful things with open source they are still going to worry what would happen when you are gone.
And the degree of worry will -- properly -- increase with the degree of customization.
If management is doing their job right, they have to worry about the skill set they need in their organization.
If, for example, Linux/Perl/custom-app is not in the skill set the organization currently needs,
it is a major commitment for the management to add those to the list.
In the couple of years that I was acting as the group manager, I had to make a couple of decisions that I didn't like about tools, because I couldn't commit to keeping a particular set of skills on the staff over the long term.
And the corporate budget rules didn't allow me to commit to hiring outside expertise without very long lead times.
Slashdot Mirror
No, but the NRC currently has legal standing to regulate and license private possession of that much fissile material. One suspects that the NRC would not license "assemble a nuclear weapon". It might be entertaining to listen to the Supreme Court questioning, but it seems unlikely that the Court would rule Bill's second amendment rights trump the NRC's authority to regulate. After all, the Court has never ruled that the second amendment overrides the states' authority to regulate high explosives.
Technically, no, they can't arbitrarily "police" any vessel they wish. But private possession of that much fissile material without an appropriate license from a signatory government also certainly violates some UN treaty. That they can enforce (although they might want to make sure that one of the US, UK, France, Russia or China is willing to back them up on their interpretation of the treaty).
We could have more small, local generation of power from wind and solar...
With the emphasis on local. Bell Laboratories didn't create a million jobs (maybe 26,000 people at the peak, and the vast majority were not involved in research). AT&T created a million jobs involved in manufacturing the equipment and installing and operating the network. Primarily the local network -- AT&T Long Lines, the long-distance piece of the business, employed relatively few people. If wind and solar energy provide a million jobs, the large majority will be manufacturing, installation, and maintenance of the equipment -- not the research.
Yes, I have ISO file systems that I burned on CDs 15 years ago and current computers have no difficulty mounting them. I would still choose that over UDF (ISO 13346) on DVD for two reasons: lower density recording is typically more tolerant of physical degradation, and the video industry seems more likely to abandon DVD for higher capacity media than the music industry to abandon CD.
The formats for individual files are important too. On those oldest disks, I can still view the HTML, images in JPEG and GIF, and flat ASCII text files. Interestingly, groff handles the troff/mm files on the disk without any difficulties, but extracting the Word files took a bit more effort. The PostScript files on the disk still render just fine (no PDF files to try). The MPEG files on the disks play.
Some years back, this Slashdot story included several anecdotal examples of substantial bills for import duties showing up from the US Customs Service after a few months. For books purchased from individuals, probably not a large risk. If purchased from a business, which risks losing its export licenses, such sales are more likely to be eventually reported.
The version that took pictures of viewers never got used in customers' homes. The legal department was seriously concerned about how to write an agreement regarding the use of those images. I certainly have to wonder whether Comcast's legal department has looked at what needs to be added to the terms of service, and what the privacy requirements will be. If I believe my spouse has been cheating on me, can I get access to what was observed while I was out of town?
The members of the research group and I did have some odd conversations about whether the viewer snapshots should be disabled based on which channel was being watched...
No, and no. Microsoft's patent covers representation of certain data related to word processing. As you have wrapped something quite different in your document, you do not infringe on their patent nor is your application prior art for wrapping the kind of data covered by the MS patent.
After reading the claims, this strikes me as a classic "defensive" patent. MS is using XML in a particular way for something critical to their products (help files?) and since that particular use might be patentable, took steps to insure that no one else was going to get a patent for it and then extort money from MS. A company I worked for obtained patents on a couple of things I had developed with exactly this intent -- not to stop other people from using it, but to keep other people from stopping us from using it.
The obvious compromise is software like LyX, that has a GUI interface suitable for infrequent users but uses LaTeX to actually do page layout. I also think it will never be widely adopted because people who think in terms of WYSIWYG will be disturbed that the final page doesn't look like what they've been working on.
Or in some cases, much less control over the formatting and layout, which can be a good thing.
Many years ago, there was a development project at Bell Labs so large that there was an entire department for maintaining the technical documentation. The department head wanted to dump troff and the macros then in use and go to WYSIWYG. To justify his decision, he had the research people set up a controlled experiment with two groups of new people that received equal training in their respective tools. The troff people were about 25% more productive than WYSIWYG, and had significantly fewer formatting errors. When the psych people got done with their interviews and examining keystroke logs, they concluded that with formatting control available to them, almost everyone spends 20-25% of their time futzing with fonts, line and page breaks, etc. All of which is wasted time until very close to the end of the process.
Personally, when creating new text, I feel like I'm more productive if I can write flat files with a mark-up language, because I do get distracted by an ugly line break in a WYSIWYG tool. But I'm an old UNIX geek, and I don't expect the rest of the world to ever go away from WYSIWYG.
The only real "feature" in WordPerfect tables that isn't in Word is that they can be used as baby spreadsheets with formulas and macros. "Baby" in the sense of simple, I've seen WordPerfect tables that run to several hundred rows. There are times, particularly under deadline, when it's very, very nice to have text and live tables all in one document. This was a bigger deal ten years ago than it is now.
PerfectScript for macros is a nightmare. If anyone asks you to maintain old PerfectScript code, run away screaming.
Doesn't the department have some soft of coherent policy about software? I've taken classes at four colleges over the years (three degrees in three different fields), and the department always had a fairly narrow policy about what was acceptable and what was not. If simulation is a required part of the circuit design classes, I would expect the department to have a position on the software tools that was independent of instructors or textbooks. If for no other reason than if you got hit by a bus six weeks into the class, a substitute would be able to take over and know what tools the students were using.
To expand on that point, because it's inexpensive, it uses common materials, and it scales. The problem of "I have an object here that produces lots of heat energy, I'd like to convert that heat to useful work, please" is harder than it sounds.
Seriously, how do people who don't write quickly and clearly (cursive or printing) get through classes with heavy-duty math in college? I took a sequence of graduate economics classes within the last five years, and only about half the material covered was in the textbook. Much of the half not in the texts involved complex expressions involving integrals, differentiation, and matrix expressions. Most students notes for a 90-minute class ran to 3-5 pages of the stuff.
Is this going to be another reason for not producing engineers and scientists in the US? That we don't teach enough math because the students can't write fast enough to take notes on the material if taught at a reasonable pace?
==========
This is not realistic. You _can't_ get the requirements right up front because the users don't even know what they want until they have a system that doesn't have it. They think they told you what they want, but they didn't because they don't know themselves.
I have to agree with the parent. I've had an opportunity to watch the post-mortems on several large, failed software procurements by my state's government. My opinion is that the fundamental reason all of them failed was inadequate (sometimes grossly so) specification. I also agree with you, that the customer generally can't (or won't) do it. I believe the way I put it to one director was "If you can't specify the interfaces, the protocols, and a reasonably complete conceptual model of the data, you're paying $78 million for the vendor to guess." Given the price tags on large state software systems these days, government is going to have to figure out how to avoid buying $78 million prototypes that aren't going to be even close to right.
I'm an old grumpy guy, but am still looking for at least two features. Have they managed to put floating displays in this version? How about intelligent vertical white space, that gets suppressed as being unnecessary at the top of a column or page? Stuff should start at exactly the same place at the top of each page or column (excepting possibly the first page). And with the exception of a handful of cases involving the end of sections, there should never be more than a couple of blank lines at the bottom of a page. Fill the pages intelligently for me, please.
For many applications, this would certainly be a killer. What many of the researchers have in mind for high Wh/kg batteries is, of course, traction applications: cars, trucks, buses, etc. This class of application is characterized by frequent -- daily in most cases -- recharging. Even if 10-15% of the charge I start with in the morning is lost to self-discharge, the roughly 2:1 thermal efficiency gain of a commercial power plant relative to a typical ICE still leaves the electric vehicle ahead overall. Plus, the electric car lets me "burn" coal, uranium, wind and solar in the vehicle.
For a suburban electric car, the industry desperately needs something inexpensive that will give them 15-20 kWh to start the day with...
Both articles pointed to by the original post note that rechargeable lithium-air batteries are in "early development". It may be worth noting that zinc-air batteries (fuel cells, more accurately, as these lithium devices are currently) have been available for some years now. The problem is the recharging step, ie, making it a battery instead of a fuel cell. Splitting zinc oxide to get relatively pure zinc back, all within the original container, remains an unsolved problem, in practice. These lithium devices will face the same problem: how do you use electricity to efficiently split lithium oxides to get lithium and oxygen again? If they have indeed solved that problem, and can apply it to other metals, zinc may be a better solution overall, even with somewhat lower energy density. The global mineral reserves are much larger and the problem with water goes away.
Second this. I always find the biggest hurdle to be writing enough code for the application to do something. Once there, adding a feature/capability at a time is much easier. There is a down side to this approach (as there are to all approaches): it's easier to "code yourself into a corner". At some point you'll find that your data design doesn't support something you need, or that you've factored code badly. I accept that, and periodically set aside a day or two just to go back and clean up or reorganize.
If I were going to change this sequence, I would drop geometry before I added anything. I loved geometry, for all the reasons that the essay identifies: an opportunity to create something beautiful out of ideas alone. Frustrated when the teacher asked, "How would all this change if we were doing it on the surface of a sphere, instead of on a plane?" and then didn't pursue it. But it's simply boring as hell for most people, and at least from my anecdotal experience, chases more kids out of applied math than anything else in the curriculum.
I know "computed goto" has been declared to be obsolete, but has it ever actually disappeared from the language? If not, I nominate them for inclusion on your list. I recall porting about 10,000 lines of code from one OS/compiler to another around 1977 that was simply riddled with the damned things. The original programmer had left comments indicating that he thought they were faster than function calls. Moving the code blocks into actual functions, and untangling the spaghetti that had grown up around the gotos, reduced the run time on the test cases by a consistent 25%.
Common blocks had their place at that time, although they could certainly be abused. The same program had a collection of subroutines (consistency was not the original coder's strong point) that each took 30-40 arguments, all but two or three being global state variables. A common block cleaned out all of that mess. As I recall, that change alone resulted in the program succeeding on several test problems that had been failing, due to multiple places where the variables in the argument list appeared in the wrong order.
The symbolic debugging capabilities built into IBM's APL system by the early 1970s spoiled me: breakpoints, stack traces, interactive examination of data structures on errors, etc. I recall getting permission from the professor to use APL instead of Fortran for third-semester numerical analysis. He considered it a failed experiment because I was treating assignments that were supposed to be two-week nightmares to code as weekend projects.
OTOH, you needed all of that because APL's name-scoping rules created situations where the simple bug of failing to make a variable name local to a function could result in all kinds of erratic behavior that was very difficult to track down.
The numbers involved in realistic energy production are so large, it's almost always worth doing some simple scale calculations. Consider a small nuke with 500 MW faceplate capacity. 500 MW times 365 days/year times 24 hours/day times availability of 0.8 (allow for repair and maintenance) is 3.504e9 kWh/year.
On the hemp side, a variety of sources give 9.0 dry tons/acre/year in temperate latitudes, 1.46e7 BTUs/ton, 2.928e-4 kWh/BTU at 100% efficiency, assume 0.4 thermal efficiency (traditional coal-fired plants are about 0.33), and availability of 1.0. These numbers are all on the generous side of their ranges. Multiply that and get 1.539e4 kWh/acre/year. Call it 227,680 acres to match the output of the small nuke. A square about 19 miles on a side.
OTOH, assume cheap low-efficiency solar panels. Assume daily solar flux of 5.0 kWh per square meter per day (parts of the US are better than that), efficiency of 0.05, and availability of 1.0. Multiply that all out and get 3.693e5 kWh/acre/year. About 9,488 acres to match the output of the small nuke. Overall, an efficiency gain of 24 in favor of the panels.
Sanity check: non-crop plants are about 1% efficient in converting solar flux to biomass, so a factor of 5.0 for solar panels; assumed thermal efficiency for biomass to electricity is a factor of 2.5 for panels; growing season of five months is a factor of roughly 2.0 for panels (five month growing season in temperate latitude, but it's the five months with greatest flux); that gives a factor of about 25 in favor of panels, which matches.
Dye-sensitized solar cells can be manufactured in a roll-to-roll process, have demonstrated efficiencies greater than 5% when produced in that fashion, and depending on advances in the materials that can be used, may drastically change the cost per watt for solar PV. And solar PV can use land that's much more "marginal" than what's needed to support hemp: deserts, semi-arid high plains, and rooftops.
Indeed. If it doesn't have floating displays, it's still a toy. If the new Word features will let me define a display that includes (for example) a graphic and the proper short descriptive material that is appropriately formatted, possibly including an end note, and will automatically position the display at the next available point where there is adequate space, with no extraneous white space at either the top or bottom of any page, I might consider using it for preparing an academic textbook.
Certainly it's a useful toy, but it's still a toy.
Early 1992, Manchester Computer Center (MCC) distribution on a half-dozen floppies, on a laptop with a 20 MHz 386 with external floating point unit, 4M of RAM, 40M hard disk, 640x480 monochrome display. Added a port of (then) Bellcore's MGR light-weight windowing system.
On an evening flight from New Jersey to Denver, I had the machine out with an analog clock in one window, was compiling something in another, and editing a document in a third. A guy headed back to his seat from the restroom stopped and yelled up the length of the plane, "Hey! This guy's got UNIX on a laptop!" Next thing I knew there were half-a-dozen people hanging over me, elbowing each other and some of the other passengers, all trying to see and asking questions at the same time. The flight attendants were NOT happy.
IIRC, recompiling the kernel on that machine took about 45 minutes.
And the degree of worry will -- properly -- increase with the degree of customization. If management is doing their job right, they have to worry about the skill set they need in their organization. If, for example, Linux/Perl/custom-app is not in the skill set the organization currently needs, it is a major commitment for the management to add those to the list. In the couple of years that I was acting as the group manager, I had to make a couple of decisions that I didn't like about tools, because I couldn't commit to keeping a particular set of skills on the staff over the long term. And the corporate budget rules didn't allow me to commit to hiring outside expertise without very long lead times.