In the early nineties I was contracting for a large financial institution that were re-training COBOL programmers to be C programmers. I was called in to fix the most awful C code that I've ever seen, before or since. e.g. Functions that would span for 25 pages and blow up compilers.. Later of course, they needed all those COBOL programmers back for Y2K. Now they need 'em back for the boomers retiring. Such foresight.
Here's a thought.. What about building a modern language preprocesser that spit out COBOL? Something like RATFOR did for Fortran?
I bought an HP-41C about 40 years ago. The software (and hardware) was brilliant. Still use it and it still works. It was so well designed that even the infamous Y2K problem didn't impact it. Brilliant!
Hopefully the bar is a tad higher for developers creating heart monitors and aviation electronics is higher than the usual software (and hardware) today..
I can remember reading in an encyclopedia back in the early 60's, about engineers at GE needing to build in a failure mechanism because they lasted too long. Unfortunately have forgotten which encyclopedia and they've long since gone.. Stuck out in my memory however..
Sorry to see you leaving, but happy that you're on a new road to fresh opportunities. I've been a reader (and occasional contributer) since the early days..
BTW, I think your personal website is being slashdotted..;-)
Speed isn't the problem, unless you consider that the slower drivers are the ones causing many of the accidents.
As a rule (with few exceptions), it is the fast drivers who are paying attention to the driving. (They have to.) The drivers doing the speed limit are often also daydreaming, talking with other passengers (looking them in the eyes while doing it), talking on their cell phones etc. Unfortunately, the police don't have an "attention detector" to point at you before pulling you off the road for hazardous driving. (It's much easer to build a radar detector to collect revenue and pretend that it's for public safety.)
So the poor drivers continue to clog the passing lanes, oblivious to the traffic piling up behind them in dangerously close distances just waiting for multi-car pilups. (If they observe other traffic at all, I'm sure they remark to their passengers about the cars "weaving in and out" that are trying to get around them.)
If the authorities were *actually* concerned about making roads safer, they'd be better off having periodic mandatory testing of drivers and roadworthiness of cars. It might actually get much of the riff-raff off the roads and make them a safer place. Perhaps classifying drivers, safe for highway speeds, only safe for slower speeds (and some unsafe at any speed..)
I'm wondering if anyone else has been having similar problems with Verisign this week. I made a simple change to add a new nameserver to the existing five nameservers for six domains I administer. Everything looked fine; their web interface confirmed the changes.
The next morning, all h*ll broke loose, as the root nameservers were now returning the infamous 64.94.110.11 on these valid domains!! Checking the whois database revealed that the nameserver addition had not taken place, but the previous five nameservers were still there and still valid. Checking with the Verisign web interface showed the same five nameservers. Nevertheless, the root nameservers were acting as though these domains did not exist!!
I have 46 domains registered with Verisign and have been using Network Solutions for ten years. This qualifies me as a "VIP" client I guess. So I've been calling the VIP hotline for two days now and have five trouble tickets, to no avail. They can see the problem, they admit that it's a Verisign problem, but all they can say is that it may take five to seven days to fix!!
I've spoken with people who say they are in Pennsylvania and they can't talk directly to the engineers because "they're in Virginia". And I've spoken with people in Virginia who say they can't talk with the engineers because they're in Pennsylvania!
Meanwhile, whois is returning valid information while the root domain servers are just serving up the wildcard. I'm stuck and being held hostage by Verisign...
What about using a biometric finger scanning device on the control column (or stick on an Airbus) where the finger being scanned must belong to the pilot or co-pilot, and it must be alive and warm (to prevent them from cutting a finger off and taping it to the sensor)? These type of devices are used by many ISPs now.
If a finger belonging to someone else takes control, or perhaps if neither pilot or co-pilot touches the sensor within a given period of time, flags go up somewhere at flight services.
Of course, we also need to rewrite the chapters in the procedures manuals for flight services on what to do when they get these red flags popping up...
And of course the circuitry (necessary radios etc) will need to have a separate set of circuit breakers somehow, or perhaps the absense of the periodic finger cabin check puts the flags up at the FSS.
I was once involved with rolling out an application for worldwide deployment by a multinational company. Through that experience I learned that HTML with perhaps a Java front-end for doing field validation and such makes the most sense.
This is not a bandwidth issue, but an issue with the "speed of light" and the long latency times to get packets around the world. (The situation I was involved with required servers in north america, while some of the offices were as far away as Hong Kong.)
As much as I love Xwindows, this was totally unsuitable because much of the underlying chit-chat for the X protocol is "synchronous", meaning that the client will send requests to the X display server and wait (and wait) for it to respond before sending the next request. There can be hundreds of transactions like this just to bring up a simple window, meaning that it can take several minutes. Bandwidth was not the issue.
Since the application was written using X, we also tried dxpc, lbx and other compression techniques. It improved, but not by much.
The thing is, with that kind of latency, even telnet sessions are not very nice!
We also tried various techniques of client/server, distributed database, VNC's, caching etc.
What really works is some kind of an HTML front-end, which let's face it, is very much like the block mode 3270 terminals of yore with a bit of window dressing. This gives the users the perception of a responsive application most of the time, unlike the other solutions we tried.
I'm not fond of Java as a general purpose language, and I certainly don't think there is any benefit to using it on the server side where performance is usually more of an issue, but on the client side to facilitate the front end of an application it does make sense.
Slashdot Mirror
In the early nineties I was contracting for a large financial institution that were re-training COBOL programmers to be C programmers. I was called in to fix the most awful C code that I've ever seen, before or since. e.g. Functions that would span for 25 pages and blow up compilers.. Later of course, they needed all those COBOL programmers back for Y2K. Now they need 'em back for the boomers retiring. Such foresight.
Here's a thought.. What about building a modern language preprocesser that spit out COBOL? Something like RATFOR did for Fortran?
I bought an HP-41C about 40 years ago. The software (and hardware) was brilliant. Still use it and it still works. It was so well designed that even the infamous Y2K problem didn't impact it. Brilliant!
Hopefully the bar is a tad higher for developers creating heart monitors and aviation electronics is higher than the usual software (and hardware) today..
I used to use that all the time. Now I'll have to think of something else..
I can remember reading in an encyclopedia back in the early 60's, about engineers at GE needing to build in a failure mechanism because they lasted too long. Unfortunately have forgotten which encyclopedia and they've long since gone.. Stuck out in my memory however..
Sorry to see you leaving, but happy that you're on a new road to fresh opportunities. I've been a reader (and occasional contributer) since the early days..
BTW, I think your personal website is being slashdotted.. ;-)
Cheers!
Speed isn't the problem, unless you consider that the slower drivers are the ones causing many of the accidents.
As a rule (with few exceptions), it is the fast drivers who are paying attention to the driving. (They have to.) The drivers doing the speed limit are often also daydreaming, talking with other passengers (looking them in the eyes while doing it), talking on their cell phones etc. Unfortunately, the police don't have an "attention detector" to point at you before pulling you off the road for hazardous driving. (It's much easer to build a radar detector to collect revenue and pretend that it's for public safety.)
So the poor drivers continue to clog the passing lanes, oblivious to the traffic piling up behind them in dangerously close distances just waiting for multi-car pilups. (If they observe other traffic at all, I'm sure they remark to their passengers about the cars "weaving in and out" that are trying to get around them.)
If the authorities were *actually* concerned about making roads safer, they'd be better off having periodic mandatory testing of drivers and roadworthiness of cars. It might actually get much of the riff-raff off the roads and make them a safer place. Perhaps classifying drivers, safe for highway speeds, only safe for slower speeds (and some unsafe at any speed..)
I'm wondering if anyone else has been having similar problems with Verisign this week. I made a simple change to add a new nameserver to the existing five nameservers for six domains I administer. Everything looked fine; their web interface confirmed the changes.
The next morning, all h*ll broke loose, as the root nameservers were now returning the infamous 64.94.110.11 on these valid domains!! Checking the whois database revealed that the nameserver addition had not taken place, but the previous five nameservers were still there and still valid. Checking with the Verisign web interface showed the same five nameservers. Nevertheless, the root nameservers were acting as though these domains did not exist!!
I have 46 domains registered with Verisign and have been using Network Solutions for ten years. This qualifies me as a "VIP" client I guess. So I've been calling the VIP hotline for two days now and have five trouble tickets, to no avail. They can see the problem, they admit that it's a Verisign problem, but all they can say is that it may take five to seven days to fix!!
I've spoken with people who say they are in Pennsylvania and they can't talk directly to the engineers because "they're in Virginia". And I've spoken with people in Virginia who say they can't talk with the engineers because they're in Pennsylvania!
Meanwhile, whois is returning valid information while the root domain servers are just serving up the wildcard. I'm stuck and being held hostage by Verisign...
Anyone else in the same boat??
What about using a biometric finger scanning device on the control column (or stick on an Airbus) where the finger being scanned must belong to the pilot or co-pilot, and it must be alive and warm (to prevent them from cutting a finger off and taping it to the sensor)? These type of devices are used by many ISPs now.
If a finger belonging to someone else takes control, or perhaps if neither pilot or co-pilot touches the sensor within a given period of time, flags go up somewhere at flight services.
Of course, we also need to rewrite the chapters in the procedures manuals for flight services on what to do when they get these red flags popping up...
And of course the circuitry (necessary radios etc) will need to have a separate set of circuit breakers somehow, or perhaps the absense of the periodic finger cabin check puts the flags up at the FSS.
I was once involved with rolling out an application for worldwide deployment by a multinational company. Through that experience I learned that HTML with perhaps a Java front-end for doing field validation and such makes the most sense.
This is not a bandwidth issue, but an issue with the "speed of light" and the long latency times to get packets around the world. (The situation I was involved with required servers in north america, while some of the offices were as far away as Hong Kong.)
As much as I love Xwindows, this was totally unsuitable because much of the underlying chit-chat for the X protocol is "synchronous", meaning that the client will send requests to the X display server and wait (and wait) for it to respond before sending the next request. There can be hundreds of transactions like this just to bring up a simple window, meaning that it can take several minutes. Bandwidth was not the issue.
Since the application was written using X, we also tried dxpc, lbx and other compression techniques. It improved, but not by much.
The thing is, with that kind of latency, even telnet sessions are not very nice!
We also tried various techniques of client/server, distributed database, VNC's, caching etc.
What really works is some kind of an HTML front-end, which let's face it, is very much like the block mode 3270 terminals of yore with a bit of window dressing. This gives the users the perception of a responsive application most of the time, unlike the other solutions we tried.
I'm not fond of Java as a general purpose language, and I certainly don't think there is any benefit to using it on the server side where performance is usually more of an issue, but on the client side to facilitate the front end of an application it does make sense.