Sometimes I need to carry a few files (e.g. draft documents) from place to place, where Internet connectivity isn't available for the transfer. A floppy fits in my shirt pocket; a CDR doesn't and of course isn't reusable either. I agree that a 1.44Mb medium is pretty close to useless but until we have a better replacement my floppy drives will stay.
...you should. Even though there's a lot to be improved in a standard Palm or comparable PDA, and in another decade we'll laugh at them, they still kick butt. I got a Palm VII a few years ago, my first PDA, and after just a day was wondering how I'd ever survived before. The handwriting recognition works fine (not perfect, but good enough), and the easy synching with my desktop address book, calendar, and to do lists made life 100% better. If you're already experienced with these and are truly looking for the Next Big Thing, then OK fine. But if you just want to get organized, current generation PDA's kick the shit out of pencil and paper. JMHO
I don't believe that a file structure, protocol, or grammar should be copyrightable or patentable. Such things are (in my opinion) ideas or concepts, rather than implementations. A particular header file, piece of documentation, or interpreter describing or processing such a structure is and should be covered by copyright; but I feel that the underlying data structures should not be, any more than a mathematical formula or physical law.
Should companies be forced to publish their internal data structures and protocols? In general, no -- we already have too many laws to control the behavior of people and organizations. But for external/shared data, I feel there is a good fair-use argument for requiring documentation: If you export or import the data, you [should] have an obligation to describe the relevant public syntax and external semantics. The omission of such documentation would be considered a product failure, and would leave the vendor open to warranty issues, by failing to deliver a product that performs as advertised. "No documentation? Give me my money back."
Bottom line: I think it should be impossible for a vendor to obtain IP protection over a data structure or similar metadata; I think that a vendor should be expected (but not compelled except by market forces) to document external interfaces; and I think that a vendor should only be able to cling to a proprietary format as a trade secret, i.e. it should not be possible to prevent reverse engineering.
This was a pants-wetter back in 1972. Though I remember some different tearsheets -- they had marketing material as well, I think. One showed a "modified TO-5 case" that was in fact a photo of a water tower. The WOM campaign became a bit of cult humor for a generation of engineers and hobbyists.
Yup. I enjoyed AOTC -- and it was better than I was expecting. Face it, the thing that's grabbed us in every Star Wars release has been the progression in cool effects. We loved the star destroyer looming past at the start of Episode 4, and the creature cantina; and we loved similar progress in Episode 2 -- improved Jedi tricks like jumping through the window, Yoda's swordplay, the great waterfalls, nice spaceships.
I never expected brilliant storytelling or dialogue. We've never seen that from Lucas. He's no Raymond Chandler or John LeCarre. He gives us pure, cheesy space opera, executed well. That's fine with me, and all I expect or hope from Episode 3.
And aren't you glad to know the reason that Luke is such a whiny, pissy little brat -- because his dad was just the same?:)
If you read the rest of the review, it's pretty clear he's been through the book in as much depth as could be expected in the time available, given the amount and complexity of the material. I'd say the reviewer put at least as much work and thought into analyzing the work as the usual/. review. JMHO.
I agree that source control is orthogonal to commenting and should be used appropriately. But rigorous source control is not available or appropriate in every context (e.g. fragmented source environments like Smalltalk, or many single-developer projects where source control becomes a barrier to productivity). And besides, I *like* seeing a comment like
// inserted 2/24/01 to resolve race condition problem // I think I got it, but call Bob at x235 if you wind up looking at this code:O . .. // end of race condition fix
As far as herding cats is concerned, I find that developers who are aghast at the idea of imposed standards may be quite willing to work collaboratively on developing those standards: "Let's come up with a set of naming conventions to help new hires get on board. And in the process, we can decide how we'd really like to do things 'right' in the future. You draft a set for local variable names; I'll draft a set for database objects; then afterwards we'll work together on shared data and class hierarchies." It's true that everybody will have strong and conflicting opinions about what standards are reasonable; but talking these issues out can often lead to a better understanding all around, since most such opinions are based on valid concerns that should be balanced in any group standard.
My commenting discipline matured when doing operating system programming in S/370 assembler language, an environment just bulging with entropic forces trying to make code incomprehensible. My coding style became semi-famous because I was essentially always programming with the comments, inserting the actual source code to implement those comments like a human compiler. It worked well, and since I did it so much and so fast, the commenting strategy became second nature. So even though it wasn't as necessary in C or (shudder) VB or whatever, it's always been natural to code outside-in, from concepts and data structures into the details.
A technique I often used was this: 1. Invent a pseudocode language that is close to the problem domain for describing the solution. 2. Write comments using that pseudocode to show the algorithm. 3. Either a) Insert source code that performs the logic, or b) Write a compiler/interpreter/dataflow graph/whatever to implement the pseudocode language, and transform the comments into source code or an instruction stream for that engine. (You might think of Regular Expression processing as an example of this approach.)
The compelling reason to invest so much value in comments and other precoding scaffolding is that it encourages rearchitecting the system ('refactoring' in today's parlance) a few times during implementation -- it's relatively easy to change things and recognize the canonical elements when you're still at a conceptual level. It gets harder and harder as the details get fleshed out.
This is a good framework. Your code is probably very pleasant to read. I might argue with your position about marking changes, however. There are times that it's highly useful to see why and when a particular block of code was inserted. Basically, if it's relevant to understanding or troubleshooting that chunk of logic, then by all means leave fingerprints.
One other suggestion you didn't make was: Write the comments first. In The Old Days this was much more important, when working e.g. in assembly language, C6, or FORTRAN. But it's still very helpful. As you start writing the code, implementing your abstract design, you pass through all the major decision-points that shape the detailed implementation. It's relatively easy to capture those decisions as you rough out the module, explaining macro control and data flow, algorithm design, etc. Later comments tend to focus on the gory details rather than the big picture.
Another suggestion is: Revise old comments. It's easy to let old comments go out of date, particularly module-level and block comments. Part of the revision discipline should be reading through the existing documentation and making sure it's (still) accurate. If not, fix it.
Two more: Design and use a set of standards for naming, module headers, error handling, diagnostic messages, etc. These things don't evolve; they have to be implemented by choice and agreement. And Use whitespace intelligently to ensure that important things are easy to see.
You don't have to go to college to get a (decent) job. But that's not why to go. It's a great big world-wide club, and this is your chance to join. This decision, for or against, will follow you your whole life.
I'm 47 years old, with no college degree. I left a good university in my second year, for various personal reasons (but was still in good standing and had good grades). Since then I've done a lot of stuff -- developed operating systems, designed languages, wrote compilers, launched businesses, run my own company for over 20 years, yatta yatta yatta. Also done lots of non-tech stuff: raised orchids, worked as a musician, traveled, launched a restaurant. And I'm pretty widely read, etc. But at the end of the day, I regret having to take the path I took. For 10-15 years, I kept expecting to go back to school after I dealt with immediate priorities. But eventually, that chance dried up.
I've known quite a few old farts who went back to school in their forties; but they've all been pretty lame in my experience, and I don't really want to be one of them. And besides, I still have other stuff to do. I didn't miss out on the intellectual/educational side of life (I found that outside of college) but on the social/cultural/personal-network side.
College can be a grind and a waste; but if you use the time right, college can give you a breadth of vision and experience that you just won't get if you're knuckled down on the job for ten years. So please think about this carefully. You should be in no hurry to work as a sysadm -- those jobs will always be there.
They claim to have actually built a Maxwell's Demon. Like all such claims, it is founded on germs of plausibility, and the prospect of beating the thermodynamic game is so interesting that folks line up to play with it. It's hard to imagine that all the objections posted here can be wrong; though perhaps it will turn out that, after you cut through their marketing hyperbole, there's a valid useful nugget of technology that has some practical applications. One hopes that this is what the Boeing geeks have found, and that they didn't get swindled. (It's sad when smart guys get fooled by a scam.) But time will tell, of course.
The judge can immediately order the bringer of the suit to pay all legal costs for the defendand without a new trial. It is done all the time.
The judge can, but this does not always happen. And plenty of suits that seem frivolous from the standpoint of common sense are not frivolous legally. And I'd bet that NO patent infringement suit along the lines described would be deemed frivolous -- the patent may be stupid, but once you have it you're within your rights to try to protect it. The bottom line here is that following the litigation route is a very dicey thing, and the odds are you'll have to pay your court costs. It's rarely worth pursuing something in court unless you stand to collect $150-200K, or unless it's a matter of principle. That's why everybody settles.
In a small company, and even in larger ones, it's relatively easy to "pierce the corporate veil" as it's called. Classic ways for a litigant to reach past the corporation to a stockholder or officer include such trivial things as whether your corporate minute book is totally accurate and up to date, details of your sales pitch, and of course the ever popular whims of a judge or jury, which can lead to amazing results.
There are certainly advantages to incorporating, or using a Limited Liability Company or similar framework, but it's not black and white, and every company's stockholders/officers/directors/members/etc. face various personal risks that can be substantial. This poor schmuck's story is not unusual. Many people believe they are protect by a corporate shell, but generally speaking the protection doesn't go as far as you'd think or hope. IANAL but I have scars all over my damn back. Check with an attorney about this stuff.
First - do US courts award costs against companies? Here in New Zealand judges will regularly force whoever brings stupid/frivolous law suits to pay the costs of whoever was forced to defend themselves against such practices.
Sadly, no, except in very specific situations. This is a big problem in the US.
Second - isn't there some kind of lawyer's association/bar or something that could be of help here? Surely the lawyer that drafted these letters realises they're basically commiting fraud - demanding money with menaces or something similar?
The American Bar Association is basically a lawyer's club, and so although they do censure some malefactors, it has to be a black-and-white situation. These particular bozos are very likely not doing anything illegal, believe it or not, just obnoxious and IMO immoral. But legal obnoxious behavior surrounds us. Most US businesses of any age have been unwillingly involved in legal BS of some kind, not always as flagrant as this but always painful and exasperating. This is a terribly litigious society.
...it could never happen in the US. Never. There's too much history. Ask some (non-scum) lawyers about this and they'll explain the reasons this would be so hard to change. I agree it is one of the worst things about life in the US.
Until we pass a law requiring their use. Another good opportunity for the state to protect us from ourselves by legislating behavior. (Bitter? I'm not bitter.)
race car drivers? I'm certain NASCAR drivers do not double clutch. Are you talking historically?
Yeah. Though some folks still drive crash boxes, and plenty of guys power-shift when they must (or to show off). And synchros can crap out, so you need to be able to compensate. Anyway, NASCAR isn't the only game in town.
Sorry, misspoke; I meant daytime running lights, which I do realize are different from headlights. And I know about the studies, and I've experienced the advantage of daytime running lights on (for example) a remote mountain road, though in that situation headlights feel safer.
But I think the studies ignore the consequences of what happens when EVERYBODY has daytime running lights in dense traffic. There are so many moving lights that it can become hard to take everything in -- sensory overload. I'd rather leave it to the driver's discretion, though this is one of those cases where lots of folks are morons, and do the wrong thing. Still, I'd generally rather err on the side of personal responsibility than legislated behavior. JMHO.
Uh, you have experienced little issues like fog, rain, snow storm, dust storm, cloudy day... etc.
Naturally, I'm pleased to turn the lights on when conditions warrant. This is true almost all day at high altitudes and latitudes -- and throughout Canada, for example, where daytime running lights are the law for a good reason. (I find this somewhat mysterious.) But in a Chicago suburb on a sunny day? Not good in my opinion.
I always double (de-)clutch on every car when downshifting, and have for 30 years. It's part of why I like driving with a manual transmission. Truck drivers and race car drivers do this because they must; I do it because I like it.:)
VW Beetle did this also. It was a nice feature. I was surprised and pleased when I found my 1972 Beetle turned the lights off for me. Parking lights stayed on, though.
I believe the logic is that if the car stalls or breaks down, you don't want the lights turning off automatically. Anything more elaborate than simply staying on would have required an overly complex ignition switch, given the technology of the day. Of course, today, there's no excuse.
Worse, they brainacs who design our cars have decided the headlights should stay on during daylight hours. I find this annoying, confusing, and dangerous.
...when they pry it from my cold, dead fingers. Wait...come to think of it, that's probably just how it would happen. But I guess I wouldn't need it then.
I hate cars that try to be smarter than the driver. Give me my old Morgan any time. I do miss it so. <sigh>
Car controls have changed dramatically through the years. The high-beams used to be via a footswitch. Windshield wipers only moved onto a stalk on the console very recently. Transmission controls have varied widely: stalks, buttons, levers, etc. True, the main controls (wheel, throttle, brake) haven't moved too much, but one might argue there aren't many variations possible if you a) want to steer with two hands and b) want to speed up/slow down with your feet. There were tillers on some early cars, but the public tended to prefer the wheel. Also, remember that engine controls in the old days were incredibly complex, letting you adjust engine timing, butterfly valve settings, and myriad other features.
I think we've seen plenty of change. Just try to drive a car from the twenties or thirties some time.
In the '70's, I worked for a timesharing company called National CSS. NCSS was a very cool place, not at all a traditional computer services company. There were scads of really sharp propellor-heads, all of whom today would be (and some of whom are) deep Linux hackers. We had our own operating system running on IBM mainframe hardware, a highly-evolved descendent of CP/CMS called VP/CSS. We had a kick-ass packet switching network spanning the globe, with PDP 11's as network nodes, and we rented interactive computer time to just about every major company for on-line data mining, prototyping, what-if analysis, etc. NCSS was a constant thorn in IBM's side; for you youngsters, IBM was the Microsoft of the era:). At the time, a big TSO customer might squeeze 30-50 online users on a 370/158, whereas we could run 150+ users on the same machine.
Anwyay, we bought a big Amdahl, I believe a 470/V7, and it showed up one day on a truck, outside our data center. The pallets needed to be shifted from the truck up onto the data center floor. As the forklift picked up the first load, the bright director of engineering wondered aloud "What happens if they drop it?" The observers started wondering about who covered the insurance for moving the system from the truck into our premises. After a few anxious looks, the delivery was stopped, and some phone calls made. Turns out the shipper covered it to the curb, and our in-house insurance covered it once it was on the floor, but NOBODY was covering the transition.
After some hurried calls, something like $50K was pledged to Lloyd's for a 24-hour $3M policy covering this very short-haul move. (The dollars might be wrong, and it might not have been Lloyd's. But you get the idea.)
At the end of the process, the system came up and all was well, and Amdahl had a great new reference site running a non-IBM operating system. But it was a good lesson in anticipating troubles.
"Use the best technology for the job" "Beta is technically superior to VHS." "I've been telling my customers (mainly small businesses) that mirrored IDE drives are the best value for general purpose data storage."
So, uh, does this mean you still use Beta? Kewl. Great to see somebody who stands by his principles in the face of overpowering market forces.
It's actually not generally the best advice for a client, though. You rarely lose *in the long term* betting on the market leader. Sad but true.
Slashdot Mirror
Sometimes I need to carry a few files (e.g. draft documents) from place to place, where Internet connectivity isn't available for the transfer. A floppy fits in my shirt pocket; a CDR doesn't and of course isn't reusable either. I agree that a 1.44Mb medium is pretty close to useless but until we have a better replacement my floppy drives will stay.
...you should. Even though there's a lot to be improved in a standard Palm or comparable PDA, and in another decade we'll laugh at them, they still kick butt. I got a Palm VII a few years ago, my first PDA, and after just a day was wondering how I'd ever survived before. The handwriting recognition works fine (not perfect, but good enough), and the easy synching with my desktop address book, calendar, and to do lists made life 100% better. If you're already experienced with these and are truly looking for the Next Big Thing, then OK fine. But if you just want to get organized, current generation PDA's kick the shit out of pencil and paper. JMHO
I don't believe that a file structure, protocol, or grammar should be copyrightable or patentable. Such things are (in my opinion) ideas or concepts, rather than implementations. A particular header file, piece of documentation, or interpreter describing or processing such a structure is and should be covered by copyright; but I feel that the underlying data structures should not be, any more than a mathematical formula or physical law.
Should companies be forced to publish their internal data structures and protocols? In general, no -- we already have too many laws to control the behavior of people and organizations. But for external/shared data, I feel there is a good fair-use argument for requiring documentation: If you export or import the data, you [should] have an obligation to describe the relevant public syntax and external semantics. The omission of such documentation would be considered a product failure, and would leave the vendor open to warranty issues, by failing to deliver a product that performs as advertised. "No documentation? Give me my money back."
Bottom line: I think it should be impossible for a vendor to obtain IP protection over a data structure or similar metadata; I think that a vendor should be expected (but not compelled except by market forces) to document external interfaces; and I think that a vendor should only be able to cling to a proprietary format as a trade secret, i.e. it should not be possible to prevent reverse engineering.
This was a pants-wetter back in 1972. Though I remember some different tearsheets -- they had marketing material as well, I think. One showed a "modified TO-5 case" that was in fact a photo of a water tower. The WOM campaign became a bit of cult humor for a generation of engineers and hobbyists.
Yup. I enjoyed AOTC -- and it was better than I was expecting. Face it, the thing that's grabbed us in every Star Wars release has been the progression in cool effects. We loved the star destroyer looming past at the start of Episode 4, and the creature cantina; and we loved similar progress in Episode 2 -- improved Jedi tricks like jumping through the window, Yoda's swordplay, the great waterfalls, nice spaceships.
:)
I never expected brilliant storytelling or dialogue. We've never seen that from Lucas. He's no Raymond Chandler or John LeCarre. He gives us pure, cheesy space opera, executed well. That's fine with me, and all I expect or hope from Episode 3.
And aren't you glad to know the reason that Luke is such a whiny, pissy little brat -- because his dad was just the same?
If you read the rest of the review, it's pretty clear he's been through the book in as much depth as could be expected in the time available, given the amount and complexity of the material. I'd say the reviewer put at least as much work and thought into analyzing the work as the usual /. review. JMHO.
I agree that source control is orthogonal to commenting and should be used appropriately. But rigorous source control is not available or appropriate in every context (e.g. fragmented source environments like Smalltalk, or many single-developer projects where source control becomes a barrier to productivity). And besides, I *like* seeing a comment like
:O .
// inserted 2/24/01 to resolve race condition problem
// I think I got it, but call Bob at x235 if you wind up looking at this code
. .
// end of race condition fix
As far as herding cats is concerned, I find that developers who are aghast at the idea of imposed standards may be quite willing to work collaboratively on developing those standards: "Let's come up with a set of naming conventions to help new hires get on board. And in the process, we can decide how we'd really like to do things 'right' in the future. You draft a set for local variable names; I'll draft a set for database objects; then afterwards we'll work together on shared data and class hierarchies." It's true that everybody will have strong and conflicting opinions about what standards are reasonable; but talking these issues out can often lead to a better understanding all around, since most such opinions are based on valid concerns that should be balanced in any group standard.
My commenting discipline matured when doing operating system programming in S/370 assembler language, an environment just bulging with entropic forces trying to make code incomprehensible. My coding style became semi-famous because I was essentially always programming with the comments, inserting the actual source code to implement those comments like a human compiler. It worked well, and since I did it so much and so fast, the commenting strategy became second nature. So even though it wasn't as necessary in C or (shudder) VB or whatever, it's always been natural to code outside-in, from concepts and data structures into the details.
A technique I often used was this: 1. Invent a pseudocode language that is close to the problem domain for describing the solution. 2. Write comments using that pseudocode to show the algorithm. 3. Either a) Insert source code that performs the logic, or b) Write a compiler/interpreter/dataflow graph/whatever to implement the pseudocode language, and transform the comments into source code or an instruction stream for that engine. (You might think of Regular Expression processing as an example of this approach.)
The compelling reason to invest so much value in comments and other precoding scaffolding is that it encourages rearchitecting the system ('refactoring' in today's parlance) a few times during implementation -- it's relatively easy to change things and recognize the canonical elements when you're still at a conceptual level. It gets harder and harder as the details get fleshed out.
JMHO - Trevor
This is a good framework. Your code is probably very pleasant to read. I might argue with your position about marking changes, however. There are times that it's highly useful to see why and when a particular block of code was inserted. Basically, if it's relevant to understanding or troubleshooting that chunk of logic, then by all means leave fingerprints.
One other suggestion you didn't make was: Write the comments first. In The Old Days this was much more important, when working e.g. in assembly language, C6, or FORTRAN. But it's still very helpful. As you start writing the code, implementing your abstract design, you pass through all the major decision-points that shape the detailed implementation. It's relatively easy to capture those decisions as you rough out the module, explaining macro control and data flow, algorithm design, etc. Later comments tend to focus on the gory details rather than the big picture.
Another suggestion is: Revise old comments. It's easy to let old comments go out of date, particularly module-level and block comments. Part of the revision discipline should be reading through the existing documentation and making sure it's (still) accurate. If not, fix it.
Two more: Design and use a set of standards for naming, module headers, error handling, diagnostic messages, etc. These things don't evolve; they have to be implemented by choice and agreement. And Use whitespace intelligently to ensure that important things are easy to see.
If I can learn to read these, I'll be cunilingual, right?
You don't have to go to college to get a (decent) job. But that's not why to go. It's a great big world-wide club, and this is your chance to join. This decision, for or against, will follow you your whole life.
I'm 47 years old, with no college degree. I left a good university in my second year, for various personal reasons (but was still in good standing and had good grades). Since then I've done a lot of stuff -- developed operating systems, designed languages, wrote compilers, launched businesses, run my own company for over 20 years, yatta yatta yatta. Also done lots of non-tech stuff: raised orchids, worked as a musician, traveled, launched a restaurant. And I'm pretty widely read, etc. But at the end of the day, I regret having to take the path I took. For 10-15 years, I kept expecting to go back to school after I dealt with immediate priorities. But eventually, that chance dried up.
I've known quite a few old farts who went back to school in their forties; but they've all been pretty lame in my experience, and I don't really want to be one of them. And besides, I still have other stuff to do. I didn't miss out on the intellectual/educational side of life (I found that outside of college) but on the social/cultural/personal-network side.
College can be a grind and a waste; but if you use the time right, college can give you a breadth of vision and experience that you just won't get if you're knuckled down on the job for ten years. So please think about this carefully. You should be in no hurry to work as a sysadm -- those jobs will always be there.
They claim to have actually built a Maxwell's Demon. Like all such claims, it is founded on germs of plausibility, and the prospect of beating the thermodynamic game is so interesting that folks line up to play with it. It's hard to imagine that all the objections posted here can be wrong; though perhaps it will turn out that, after you cut through their marketing hyperbole, there's a valid useful nugget of technology that has some practical applications. One hopes that this is what the Boeing geeks have found, and that they didn't get swindled. (It's sad when smart guys get fooled by a scam.) But time will tell, of course.
The judge can immediately order the bringer of the suit to pay all legal costs for the defendand without a new trial. It is done all the time.
The judge can, but this does not always happen. And plenty of suits that seem frivolous from the standpoint of common sense are not frivolous legally. And I'd bet that NO patent infringement suit along the lines described would be deemed frivolous -- the patent may be stupid, but once you have it you're within your rights to try to protect it. The bottom line here is that following the litigation route is a very dicey thing, and the odds are you'll have to pay your court costs. It's rarely worth pursuing something in court unless you stand to collect $150-200K, or unless it's a matter of principle. That's why everybody settles.
In a small company, and even in larger ones, it's relatively easy to "pierce the corporate veil" as it's called. Classic ways for a litigant to reach past the corporation to a stockholder or officer include such trivial things as whether your corporate minute book is totally accurate and up to date, details of your sales pitch, and of course the ever popular whims of a judge or jury, which can lead to amazing results.
There are certainly advantages to incorporating, or using a Limited Liability Company or similar framework, but it's not black and white, and every company's stockholders/officers/directors/members/etc. face various personal risks that can be substantial. This poor schmuck's story is not unusual. Many people believe they are protect by a corporate shell, but generally speaking the protection doesn't go as far as you'd think or hope. IANAL but I have scars all over my damn back. Check with an attorney about this stuff.
First - do US courts award costs against companies? Here in New Zealand judges will regularly force whoever brings stupid/frivolous law suits to pay the costs of whoever was forced to defend themselves against such practices.
Sadly, no, except in very specific situations. This is a big problem in the US.
Second - isn't there some kind of lawyer's association/bar or something that could be of help here? Surely the lawyer that drafted these letters realises they're basically commiting fraud - demanding money with menaces or something similar?
The American Bar Association is basically a lawyer's club, and so although they do censure some malefactors, it has to be a black-and-white situation. These particular bozos are very likely not doing anything illegal, believe it or not, just obnoxious and IMO immoral. But legal obnoxious behavior surrounds us. Most US businesses of any age have been unwillingly involved in legal BS of some kind, not always as flagrant as this but always painful and exasperating. This is a terribly litigious society.
...it could never happen in the US. Never. There's too much history. Ask some (non-scum) lawyers about this and they'll explain the reasons this would be so hard to change. I agree it is one of the worst things about life in the US.
Until we pass a law requiring their use. Another good opportunity for the state to protect us from ourselves by legislating behavior. (Bitter? I'm not bitter.)
race car drivers? I'm certain NASCAR drivers do not double clutch. Are you talking historically?
Yeah. Though some folks still drive crash boxes, and plenty of guys power-shift when they must (or to show off). And synchros can crap out, so you need to be able to compensate. Anyway, NASCAR isn't the only game in town.
Sorry, misspoke; I meant daytime running lights, which I do realize are different from headlights. And I know about the studies, and I've experienced the advantage of daytime running lights on (for example) a remote mountain road, though in that situation headlights feel safer.
But I think the studies ignore the consequences of what happens when EVERYBODY has daytime running lights in dense traffic. There are so many moving lights that it can become hard to take everything in -- sensory overload. I'd rather leave it to the driver's discretion, though this is one of those cases where lots of folks are morons, and do the wrong thing. Still, I'd generally rather err on the side of personal responsibility than legislated behavior. JMHO.
Uh, you have experienced little issues like fog, rain, snow storm, dust storm, cloudy day... etc.
Naturally, I'm pleased to turn the lights on when conditions warrant. This is true almost all day at high altitudes and latitudes -- and throughout Canada, for example, where daytime running lights are the law for a good reason. (I find this somewhat mysterious.) But in a Chicago suburb on a sunny day? Not good in my opinion.
I always double (de-)clutch on every car when downshifting, and have for 30 years. It's part of why I like driving with a manual transmission. Truck drivers and race car drivers do this because they must; I do it because I like it. :)
VW Beetle did this also. It was a nice feature. I was surprised and pleased when I found my 1972 Beetle turned the lights off for me. Parking lights stayed on, though.
I believe the logic is that if the car stalls or breaks down, you don't want the lights turning off automatically. Anything more elaborate than simply staying on would have required an overly complex ignition switch, given the technology of the day. Of course, today, there's no excuse.
Worse, they brainacs who design our cars have decided the headlights should stay on during daylight hours. I find this annoying, confusing, and dangerous.
...when they pry it from my cold, dead fingers. Wait...come to think of it, that's probably just how it would happen. But I guess I wouldn't need it then.
I hate cars that try to be smarter than the driver. Give me my old Morgan any time. I do miss it so. <sigh>
Car controls have changed dramatically through the years. The high-beams used to be via a footswitch. Windshield wipers only moved onto a stalk on the console very recently. Transmission controls have varied widely: stalks, buttons, levers, etc. True, the main controls (wheel, throttle, brake) haven't moved too much, but one might argue there aren't many variations possible if you a) want to steer with two hands and b) want to speed up/slow down with your feet. There were tillers on some early cars, but the public tended to prefer the wheel. Also, remember that engine controls in the old days were incredibly complex, letting you adjust engine timing, butterfly valve settings, and myriad other features.
I think we've seen plenty of change. Just try to drive a car from the twenties or thirties some time.
In the '70's, I worked for a timesharing company called National CSS. NCSS was a very cool place, not at all a traditional computer services company. There were scads of really sharp propellor-heads, all of whom today would be (and some of whom are) deep Linux hackers. We had our own operating system running on IBM mainframe hardware, a highly-evolved descendent of CP/CMS called VP/CSS. We had a kick-ass packet switching network spanning the globe, with PDP 11's as network nodes, and we rented interactive computer time to just about every major company for on-line data mining, prototyping, what-if analysis, etc. NCSS was a constant thorn in IBM's side; for you youngsters, IBM was the Microsoft of the era :). At the time, a big TSO customer might squeeze 30-50 online users on a 370/158, whereas we could run 150+ users on the same machine.
Anwyay, we bought a big Amdahl, I believe a 470/V7, and it showed up one day on a truck, outside our data center. The pallets needed to be shifted from the truck up onto the data center floor. As the forklift picked up the first load, the bright director of engineering wondered aloud "What happens if they drop it?" The observers started wondering about who covered the insurance for moving the system from the truck into our premises. After a few anxious looks, the delivery was stopped, and some phone calls made. Turns out the shipper covered it to the curb, and our in-house insurance covered it once it was on the floor, but NOBODY was covering the transition.
After some hurried calls, something like $50K was pledged to Lloyd's for a 24-hour $3M policy covering this very short-haul move. (The dollars might be wrong, and it might not have been Lloyd's. But you get the idea.)
At the end of the process, the system came up and all was well, and Amdahl had a great new reference site running a non-IBM operating system. But it was a good lesson in anticipating troubles.
"Use the best technology for the job"
"Beta is technically superior to VHS."
"I've been telling my customers (mainly small businesses) that mirrored IDE drives are the best value for general purpose data storage."
So, uh, does this mean you still use Beta? Kewl. Great to see somebody who stands by his principles in the face of overpowering market forces.
It's actually not generally the best advice for a client, though. You rarely lose *in the long term* betting on the market leader. Sad but true.