Does anybody actually believe that we have progressed significantly in our use of tech to educate? I sure don't.
Really? Try getting rid of the tech then. Unplug the computers in the library and research using a card catalog. All written assignments must be typed on a typewriter. Tests, quizes and handouts will be typed or hand-written by the teacher and copied on a mimeograph machine. In science, all measurements will be made by hand and all lab reports will include hand-made calculations and hand drawn charts. To avoid having the kids calculate for 6 hours to generate a chart, they will be restricted to 4 measurements of their data.
If a child forgets an assignment, they'll have to call a friend, who will read it to them over the phone while they copy furiously (and incorrectly).
Video demonstrations or presentations in the classroom will go away. After all, it means finding it (in the library, on the card catalog, and hoping that we have such a tape), copying it on a VHS tape, wheeling the TV and VCR into the classroom (they're too bulky and expensive to put one in each room) and hoping that everything works.
Technology has had a HUGE effect on education, just as it has on everything else
I believe that most buffer overrun exploits work by overwriting a function's return address on the stack. These could be largely avoided by the compiler using either of two techniques. First, it could grow the stack into higher numbered addresses and store the return address first. Now if the code allows a buffer overrun, it will overrun the local variables and spill into the available stack space. In both cases, the chances of finding a function pointer are small. In contrast, if you grow the stack into smaller numbered addresses, then a buffer overrun has pretty much 100% chance to overwrite a code pointer (the return address).
The other technique is to use two stacks, one for the return addresses and another for the parameters/return values. Same idea though: move the return address out of the way of the overflowed buffer.
Personally, I stopped using the SETI@home screen saver years ago when I realized that it was burning an image in my screen - kind of the opposite of what a screen saver is supposed to do. Sure it won't happen now with my flat screen, but it pissed me off so much that I won't use it again.
I disagree. Software programmers followed hardware designers into 64k segments, expanded memory, tiny, small, large and huge pointer, memory overlays and on and on, just because that's what was available.
If your competitor's software takes advantage of 20 cores and yours doesn't , you're going out of business.
You may be right about the RBS's data, but notice here that we're talking about CD images, and quite likely BACKUPS.... Although many companies are very careful with their data, they seem to be really relaxed about those backup thingies.
As someone who buys his backup tapes used on ebay, I know this first hand. So to the various past sellers of backup tapes, I'd just like to say "thanks for the pictures of the vacation in France," "Thanks for the mountain of software installation files," "Don't store your gay porn on your office PC, you never know who will find it," "I like your procedure of giving two written warnings to employees before firing them, but clearly you should have canned that one guy earlier."
Trust me, these examples are all real and they are the beneign ones. I won't even mention some of the more serious stuff I've gotten. If I did, I'm sure the companies involved would get the cops after me as a way to divert attention from their own incompetence.
I think the article that the author refers to hints at the answer. The way to build good software is the same as the way to build good buildings.
To build a good building, we have building codes that have been carefully thought out and they're enforced by law. In software we have the design fad du jour and programmers get defensive when you suggest that anyone, even a peer, review their code. Suggesting that they be legally bound to a set of principles simply sends them off the deep end (see the stream of flames that this will generate for an example). But think about it - we require enforced standards in buildings for quality and safety. Why shouldn't we require the same thing in software?
In the building industry we have licensed contractors who should know the codes and follow them. In software, anyone can do it. A lot of them aren't very good.
In the building industry, if you want a nail, you walk into Home Depot and there's an entire aisle full of them. There are long nails and short ones, thin and fat ones, nails that are coated to prevent rust, nails with wide heads for roofing, nails with a square shaft that's twisted so they spiral in, skinny nails with a dimple so they can be counter sunk (finishing nails) etc. etc. Oh, and that doesn't even begin to talk about the slight variations on nails. There are screws (nails that burrow in), staples (two connected nails), spikes, and on and on and on.
The point is that there's a nail for each specific need.
Now consider the sofware industry. Suppose you need a list. I'm a C++ programmer and until a few years ago, if you needed a list, you rolled your own or maybe used one from a commercial library. Only just recently have templates made lists easy and only more recently has the STL given us a standard. But if you want a list you have 1 choice.
If software was like the building industry, I could open a catalog and choose from all sorts of lists: singly linked lists, doubly linked lists, lists that own the objects within them and lists that don't, lists that are thread safe and ones that aren't, lists that allow callback functions when you insert/delete, lists that keep ref counts, lists that ensure an item can only be on one of them at a time, etc. etc. etc.
The point is that there would be a standard component to do almost anything I want. Today we write and rewrite the same stuff over and over again and each time someone new does it, they make some of the same mistakes, both obvious and subtle.
If people built houses the way we build software, there would be a sawmill at every job site and the contractor would be using studs of his own favorite size. There would be a metal forge there too where the they'd be making nails in whatever dimensions seemed handy and out of whatever metals they felt like.
In fact, a year is defined as the period between cooresponding equinoxes. (equinoxi? equinois?) That's the same as your second option "zenith on shortest day to zenith on shortest day". This definition takes the earth's precession into account (the way it wobbles slowly like a top). If a year were a single 360 degree revolution, then over time to seasons would migrate around the calendar as the earth precessed.
The idea of a leap second is to keep the official time aligned with the mean solar time, so that, on average, the sun is at its zenith over Greenwich at noon. I say "on average" because the length of a solar day (sun zenith to sun zenith) changes throughout the year as the earth speeds up and slows down in its eliptical orbit.
Leap seconds counteract several natural phenomena:
24 hrs isn't precisely the length of an average day
The earth's rotation slows slightly each year due to tidal effects of the moon
The earth's rotation changes slightly over time as mass redistributes.
Turing equivalence and Lambda expressions are great theoretical constructs, but when it comes to translating from one computation model to another, they are about as useful as knowing the cellular structure of wood fibers would be to a house builder. Having translated between computation models, I know this.
Programming is not trivial and it is more than just computer science. In addition to reading existing code (a great tip, I'd recommend:
Make your code readable. Try to make it clear what you're doing. Just because C++ lets you do weird compact and convoluted things all in one statement doesn't mean that you should do it.
Use comments! This is perhaps the most important thing of all. If your code is dealing with a subtle case in a strange way, mention that in a comment. COmment what each function does. Use comments to explain WHY you're doing something and let the code say WHAT you're doing.
Deal with errors. You know the 90-10 rule? That's the one that says that 10% of the code executes 90% of the time? Well guess what that 10% of the code is? It's the straight-line sunny-day functionality of your program. The other 90% is error handling and each line if error handling code takes just as long to write as the sunny-day stuff. So think about the error cases and write code to handle them.
Which debugger do you use? Is it graphical and easy to get around? I'm surprised how many people use command-line debuggers, which is just insanity to me. Find and learn a good debugger. You're going to need it.
The really interesting thing is to consider how this genetic interchange will play out in the future. Now that people travel the globe more easily, inter-ethnic mating is becoming much more common place, so how long will it take before most of our descendents all look the same? And what will they look like?
Grabbing the back of an envelope, I figure that in 30 generations, each person would have about 1 billion ancestors from our generation if there were no mixing of ancestors. Clearly mixing occurs, but after that much time, I suspect most people will have many, many ancestors from all over the world. At 25 years per generation, that's just 750 years. So it seems plausible that in about 750 years, a large segment of the population will have a uniform ethnicity.
What will they look like? My guess is that present-day Central and South America have the most ethnically mixed populations. The original inhabitants came from Asia and they've had European and African people there for several hundred years.
obviously they did not know or it wouldn't have happened
That is quite untrue. The engineers were so concerned about the O-rings performance under cold temperatures that they refused to sign off on their launch worthiness the morning of the launch. A VP signed off instead. So basically, people knew that they were taking a huge risk, but that fact was suppressed and never reached the top level management. The challenger disaster really is a case where people just plain screwed up. They really should have known.
There was also the fact that the launch had been delayed several times before, it was incredibly high profile because of the civilian onboard, and Ronald Regan was planning to give his State of the Union address that night. Thus, there was immense political pressure to get the thing off the ground.
The Columbia disaster is a different animal altogether. They were certain that the debris from the booster tank wouldn't injure the wing significantly. They even ran some calculations after the launch to reconfirm the theory. After the disaster, they initially said that it couldn't have been the debris. It wasn't until they threw a piece of insulation at a piece of wing in a wind tunnel and it knocked an 18" hole in the wing that they realized something was seriously wrong with their understanding of the physics and materials involved.
Piracy isn't theft. Theft is the action in wich one denies others acces to the stolen goods.
So if my extended family and I move into your place, does that mean we can have you arrested if you try to deny us access?
Piracy is theft, plain and simple. Just because it's easy doesn't make it right. People work hard to produce that CD and they have an expectation and a right to be compensated. If you don't agree, then please come to my place tomorrow and paint my house for free.
You say that calculators are slower and more error prone that mental math. Why, then, would anyone buy one? They are, of course, faster and less prone to errors.
Even aside from that, knowing "how to achieve what the calculator does" is fundamentally important in understanding higher-math concepts. You might be able to commit to memory that performing x function on y set of numbers yields z result, but if you never fully grok why that result is yielded, then your understanding will be severely limited.
This is also nonsense. Nearly everyone knows how to do long division, but do they know why the procedure yields the correct answer? Hardly anyone does. So what higher math concept does this teach? Most people don't know or have forgotten, or were never taught, other concepts like why algebra works, or why you can cancel common factors to reduce a fraction. They just know a procedure that yields the right answer. So what difference does it make if the procedure is "cross out these numbers" or if it's "press these keys"?
Okay, 600 DPI on an 8.5" wide paper at 800mm/second. That's 8.5*800/25.4=267in^2/sec. 267*600*600 = 96.12*10^6 dots/sec. If each dot is 3 bits (one for each of 3 colors), that's 288.36Mbps.
This is just a back-of-the-envelope calculation. Most print jobs don't print every dot and the driver could compress the stream, but the point is that this thing would require some serious bandwidth.
I agree completely. The article (and the company) seem to be placing blame in completely the wrong place. A risk assessment may have shown that the software was old and no one was fluent in fortran, but it probably would not have shown the actual error that caused the shutdown.
The only way to detect this sort of problem is to look back at the requirements document (assuming that there is one) for the software and see if the requirements and assumptions still hold true. But who does that?
I understand the concept of software getting brittle, but perhaps the analogy isn't so good. Really, the requirements and data that the software must handle change, so we ask it to do more and more stuff, and using input that is farther and farther from the original design constraints. Eventually, something like this happens.
I agree. People seem to be upset that someone stole their identity. But we should really be upset that LexisNexis has our identifying information and sells it everyday.
If someone has your identifying information, what difference does it make whether they bought it or stole it?
No media lasts forever, so what really matters when archiving data is that you know how long it will last. That way you can copy the data to new media (and possibly a new format) before the media goes bad.
My father used a DECmate II word processor throughout the 1980's. After he died in 1992, I spent considerable time figuring out how to covert those files into MS Word format. About a year ago, I went to read of his documents again and found that Word wouldn't convert the doc (I didn't have the Word-for-DOS converter installed). As a result, I spent an evening converting all the files again, this time to Word 2000 format.
And of course, along the way the data has gone from 5.25" floppy disk, to MFM and RLL hard disks, to SCSI and now IDE as I've done hardware upgrades. I'd be in real trouble if those Word for DOS files had been on an RLL hard drive in the closet instead of being in the/archive directory of my home computer.
SO the lesson is that both the hardware and software technology changes rapidly. My advice is to copy the data and convert it to a modern format every 5-10 years. Always keep the original format too, just in case you turn out to have a picture of the Grassy Knoll or something equally valuable.
They missed eyeglasses.
But by far the most useful small gadget in the history of the planet is cash and coins. Before cash you had to barter for everything or make it yourself.
Compuserve used to have a great password generation mechanism. They used two common words separated by a punctuation mark, like "sofa'cloud" or "mouse=light". They sent me my password, I read it once, and never forgot it.
I'll never cease to be amazed by the stupidity of psychologists. The word superiority effect occurs because we recognize the word (through whatever means) first. When later asked if a particular letter appeared, we don't *recall* the answer from memory, we *derive* the answer from our knowledge of the spelling of the word. In other words, if I see the phrase "dumbass shrink" flashed before me and then a nitwit asks "did you see the letter k?", I my brain doesn't remember seeing the letter k at all. Instead I think "I saw 'dumbass shrink'. That's spelled d-u-m-b-a-s-s-s-h-r-i-n-k, and yes, there's a 'k' in there." So word superiority only shows that we can quickly recognize words. It doesn't tell us anything AT ALL about how.
I have no sympathy for the poster at all. Sometimes programming involves some real grunt work. Roll up your sleeves and just do it. Yes, see if you can come up with a tool that will automate some or all of the task, but sometimes, you just have to do some boring work.
I've seen really, really promising projects fail because programmers were simply too lazy to do a week's worth of this sort of grunt work. I've seen easily avoidable bugs introduced into software because programmers were too lazy to check for all the implications of their change, even when this just meant searching the source code for all instances of a function call or class name.
Do the grunt work. Get the code right, move on to something more interesting.
I'd be curious to apply the same principles to project planning software. You never really know how long somthing is going to take, you only have an estimate. I bet that if you factored in the uncertainty of each task, you'd find that the schedule and budget of any project has margin of error of at least 50% , and maybe as high as 200% - 300%.
Hmm. Of course a tool that let you make such a prediction would probably not sell very well:
"Johnson! when is the Passaic project going to be done?" "Somewhere between 1 and 3 years, Mr. President." "You're fired. Get me someone who knows how to make a prediction."
The people receiving the prediction don't want to hear about the uncertainty, even though it's clearly present. It's a case of market forces favoring ignorance.
Many of the physical attributes that are sited as evidence of water are really only evidence of large amounts of liquid. I think an earthly bias causes us to assumes that streams and rivers must have been filled with water instead of somthing else in liquid form. Maybe liquid CO2? It seems like a stretch to say there were vast amounts of a liquid that's barely present at all any more.
The code we write today is different from what we wrote 15 years ago, but that's a result of the standardization that I'm advocating. 15 years ago, we still had the same collections and the same algorithms. Knuth is still as relavant today as he was 30 years ago. Excel and Word do the same basic things today that Lotus 123 and Wordstar did in 1983. But back then we didn't have OOP to help organize the code, or things like STL to make collections and algorithms a little easier.
So I think that the problem's we're trying to solve and the general concepts that we have to solve them are mostly constant. What we need are standard tools that implement those concepts
The one thing that has changed over the years is the user interface, both in terms in input and output. I expect that to continue to change over the years to come.
Slashdot Mirror
Does anybody actually believe that we have progressed significantly in our use of tech to educate? I sure don't.
Really? Try getting rid of the tech then. Unplug the computers in the library and research using a card catalog. All written assignments must be typed on a typewriter. Tests, quizes and handouts will be typed or hand-written by the teacher and copied on a mimeograph machine. In science, all measurements will be made by hand and all lab reports will include hand-made calculations and hand drawn charts. To avoid having the kids calculate for 6 hours to generate a chart, they will be restricted to 4 measurements of their data.
If a child forgets an assignment, they'll have to call a friend, who will read it to them over the phone while they copy furiously (and incorrectly).
Video demonstrations or presentations in the classroom will go away. After all, it means finding it (in the library, on the card catalog, and hoping that we have such a tape), copying it on a VHS tape, wheeling the TV and VCR into the classroom (they're too bulky and expensive to put one in each room) and hoping that everything works.
Technology has had a HUGE effect on education, just as it has on everything else
I believe that most buffer overrun exploits work by overwriting a function's return address on the stack. These could be largely avoided by the compiler using either of two techniques. First, it could grow the stack into higher numbered addresses and store the return address first. Now if the code allows a buffer overrun, it will overrun the local variables and spill into the available stack space. In both cases, the chances of finding a function pointer are small. In contrast, if you grow the stack into smaller numbered addresses, then a buffer overrun has pretty much 100% chance to overwrite a code pointer (the return address).
The other technique is to use two stacks, one for the return addresses and another for the parameters/return values. Same idea though: move the return address out of the way of the overflowed buffer.
Personally, I stopped using the SETI@home screen saver years ago when I realized that it was burning an image in my screen - kind of the opposite of what a screen saver is supposed to do. Sure it won't happen now with my flat screen, but it pissed me off so much that I won't use it again.
I disagree. Software programmers followed hardware designers into 64k segments, expanded memory, tiny, small, large and huge pointer, memory overlays and on and on, just because that's what was available. If your competitor's software takes advantage of 20 cores and yours doesn't , you're going out of business.
You may be right about the RBS's data, but notice here that we're talking about CD images, and quite likely BACKUPS.... Although many companies are very careful with their data, they seem to be really relaxed about those backup thingies.
As someone who buys his backup tapes used on ebay, I know this first hand. So to the various past sellers of backup tapes, I'd just like to say "thanks for the pictures of the vacation in France," "Thanks for the mountain of software installation files," "Don't store your gay porn on your office PC, you never know who will find it," "I like your procedure of giving two written warnings to employees before firing them, but clearly you should have canned that one guy earlier."
Trust me, these examples are all real and they are the beneign ones. I won't even mention some of the more serious stuff I've gotten. If I did, I'm sure the companies involved would get the cops after me as a way to divert attention from their own incompetence.
I think the article that the author refers to hints at the answer. The way to build good software is the same as the way to build good buildings.
To build a good building, we have building codes that have been carefully thought out and they're enforced by law. In software we have the design fad du jour and programmers get defensive when you suggest that anyone, even a peer, review their code. Suggesting that they be legally bound to a set of principles simply sends them off the deep end (see the stream of flames that this will generate for an example). But think about it - we require enforced standards in buildings for quality and safety. Why shouldn't we require the same thing in software?
In the building industry we have licensed contractors who should know the codes and follow them. In software, anyone can do it. A lot of them aren't very good.
In the building industry, if you want a nail, you walk into Home Depot and there's an entire aisle full of them. There are long nails and short ones, thin and fat ones, nails that are coated to prevent rust, nails with wide heads for roofing, nails with a square shaft that's twisted so they spiral in, skinny nails with a dimple so they can be counter sunk (finishing nails) etc. etc. Oh, and that doesn't even begin to talk about the slight variations on nails. There are screws (nails that burrow in), staples (two connected nails), spikes, and on and on and on.
The point is that there's a nail for each specific need.
Now consider the sofware industry. Suppose you need a list. I'm a C++ programmer and until a few years ago, if you needed a list, you rolled your own or maybe used one from a commercial library. Only just recently have templates made lists easy and only more recently has the STL given us a standard. But if you want a list you have 1 choice.
If software was like the building industry, I could open a catalog and choose from all sorts of lists: singly linked lists, doubly linked lists, lists that own the objects within them and lists that don't, lists that are thread safe and ones that aren't, lists that allow callback functions when you insert/delete, lists that keep ref counts, lists that ensure an item can only be on one of them at a time, etc. etc. etc.
The point is that there would be a standard component to do almost anything I want. Today we write and rewrite the same stuff over and over again and each time someone new does it, they make some of the same mistakes, both obvious and subtle.
If people built houses the way we build software, there would be a sawmill at every job site and the contractor would be using studs of his own favorite size. There would be a metal forge there too where the they'd be making nails in whatever dimensions seemed handy and out of whatever metals they felt like.
In fact, a year is defined as the period between cooresponding equinoxes. (equinoxi? equinois?) That's the same as your second option "zenith on shortest day to zenith on shortest day". This definition takes the earth's precession into account (the way it wobbles slowly like a top). If a year were a single 360 degree revolution, then over time to seasons would migrate around the calendar as the earth precessed.
The idea of a leap second is to keep the official time aligned with the mean solar time, so that, on average, the sun is at its zenith over Greenwich at noon. I say "on average" because the length of a solar day (sun zenith to sun zenith) changes throughout the year as the earth speeds up and slows down in its eliptical orbit.
Leap seconds counteract several natural phenomena:
24 hrs isn't precisely the length of an average dayThe earth's rotation slows slightly each year due to tidal effects of the moon
The earth's rotation changes slightly over time as mass redistributes.
You have a PhD, don't you?
Turing equivalence and Lambda expressions are great theoretical constructs, but when it comes to translating from one computation model to another, they are about as useful as knowing the cellular structure of wood fibers would be to a house builder. Having translated between computation models, I know this.
Programming is not trivial and it is more than just computer science. In addition to reading existing code (a great tip, I'd recommend:
Make your code readable. Try to make it clear what you're doing. Just because C++ lets you do weird compact and convoluted things all in one statement doesn't mean that you should do it. Use comments! This is perhaps the most important thing of all. If your code is dealing with a subtle case in a strange way, mention that in a comment. COmment what each function does. Use comments to explain WHY you're doing something and let the code say WHAT you're doing. Deal with errors. You know the 90-10 rule? That's the one that says that 10% of the code executes 90% of the time? Well guess what that 10% of the code is? It's the straight-line sunny-day functionality of your program. The other 90% is error handling and each line if error handling code takes just as long to write as the sunny-day stuff. So think about the error cases and write code to handle them. Which debugger do you use? Is it graphical and easy to get around? I'm surprised how many people use command-line debuggers, which is just insanity to me. Find and learn a good debugger. You're going to need it.The really interesting thing is to consider how this genetic interchange will play out in the future. Now that people travel the globe more easily, inter-ethnic mating is becoming much more common place, so how long will it take before most of our descendents all look the same? And what will they look like?
Grabbing the back of an envelope, I figure that in 30 generations, each person would have about 1 billion ancestors from our generation if there were no mixing of ancestors. Clearly mixing occurs, but after that much time, I suspect most people will have many, many ancestors from all over the world. At 25 years per generation, that's just 750 years. So it seems plausible that in about 750 years, a large segment of the population will have a uniform ethnicity.
What will they look like? My guess is that present-day Central and South America have the most ethnically mixed populations. The original inhabitants came from Asia and they've had European and African people there for several hundred years.
obviously they did not know or it wouldn't have happened
That is quite untrue. The engineers were so concerned about the O-rings performance under cold temperatures that they refused to sign off on their launch worthiness the morning of the launch. A VP signed off instead. So basically, people knew that they were taking a huge risk, but that fact was suppressed and never reached the top level management. The challenger disaster really is a case where people just plain screwed up. They really should have known.
There was also the fact that the launch had been delayed several times before, it was incredibly high profile because of the civilian onboard, and Ronald Regan was planning to give his State of the Union address that night. Thus, there was immense political pressure to get the thing off the ground.
The Columbia disaster is a different animal altogether. They were certain that the debris from the booster tank wouldn't injure the wing significantly. They even ran some calculations after the launch to reconfirm the theory. After the disaster, they initially said that it couldn't have been the debris. It wasn't until they threw a piece of insulation at a piece of wing in a wind tunnel and it knocked an 18" hole in the wing that they realized something was seriously wrong with their understanding of the physics and materials involved.
So if my extended family and I move into your place, does that mean we can have you arrested if you try to deny us access?
Piracy is theft, plain and simple. Just because it's easy doesn't make it right. People work hard to produce that CD and they have an expectation and a right to be compensated. If you don't agree, then please come to my place tomorrow and paint my house for free.
Oh hogwash.
You say that calculators are slower and more error prone that mental math. Why, then, would anyone buy one? They are, of course, faster and less prone to errors.
This is also nonsense. Nearly everyone knows how to do long division, but do they know why the procedure yields the correct answer? Hardly anyone does. So what higher math concept does this teach? Most people don't know or have forgotten, or were never taught, other concepts like why algebra works, or why you can cancel common factors to reduce a fraction. They just know a procedure that yields the right answer. So what difference does it make if the procedure is "cross out these numbers" or if it's "press these keys"?
Okay, 600 DPI on an 8.5" wide paper at 800mm/second. That's 8.5*800/25.4=267in^2/sec. 267*600*600 = 96.12*10^6 dots/sec. If each dot is 3 bits (one for each of 3 colors), that's 288.36Mbps.
This is just a back-of-the-envelope calculation. Most print jobs don't print every dot and the driver could compress the stream, but the point is that this thing would require some serious bandwidth.
I agree completely. The article (and the company) seem to be placing blame in completely the wrong place. A risk assessment may have shown that the software was old and no one was fluent in fortran, but it probably would not have shown the actual error that caused the shutdown.
The only way to detect this sort of problem is to look back at the requirements document (assuming that there is one) for the software and see if the requirements and assumptions still hold true. But who does that?
I understand the concept of software getting brittle, but perhaps the analogy isn't so good. Really, the requirements and data that the software must handle change, so we ask it to do more and more stuff, and using input that is farther and farther from the original design constraints. Eventually, something like this happens.
I agree. People seem to be upset that someone stole their identity. But we should really be upset that LexisNexis has our identifying information and sells it everyday.
If someone has your identifying information, what difference does it make whether they bought it or stole it?
No media lasts forever, so what really matters when archiving data is that you know how long it will last. That way you can copy the data to new media (and possibly a new format) before the media goes bad. My father used a DECmate II word processor throughout the 1980's. After he died in 1992, I spent considerable time figuring out how to covert those files into MS Word format. About a year ago, I went to read of his documents again and found that Word wouldn't convert the doc (I didn't have the Word-for-DOS converter installed). As a result, I spent an evening converting all the files again, this time to Word 2000 format. And of course, along the way the data has gone from 5.25" floppy disk, to MFM and RLL hard disks, to SCSI and now IDE as I've done hardware upgrades. I'd be in real trouble if those Word for DOS files had been on an RLL hard drive in the closet instead of being in the /archive directory of my home computer.
SO the lesson is that both the hardware and software technology changes rapidly. My advice is to copy the data and convert it to a modern format every 5-10 years. Always keep the original format too, just in case you turn out to have a picture of the Grassy Knoll or something equally valuable.
They missed eyeglasses. But by far the most useful small gadget in the history of the planet is cash and coins. Before cash you had to barter for everything or make it yourself.
Compuserve used to have a great password generation mechanism. They used two common words separated by a punctuation mark, like "sofa'cloud" or "mouse=light". They sent me my password, I read it once, and never forgot it.
I'll never cease to be amazed by the stupidity of psychologists. The word superiority effect occurs because we recognize the word (through whatever means) first. When later asked if a particular letter appeared, we don't *recall* the answer from memory, we *derive* the answer from our knowledge of the spelling of the word. In other words, if I see the phrase "dumbass shrink" flashed before me and then a nitwit asks "did you see the letter k?", I my brain doesn't remember seeing the letter k at all. Instead I think "I saw 'dumbass shrink'. That's spelled d-u-m-b-a-s-s-s-h-r-i-n-k, and yes, there's a 'k' in there." So word superiority only shows that we can quickly recognize words. It doesn't tell us anything AT ALL about how.
C++ doesn't support a NULL reference. So you can't make a variable length data structure with references.
Also, you can't modify a reference, only the thing referred to.
I have no sympathy for the poster at all. Sometimes programming involves some real grunt work. Roll up your sleeves and just do it. Yes, see if you can come up with a tool that will automate some or all of the task, but sometimes, you just have to do some boring work.
I've seen really, really promising projects fail because programmers were simply too lazy to do a week's worth of this sort of grunt work. I've seen easily avoidable bugs introduced into software because programmers were too lazy to check for all the implications of their change, even when this just meant searching the source code for all instances of a function call or class name.
Do the grunt work. Get the code right, move on to something more interesting.
I'd be curious to apply the same principles to project planning software. You never really know how long somthing is going to take, you only have an estimate. I bet that if you factored in the uncertainty of each task, you'd find that the schedule and budget of any project has margin of error of at least 50% , and maybe as high as 200% - 300%.
Hmm. Of course a tool that let you make such a prediction would probably not sell very well:
"Johnson! when is the Passaic project going to be done?"
"Somewhere between 1 and 3 years, Mr. President."
"You're fired. Get me someone who knows how to make a prediction."
The people receiving the prediction don't want to hear about the uncertainty, even though it's clearly present. It's a case of market forces favoring ignorance.
Many of the physical attributes that are sited as evidence of water are really only evidence of large amounts of liquid. I think an earthly bias causes us to assumes that streams and rivers must have been filled with water instead of somthing else in liquid form. Maybe liquid CO2? It seems like a stretch to say there were vast amounts of a liquid that's barely present at all any more.
So I think that the problem's we're trying to solve and the general concepts that we have to solve them are mostly constant. What we need are standard tools that implement those concepts
The one thing that has changed over the years is the user interface, both in terms in input and output. I expect that to continue to change over the years to come.