You're confusing vendor lock-in and technology lock-in. They are not the same, one (the latter) is fairly benign, the other can get you into trouble.
The difference is that technology lock-in (choosing, say, a 'nix-like OS; or using CD-RW as an offline medium vs ZIP disks) still lets you choose that technology from different vendors. Individual companies may go out of business, or jack up their prices, but you still have a choice.
OTOH, with vendor lock-in (going Windows, or using ZIP drives, etc) means that if that vendor changes the terms of doing business, you have little choice but to bend over and take it.
My car purchase may mean I'm "locked in" to buying gasoline (vs diesel, or straight ethanol) as a fuel, but I have my choice of vendors as to who to buy that from. A vendor lock-in would mean I had to buy, say, GM brand MotoFuel because the engine wouldn't burn anything else. Sure, maybe it gives 10% better mileage than generic gas in a generic engine, but I'm still screwed if GM doubles the price, or decides to stop making MotoFuel.
Nope, GP is correct. Windows (XP,2K,NT) kernel is very much based on VMS, which was notoriously painful to fork processes on, so applications ended up being big monolithic things with numerous threads -- with the consequent risks of an error in one thread clobbering everything else.
Unix has always been about solving problems with multiple lighter weight, communicating tasks that can be forked very efficiently, and traditional 'nix apps were written to take advantage of that. And a renegade task generally won't clobber the other tasks, and (potentially) can be killed and restarted without affecting the overall app, giving both better reliability and better security.
The modern trend to bloated apps is the curse of a generation of programmers raised on Windows. Threads can and are implemented efficiently on 'nix as a degenerate case of forking, for those that insist on it or whose language maldesign pretty much forces it (eg, if your language requires a virtual machine).
does not mean Apple had to stop innovating. Have you seen MagSafe?
Hope they got a license on the patents owned by Presto (the appliance makers). Their magnetic quick-release cord patents were issued in 2003/2004, filed in 2001.
This is obviously some Microsoft-influenced meaning of the word "innovation".
You make some excellent points - +1 insightful if I had the mod points. However, regarding "The CGI work might help a less credible episode." -- I can't imagine any CGI work at all that would save "Spock's Brain".
It's also hard to imagine anything that could be done to STTMP to make it "the best", it being basically a rewrite of the Nomad episode. But tastes differ -- my wife actually likes the hour-and-a-half slow pans and dollies around the new Enterprise in spacedock. (Okay, only a few minutes, it just seems like an hour and a half;-)
That leaves the possibility that there will be an interest in putting in more effects than they have time for and they already cut stuff from the original to get it into an hour runtime as is.
No, not an hour runtime -- unless you're counting commercials. The thing is, back in the 60s they didn't show nearly as many minutes of commercials per hour as they do now. It has become very obvious as various TV shows are released on DVD -- more recent ones run to about 42 minutes per show, from 10-15 years ago it's more like 45-46 minutes per show, and the original Trek may well have been closer to 50 minutes. (Haven't watched a TOS episode recently enough to say for sure.)
That means they'll need to cut nearly 8 minutes of content anyway just to fit in the modern format. Perhaps that's one reason they're completely re-doing the title sequence -- to make it shorter.
On the plus side, if they cut all the... pauses... from Shatner's... dialog... they may not need to cut anything else.
Nope, you're wrong -- or you're thinking about conventional aircraft.
A Saturn V launch leaves a very nice path to ground through the ionized gas (flame) and carbon smoke (rich-burning kerosene fuel) trail it's pouring out the back end. That's why the thing got hit in the first place. To quote from a web page on the strike: "As the rocket accelerated through the low-altitude rain clouds, it behaved much like a lightning rod. A bolt of electricity struck the vehicle and traveled to the ground along the column of ionized, electrically conductive gases in the rocket engine exhaust plume of the Saturn V."
(Actually it was hit twice; the first at an altitude of 6500 ft at 36 seconds into the launch, and again at about 14,500 ft at about 52 seconds)
More stuff these days is being shot direct to digital, as it's far easier to get it into editing suites and post production that way. Also, film and paper decay, media goes obsolete, etc.
Just because a studio or publisher retains a copy, do you really think that they're planning on hanging on to it for ninety years and then digging out that copy and saying "here, this is in the public domain now, it's all yours". I doubt it. Ninety years is a long time, and storage space costs money. Sooner or later studios, etc, just toss the stuff out - especially as studios go out of business, or are acquired through mergers or buyouts by companies that may not care about those particular assets.
if you were to crack the DRM on something that was in the public domain
Big if. That's assuming you can even find something to read the media and that the media survived the 90 years until it goes PD.
Apollo 12 was struck by lightning shortly after launch. Aside from a few tense moments while circuit breakers were reset, etc, it made orbit okay and proceeded on to do a pinpoint landing on the Moon (within walking distance of Surveyor III).
And they're worried about an 80 msec blip on one bus?
(Okay, it doesn't hurt to check it out. If they do find any showstoppers it says something about the relative robustness of the Apollo-Saturn stack vs Shuttle.)
The last place I want an 8' wall is where a door should be;-)
Seriously, the real estate trade has a definition of "square footage" -- that's finished, livable space. Unfinished basements don't count. Garages don't count. Crawl spaces don't count.
That said, they do tend to estimate based on overall dimensions or county assessment office records, it's not like they subtract out closets and stairways.
social skills are just one of many areas which obscure pure merit.
You miss the point: social skills are one of the properties on which an overall figure of merit is based. Communication (which social skills lubricate) is essential. Now, I agree that if some interviewer lets him or herself be dazzled by a candidate's social skills to the point that they overlook significant technical deficiencies, then that's no good either. And some programming jobs take more or fewer social skills than others -- if you're going to be meeting with clients to do requirements analysis or give demos, then social skills are a lot more significant than if you're one of the "boys in the back room" fine tuning the module that calculates the convex hull of some data points.
And yes, once upon a time I used to think that technical merit ought to be the only yardstick - until I'd been out in the workforce for a few years and observed some programming teams working on medium-large projects in action. School (with a couple of rare exceptions) doesn't prepare you for that.
I'm surprised more companies don't employ rigorous application tests and psychological evaluations to replace the caprice of the varied interviewers.
Most companies aren't pushing the bleeding edge so hard that they need technical skills uber alles, and don't have the managers capable of leading teams made up of that sort even if they did. By the time a candidate gets to the interview stage, the company has a pretty good idea (eg from the resume, etc) that the candidate is probably "good enough" technically and the interview is to make sure the resume wasn't padded and that the candidate will fit in with the existing employees. When a candidate has gone through a round of interviews, the hiring manager generally has two questions of the interviewers: "does he know his stuff?" and "will he fit in?".
(That said, a company doing bleeding edge work will definitely do a pretty rigorous technical appraisal often including tests. They can't afford the merely "good enough". An interview I did at a company building supercomputer clusters was like that -- I've had college finals that were easier. I passed, but alas the company re-orged and eliminated the position (and a few others) before the start date.)
Shoddy code will eventually break. The exception is if the environment it operates in never changes. This is also true with buildings, appliances, etc, except that their environment changes by itself. And I really doubt that you'll find differences of opinion over what constitutes shoddy code. Code style differences, sure, but that's not the same thing. Unreachable code, unused variables, failure to check inputs for domain-appropriateness, undocumented and inappropriate assumptions (cf "all the world's a VAX") etc -- none of this is "golden brilliant" to anybody.
I've heard of some extreme cases where they were able to swap out the control board with a fresh one to get the data out
Been there, done that, still have the burnt out drive electronics (a PSU failed badly, sending high voltage to the system, and the power surge literally exploded one of the chips on the drive card and burned off a few traces). It was an old Seagate SCSI drive. Fortunately I had a couple of others of the same model. Just swapped the circuit board on the drive and rescued the data.
(Unfortunately the other drive that fried (an IDE drive) I didn't have a replacment for, and even though the manufacturer still produced that model, they'd changed some details and the circuit boards were no longer physically compatible. Haven't tried the platter swap. Of course the power surge fried just about everything else in the computer too.)
You'd be too hesitant to write a line, for fear of having to erase it in front of the person, and appear unsure.
Yep, and I'm really not interested in hiring someone who lacks that kind of self confidence. I'd rather have somebody write a few lines of code, say "nope, this is wrong", erase it and start over, than have someone too paralyzed to do anything.
If your focus in an interview is to see who can come up with answers quickly, and pencil code easily, you'll miss those who, though they don't perform well under social pressure, might be brilliant when allowed some time alone.
Sorry, it's a business. Programming teams (and I'm not talking XP here) need to be able to bounce ideas off each other, to stand up and do design and/or code reviews, and too-often work under some deadline pressure.
You'll weed out the social phobics and autistics, who represent a disproportionate number of coders.
Most coders I've worked with -- and I was in software development for a lot of years -- don't fit that mold. Those that did tended to be bad coders -- didn't follow style guidelines (their way was better), or spent too much time trying to find their own answer to a problem instead of just asking someone else. (Some of that is OK -- I've also seen coders who drive everybody else on the team crazy by bugging them with questions instead of RTFM.)
these weird tests that you think can peer into the heart of any programmer
I'm not (much) interested in peering into the heart of a programmer, but into their mind. And it doesn't have much to do with whether they can generate correct code or not; generating correct code is so easy that even a computer program can do it. It has a lot to do with how adaptable the programmer is -- is this guy going to be any good two years from now when the technology has changed? (Granted, interviewing style is going to be different if you're just looking for someone for a 3-month project vs a permanent long term hire.)
Programming is kind of weird in that something can outwardly function, but yet be terribly coded. I don't know of many other fields where this is true.
Geez, look at the internals of almost any consumer device, or look at a house under construction, or... etc. It's true of almost anything where the manufacturer/builder can wrap a pretty skin around it that will hold up for a minimal amount of time. That's why there are things like electrical codes and building codes and inspectors. Software isn't quite there yet, except in certain critical fields like avionics. If commercial software had to have something equivalent to a UL certification, the whole field would collapse overnight.
Most people looking for "voodoo indicators" are probably techies who don't really have a clue how they themselves do what they do, so they don't know how to look for it in other people. (Having miserable people-skills in the first place may have something to do with that, too.)
On the other hand what you may think is a voodoo indicator may actually be something that is important to the project/company and extremely relevant in the interviewer's experience, or that they're using that to find out something other than what you think they are.
An example: one of my fellow senior programmers/technical interviewers at a company where the work involved a lot of computational geometry was fond of asking about finding convex hulls. Unlikely that anyone could give a good technical answer off the cuff unless they'd just completed a course on it or had worked in that field for a while -- and even then there's no single right answer. That wasn't the point; the point was to see how the candidate reacted to the question. Being ignorant was okay so long as they were honest (extra points for coming up with some intelligent suggestions for finding out the answer) -- we had a database team, a UI team, etc where that kind of mathematical knowledge wasn't as important. But trying to bullshit your way through an answer was fatal. If you started talking about boats, you might be shown the door right then;-)
A candidate might view that question about computing a convex hull as a voodoo indicator, especially if they didn't know the answer and they didn't get a job offer. But they might have blown the interview for totally unrelated reasons -- as might well have somebody who could discourse at length on the relative merits of various convex hull algorithms.
Yep, which is why I said "not that I necessarily ask people to write code on a white board". But the orginal poster had a "Never..ever" in there that indicates a certain inflexibility.
Inflexible programmers are brittle programmers -- and it's been my experience that they tend to write brittle code, or design brittle systems. Maybe it has something to do with a lack of imagination.
Never.. Ever.. ask somebody to write answers on a white board. It is not natural. If I prefer to place open/close brackets right when start a function then white boards do not fit that pattern. Little things like this make it more 'English' and less 'code'
You just failed any interview that I'd give. Not that I necessarily ask folks to write code on a white board, but if they can't handle that it shows that they're inflexible and would probably be totally lost in a design discussion or a code walkthrough. I don't care about matched brackets on a whiteboard -- compilers are real good at catching stuff like that -- but if you can't explain what you're doing in English (or whatever natural language you speak) then you don't understand it.
My thoughts exactly while I was reading that definition.
It means that, by definition, there are no extra-solar planets. So what the heck are we supposed to call all those things (203 of them, by latest count) smaller than a brown dwarf that we've found orbiting other stars?
My question, however, is just how much will the average citizen get out of reading a highly technical research report on a subject?
Irrelevant. True, most of them won't get anything out of it -- indeed won't even bother trying to find it. That's no reason not to make the information available to those who do want to read it and may well be capable of understanding it.
Unless they are well schooled in a particular field, they likely won't even understand what the abstract is talking about.
Likely? Perhaps -- but even if only 2% of the population is intelligent enough, (eg, those with an IQ high enough to qualify for Mensa), and only half of those have done enough reading in the field to undestand the abstract, (and people that smart tend to do a lot of reading in many fields), that's still well over a million people in this country who could read it and understand it, given the opportunity.
It was inevitable. DOD is planning on shutting down Cheyenne Mountain and moving the (non-Stargate) operations to Peterson AFB. How can you film SG-1 episodes without access to the gate room?
Probably some alien virus got loose in there and they have to shut everything down.
(For the humor impaired: no, I'm not serious. If I were serious I'd have to explain how they're actually moving the Stargate to a formerly abandoned Titan missile silo complex on the plains out east of Denver, and how the scenery around there is way too boring to use as the locale for a TV series.)
Slashdot Mirror
start thinking about in terms of real estate with a long-ass trip to the beach....
Hey, no, man. The beach is right there. It's just a long way to the water...
(But yeah. Environmental impact? Heck, the place already looks like it was strip-mined.)
You're confusing vendor lock-in and technology lock-in. They are not the same, one (the latter) is fairly benign, the other can get you into trouble.
The difference is that technology lock-in (choosing, say, a 'nix-like OS; or using CD-RW as an offline medium vs ZIP disks) still lets you choose that technology from different vendors. Individual companies may go out of business, or jack up their prices, but you still have a choice.
OTOH, with vendor lock-in (going Windows, or using ZIP drives, etc) means that if that vendor changes the terms of doing business, you have little choice but to bend over and take it.
My car purchase may mean I'm "locked in" to buying gasoline (vs diesel, or straight ethanol) as a fuel, but I have my choice of vendors as to who to buy that from. A vendor lock-in would mean I had to buy, say, GM brand MotoFuel because the engine wouldn't burn anything else. Sure, maybe it gives 10% better mileage than generic gas in a generic engine, but I'm still screwed if GM doubles the price, or decides to stop making MotoFuel.
Nope, GP is correct. Windows (XP,2K,NT) kernel is very much based on VMS, which was notoriously painful to fork processes on, so applications ended up being big monolithic things with numerous threads -- with the consequent risks of an error in one thread clobbering everything else.
Unix has always been about solving problems with multiple lighter weight, communicating tasks that can be forked very efficiently, and traditional 'nix apps were written to take advantage of that. And a renegade task generally won't clobber the other tasks, and (potentially) can be killed and restarted without affecting the overall app, giving both better reliability and better security.
The modern trend to bloated apps is the curse of a generation of programmers raised on Windows. Threads can and are implemented efficiently on 'nix as a degenerate case of forking, for those that insist on it or whose language maldesign pretty much forces it (eg, if your language requires a virtual machine).
does not mean Apple had to stop innovating. Have you seen MagSafe?
Hope they got a license on the patents owned by Presto (the appliance makers). Their magnetic quick-release cord patents were issued in 2003/2004, filed in 2001.
This is obviously some Microsoft-influenced meaning of the word "innovation".
What is this "enough memory" of which you speak?
Oh, wait, virtual memory. I thought you were talking about real memory.
Never mind.
You make some excellent points - +1 insightful if I had the mod points. However, regarding "The CGI work might help a less credible episode." -- I can't imagine any CGI work at all that would save "Spock's Brain".
;-)
It's also hard to imagine anything that could be done to STTMP to make it "the best", it being basically a rewrite of the Nomad episode. But tastes differ -- my wife actually likes the hour-and-a-half slow pans and dollies around the new Enterprise in spacedock. (Okay, only a few minutes, it just seems like an hour and a half
That leaves the possibility that there will be an interest in putting in more effects than they have time for and they already cut stuff from the original to get it into an hour runtime as is.
... pauses ... from Shatner's ... dialog ... they may not need to cut anything else.
No, not an hour runtime -- unless you're counting commercials. The thing is, back in the 60s they didn't show nearly as many minutes of commercials per hour as they do now. It has become very obvious as various TV shows are released on DVD -- more recent ones run to about 42 minutes per show, from 10-15 years ago it's more like 45-46 minutes per show, and the original Trek may well have been closer to 50 minutes. (Haven't watched a TOS episode recently enough to say for sure.)
That means they'll need to cut nearly 8 minutes of content anyway just to fit in the modern format. Perhaps that's one reason they're completely re-doing the title sequence -- to make it shorter.
On the plus side, if they cut all the
Dell is soooooo the market leader in technology innovation.
+1 Funny
Nope, you're wrong -- or you're thinking about conventional aircraft.
A Saturn V launch leaves a very nice path to ground through the ionized gas (flame) and carbon smoke (rich-burning kerosene fuel) trail it's pouring out the back end. That's why the thing got hit in the first place. To quote from a web page on the strike: "As the rocket accelerated through the low-altitude rain clouds, it behaved much like a lightning rod. A bolt of electricity struck the vehicle and traveled to the ground along the column of ionized, electrically conductive gases in the rocket engine exhaust plume of the Saturn V."
(Actually it was hit twice; the first at an altitude of 6500 ft at 36 seconds into the launch, and again at about 14,500 ft at about 52 seconds)
Then be incredibly surprised.
More stuff these days is being shot direct to digital, as it's far easier to get it into editing suites and post production that way. Also, film and paper decay, media goes obsolete, etc.
Just because a studio or publisher retains a copy, do you really think that they're planning on hanging on to it for ninety years and then digging out that copy and saying "here, this is in the public domain now, it's all yours". I doubt it. Ninety years is a long time, and storage space costs money. Sooner or later studios, etc, just toss the stuff out - especially as studios go out of business, or are acquired through mergers or buyouts by companies that may not care about those particular assets.
if you were to crack the DRM on something that was in the public domain
Big if. That's assuming you can even find something to read the media and that the media survived the 90 years until it goes PD.
Apollo 12 was struck by lightning shortly after launch. Aside from a few tense moments while circuit breakers were reset, etc, it made orbit okay and proceeded on to do a pinpoint landing on the Moon (within walking distance of Surveyor III).
And they're worried about an 80 msec blip on one bus?
(Okay, it doesn't hurt to check it out. If they do find any showstoppers it says something about the relative robustness of the Apollo-Saturn stack vs Shuttle.)
The last place I want an 8' wall is where a door should be ;-)
Seriously, the real estate trade has a definition of "square footage" -- that's finished, livable space. Unfinished basements don't count. Garages don't count. Crawl spaces don't count.
That said, they do tend to estimate based on overall dimensions or county assessment office records, it's not like they subtract out closets and stairways.
social skills are just one of many areas which obscure pure merit.
You miss the point: social skills are one of the properties on which an overall figure of merit is based. Communication (which social skills lubricate) is essential. Now, I agree that if some interviewer lets him or herself be dazzled by a candidate's social skills to the point that they overlook significant technical deficiencies, then that's no good either. And some programming jobs take more or fewer social skills than others -- if you're going to be meeting with clients to do requirements analysis or give demos, then social skills are a lot more significant than if you're one of the "boys in the back room" fine tuning the module that calculates the convex hull of some data points.
And yes, once upon a time I used to think that technical merit ought to be the only yardstick - until I'd been out in the workforce for a few years and observed some programming teams working on medium-large projects in action. School (with a couple of rare exceptions) doesn't prepare you for that.
I'm surprised more companies don't employ rigorous application tests and psychological evaluations to replace the caprice of the varied interviewers.
Most companies aren't pushing the bleeding edge so hard that they need technical skills uber alles, and don't have the managers capable of leading teams made up of that sort even if they did. By the time a candidate gets to the interview stage, the company has a pretty good idea (eg from the resume, etc) that the candidate is probably "good enough" technically and the interview is to make sure the resume wasn't padded and that the candidate will fit in with the existing employees. When a candidate has gone through a round of interviews, the hiring manager generally has two questions of the interviewers: "does he know his stuff?" and "will he fit in?".
(That said, a company doing bleeding edge work will definitely do a pretty rigorous technical appraisal often including tests. They can't afford the merely "good enough". An interview I did at a company building supercomputer clusters was like that -- I've had college finals that were easier. I passed, but alas the company re-orged and eliminated the position (and a few others) before the start date.)
Shoddy code will eventually break. The exception is if the environment it operates in never changes. This is also true with buildings, appliances, etc, except that their environment changes by itself. And I really doubt that you'll find differences of opinion over what constitutes shoddy code. Code style differences, sure, but that's not the same thing. Unreachable code, unused variables, failure to check inputs for domain-appropriateness, undocumented and inappropriate assumptions (cf "all the world's a VAX") etc -- none of this is "golden brilliant" to anybody.
I've heard of some extreme cases where they were able to swap out the control board with a fresh one to get the data out
Been there, done that, still have the burnt out drive electronics (a PSU failed badly, sending high voltage to the system, and the power surge literally exploded one of the chips on the drive card and burned off a few traces). It was an old Seagate SCSI drive. Fortunately I had a couple of others of the same model. Just swapped the circuit board on the drive and rescued the data.
(Unfortunately the other drive that fried (an IDE drive) I didn't have a replacment for, and even though the manufacturer still produced that model, they'd changed some details and the circuit boards were no longer physically compatible. Haven't tried the platter swap. Of course the power surge fried just about everything else in the computer too.)
You'd be too hesitant to write a line, for fear of having to erase it in front of the person, and appear unsure.
Yep, and I'm really not interested in hiring someone who lacks that kind of self confidence. I'd rather have somebody write a few lines of code, say "nope, this is wrong", erase it and start over, than have someone too paralyzed to do anything.
If your focus in an interview is to see who can come up with answers quickly, and pencil code easily, you'll miss those who, though they don't perform well under social pressure, might be brilliant when allowed some time alone.
Sorry, it's a business. Programming teams (and I'm not talking XP here) need to be able to bounce ideas off each other, to stand up and do design and/or code reviews, and too-often work under some deadline pressure.
You'll weed out the social phobics and autistics, who represent a disproportionate number of coders.
Most coders I've worked with -- and I was in software development for a lot of years -- don't fit that mold. Those that did tended to be bad coders -- didn't follow style guidelines (their way was better), or spent too much time trying to find their own answer to a problem instead of just asking someone else. (Some of that is OK -- I've also seen coders who drive everybody else on the team crazy by bugging them with questions instead of RTFM.)
these weird tests that you think can peer into the heart of any programmer
;-)
I'm not (much) interested in peering into the heart of a programmer, but into their mind. And it doesn't have much to do with whether they can generate correct code or not; generating correct code is so easy that even a computer program can do it. It has a lot to do with how adaptable the programmer is -- is this guy going to be any good two years from now when the technology has changed? (Granted, interviewing style is going to be different if you're just looking for someone for a 3-month project vs a permanent long term hire.)
Programming is kind of weird in that something can outwardly function, but yet be terribly coded. I don't know of many other fields where this is true.
Geez, look at the internals of almost any consumer device, or look at a house under construction, or... etc. It's true of almost anything where the manufacturer/builder can wrap a pretty skin around it that will hold up for a minimal amount of time. That's why there are things like electrical codes and building codes and inspectors. Software isn't quite there yet, except in certain critical fields like avionics. If commercial software had to have something equivalent to a UL certification, the whole field would collapse overnight.
Most people looking for "voodoo indicators" are probably techies who don't really have a clue how they themselves do what they do, so they don't know how to look for it in other people. (Having miserable people-skills in the first place may have something to do with that, too.)
On the other hand what you may think is a voodoo indicator may actually be something that is important to the project/company and extremely relevant in the interviewer's experience, or that they're using that to find out something other than what you think they are.
An example: one of my fellow senior programmers/technical interviewers at a company where the work involved a lot of computational geometry was fond of asking about finding convex hulls. Unlikely that anyone could give a good technical answer off the cuff unless they'd just completed a course on it or had worked in that field for a while -- and even then there's no single right answer. That wasn't the point; the point was to see how the candidate reacted to the question. Being ignorant was okay so long as they were honest (extra points for coming up with some intelligent suggestions for finding out the answer) -- we had a database team, a UI team, etc where that kind of mathematical knowledge wasn't as important. But trying to bullshit your way through an answer was fatal. If you started talking about boats, you might be shown the door right then
A candidate might view that question about computing a convex hull as a voodoo indicator, especially if they didn't know the answer and they didn't get a job offer. But they might have blown the interview for totally unrelated reasons -- as might well have somebody who could discourse at length on the relative merits of various convex hull algorithms.
Yep, which is why I said "not that I necessarily ask people to write code on a white board". But the orginal poster had a "Never..ever" in there that indicates a certain inflexibility.
Inflexible programmers are brittle programmers -- and it's been my experience that they tend to write brittle code, or design brittle systems. Maybe it has something to do with a lack of imagination.
Never.. Ever.. ask somebody to write answers on a white board. It is not natural. If I prefer to place open/close brackets right when start a function then white boards do not fit that pattern. Little things like this make it more 'English' and less 'code'
You just failed any interview that I'd give. Not that I necessarily ask folks to write code on a white board, but if they can't handle that it shows that they're inflexible and would probably be totally lost in a design discussion or a code walkthrough. I don't care about matched brackets on a whiteboard -- compilers are real good at catching stuff like that -- but if you can't explain what you're doing in English (or whatever natural language you speak) then you don't understand it.
My thoughts exactly while I was reading that definition.
It means that, by definition, there are no extra-solar planets. So what the heck are we supposed to call all those things (203 of them, by latest count) smaller than a brown dwarf that we've found orbiting other stars?
My question, however, is just how much will the average citizen get out of reading a highly technical research report on a subject?
Irrelevant. True, most of them won't get anything out of it -- indeed won't even bother trying to find it. That's no reason not to make the information available to those who do want to read it and may well be capable of understanding it.
Unless they are well schooled in a particular field, they likely won't even understand what the abstract is talking about.
Likely? Perhaps -- but even if only 2% of the population is intelligent enough, (eg, those with an IQ high enough to qualify for Mensa), and only half of those have done enough reading in the field to undestand the abstract, (and people that smart tend to do a lot of reading in many fields), that's still well over a million people in this country who could read it and understand it, given the opportunity.
It delivers a 24volt jolt of goodness down the line which fries every DSL modem between my place and the main office.
You're on a party line?
Anyway, the minimum ring signal voltage is at least 40v, and it can go over 100v. That 24v "jolt" is a tickle barely above the noise level.
I can call nationally for free for $25 / month.
Ah, this is obviously some new meaning of the word free with which we were previously unfamiliar. Does RMS know about this?
Watch the pilot episode again -- Season 1, Disc 1. And that's it.
Not that big a deal -- it's when Apophis is looking for a host for his mate.
It was inevitable. DOD is planning on shutting down Cheyenne Mountain and moving the (non-Stargate) operations to Peterson AFB. How can you film SG-1 episodes without access to the gate room?
Probably some alien virus got loose in there and they have to shut everything down.
(For the humor impaired: no, I'm not serious. If I were serious I'd have to explain how they're actually moving the Stargate to a formerly abandoned Titan missile silo complex on the plains out east of Denver, and how the scenery around there is way too boring to use as the locale for a TV series.)