Nor does there need to be - this erosion of freedom is far more pernicious than any plot hatched in a back room. The "it's for your own good", or worse, "it's for our own good", is corrosive. Every "security enhancement" for the sake of feelgood eats away at freedom. Every step is justified as being only a minor intrusion, and thought to be worth it because we supposedly live in dangerous times.
On further thought, it's not just that they thought it probably wouldn't stand up in court, but that it wouldn't have a snowball's chance in hell. If potential charges were merely iffy, they'd pull the usual trick of charging him with things that could lead to 500 years in prison, then offer him a plea bargain for 2 years. They figured he'd go for a real trial, probably get outfits like the ACLU on his side, and the gubmint would lose big time. If they could get an 82 year old nun convicted at trial of terrorism and potentially a 16 year sentence, then the possibility of successfully prosecuting this polygraph case must have been somewhere between incredibly improbable and outright impossible. The worst part is they understood that from the beginning.
That's frustrating when getting or keeping your job depends on getting or keeping a security clearance, but for truly important things your approach makes sense. The difficulty is that false positives are not the only problem with polygraphs; they also give false negatives. Hence depending at all on such a technique gives you a false sense of security. It's CYA at best.
That is pretty shady that they seize his materials, use it to their advantage, but then don't charge him with any crime. That's basically tyranny.
+17 insightful.
It's been 9 months since they seized his records, and they haven't charged him with a crime? That proves that the criminal concerns were bull from the get go. They knew damn well what he was doing before they seized his records, and obviously knew damn well that criminal charges wouldn't hold up in court (either we have a few honest federal judges left, or they were worried about an actual jury of his peers).
kg is a troublesome case. You can debate whether it's better to use grams or kg as the base unit, but I'd argue kg is the base unit in the MKS system. Not so for kOhms.
BTW, you rounded wrong. Pi to 4 decimal places is 3.1416. However, in order to round 3.1415926 to 4 decimal places "correctly", you should specify the exact type of rounding you want to use. In that case it probably wouldn't matter, but there are plenty where it does. The cumulative effect of rounding a number of numbers can be significant (pun intended).
It's because of all the things that programmers have to memorize that programming is hard.
People learn the difference between integers and reals in grade school.
Having to write int() every time he wants an integer: 1. decreases bugs, and 2. makes the code more readable.
That's an argument for static typing. It forces you to specify that you're converting between a float and an int. Better yet if the function used to convert specifies the type of rounding, rather than the C style "I guess that cast truncates - what about negative numbers?".
Types are not natural; they were created to make compiler writing easier.
On the contrary. The easiest thing in the world is to specify implicit conversion rules, as C is so full of. Newer languages took that out for the sake of the programmers.
Then I discovered Erlang and found it to be the best solution...
We should recognize a new class of Language Wars for functional languages. Allow me the honor of firing the opening salvo: Erlang sucks, Haskell rulez! (not that I know Erlang, but why should I bother to learn it when it's such a lousy language).
The farmer's daughter joins you behind the bike shed and you want to debate programming languages? New hypothesis: geeks rarely get lucky because they don't even realize when it's offered to them.
P.S. There was a good Big Bang Theory episode about that.
The the extent I've looked at it, D seems like a great language. Maybe it doesn't get much attention because it's not one of the new cool (i.e. rehashed) languages, but it'd fill an important role. In many ways it's C++ done right. That fills the need for a language that's higher level than C, without all the historical baggage and minefield complexity of C++, and compiles to fast binary. I know lots of people these days say Java (or whatever your favorite slower language is) is fast enough, programming costs outweigh hardware costs, blah, blah, blah. In many cases that's true, but there are still plenty of cases where a 2x speed improvement is very important. Binary executables ain't dead.
One thing I'm curious about though is whether D can pull off the "have your cake and eat it too" approach of using garbage collection by default, but being able to disable it when needed. Does it have a set of libraries that can do both, or are they all heavily GC dependent?
Lastly, will it ever become popular? The two ways I can think of are that it becomes so popular in the FOSS community that it starts migrating over to workplaces, or if a major company champions it for their own use (the #2 D guy Alexandrescu works at Facebook).
I can see enforcing types for say, current and resistance, but what about the fact that current times resistance is voltage? I can see having a voltage type too, but do you have to write the rules for every combination of units that result in a different unit, or is there a more clever way to handle that?
Speak for yourself. Like most people I learned the difference between integers and reals, and between numbers and the notation for numbers, before high school.
If you want billions, the choice of language doesn't matter. If you've ever seen the Curious George movie though, you'll understand that the real money is in parking garages.
How many new languages really have anything new or interesting? Most just seem like whatever struck the author as a "best of" list. I'm learning Haskell out of curiosity, because it's genuinely different from other languages I know. However, knowing Perl and Python, learning Ruby or Lua strikes me about as interesting as watching paint dry. You can argue until hell freezes over about the pros and cons of different ones, but is there really that much difference? I'm not worried about saying that, because I'm wearing my Nomex undies today. If it makes any Ruby or Lua fans happy though, I'd feel the same way about learning Python if, for example, I already knew Ruby or Lua.
I find one of the most effective techniques is just to enforce the rule that any variable that represents a physical quantity must have the units appended to it, using std SI notation, like massCannonBall_kg, or distanceToOuthouse_m. It also helps to insist that all units be base units. With floating point, why use _kOhm or _MOhm, when you can just use _Ohm for everything? It eliminates confusion and errors to stick to base units, and you can easily convert for convenient user I/O.
generally the low level programmers just turn out more secure, stable and rock solid code
At the risk of being a bit self-serving, I agree (at least when you're talking about embedded stuff). Working in higher level languages is not intrinsically bad, but the discipline that comes from the experience working in lower level languages is valuable (especially when speed is a big consideration). It's been years since I've done more than a few dozen lines of assembly here and there, but I always found it curious that I had the lowest bug rate per line when writing assembly (though that doesn't necessarily mean the lowest bug rate for a given functionality). It's such a tedious pain to write, read and debug assembly, that I go over everything very carefully before even trying to assemble it.
Slashdot Mirror
Please explain how this was feigned, fudged, and fibbed. I'm sure there are plenty of denialist websites that can help you with that.
you know I'm right
And as can be inferred from that statement, able to read minds too. Impressive.
There's no grand conspiracy out to get you.
Nor does there need to be - this erosion of freedom is far more pernicious than any plot hatched in a back room. The "it's for your own good", or worse, "it's for our own good", is corrosive. Every "security enhancement" for the sake of feelgood eats away at freedom. Every step is justified as being only a minor intrusion, and thought to be worth it because we supposedly live in dangerous times.
Redundant: it's the same as the list of people who, for their own safety, shouldn't be allowed to play with sharp objects.
On further thought, it's not just that they thought it probably wouldn't stand up in court, but that it wouldn't have a snowball's chance in hell. If potential charges were merely iffy, they'd pull the usual trick of charging him with things that could lead to 500 years in prison, then offer him a plea bargain for 2 years. They figured he'd go for a real trial, probably get outfits like the ACLU on his side, and the gubmint would lose big time. If they could get an 82 year old nun convicted at trial of terrorism and potentially a 16 year sentence, then the possibility of successfully prosecuting this polygraph case must have been somewhere between incredibly improbable and outright impossible. The worst part is they understood that from the beginning.
That's frustrating when getting or keeping your job depends on getting or keeping a security clearance, but for truly important things your approach makes sense. The difficulty is that false positives are not the only problem with polygraphs; they also give false negatives. Hence depending at all on such a technique gives you a false sense of security. It's CYA at best.
Also they taste good.
That is pretty shady that they seize his materials, use it to their advantage, but then don't charge him with any crime. That's basically tyranny.
+17 insightful.
It's been 9 months since they seized his records, and they haven't charged him with a crime? That proves that the criminal concerns were bull from the get go. They knew damn well what he was doing before they seized his records, and obviously knew damn well that criminal charges wouldn't hold up in court (either we have a few honest federal judges left, or they were worried about an actual jury of his peers).
kg is a troublesome case. You can debate whether it's better to use grams or kg as the base unit, but I'd argue kg is the base unit in the MKS system. Not so for kOhms.
Consider: int x; What happens here? x = 3.1415
Hopefully you get an error.
BTW, you rounded wrong. Pi to 4 decimal places is 3.1416. However, in order to round 3.1415926 to 4 decimal places "correctly", you should specify the exact type of rounding you want to use. In that case it probably wouldn't matter, but there are plenty where it does. The cumulative effect of rounding a number of numbers can be significant (pun intended).
It's because of all the things that programmers have to memorize that programming is hard.
People learn the difference between integers and reals in grade school.
Having to write int() every time he wants an integer: 1. decreases bugs, and 2. makes the code more readable.
That's an argument for static typing. It forces you to specify that you're converting between a float and an int. Better yet if the function used to convert specifies the type of rounding, rather than the C style "I guess that cast truncates - what about negative numbers?".
Types are not natural; they were created to make compiler writing easier.
On the contrary. The easiest thing in the world is to specify implicit conversion rules, as C is so full of. Newer languages took that out for the sake of the programmers.
People can learn to think in types. But that's a learnt ability, not a natural one.
So fractions and decimals are a natural way to think? Most kids in the earliest grades could disabuse you of that notion.
Only once.
That's the point - you can never re-assign to a variable.
Then I discovered Erlang and found it to be the best solution ...
We should recognize a new class of Language Wars for functional languages. Allow me the honor of firing the opening salvo: Erlang sucks, Haskell rulez! (not that I know Erlang, but why should I bother to learn it when it's such a lousy language).
The farmer's daughter joins you behind the bike shed and you want to debate programming languages? New hypothesis: geeks rarely get lucky because they don't even realize when it's offered to them.
P.S. There was a good Big Bang Theory episode about that.
The the extent I've looked at it, D seems like a great language. Maybe it doesn't get much attention because it's not one of the new cool (i.e. rehashed) languages, but it'd fill an important role. In many ways it's C++ done right. That fills the need for a language that's higher level than C, without all the historical baggage and minefield complexity of C++, and compiles to fast binary. I know lots of people these days say Java (or whatever your favorite slower language is) is fast enough, programming costs outweigh hardware costs, blah, blah, blah. In many cases that's true, but there are still plenty of cases where a 2x speed improvement is very important. Binary executables ain't dead.
One thing I'm curious about though is whether D can pull off the "have your cake and eat it too" approach of using garbage collection by default, but being able to disable it when needed. Does it have a set of libraries that can do both, or are they all heavily GC dependent?
Lastly, will it ever become popular? The two ways I can think of are that it becomes so popular in the FOSS community that it starts migrating over to workplaces, or if a major company champions it for their own use (the #2 D guy Alexandrescu works at Facebook).
I can see enforcing types for say, current and resistance, but what about the fact that current times resistance is voltage? I can see having a voltage type too, but do you have to write the rules for every combination of units that result in a different unit, or is there a more clever way to handle that?
There are too many programming languages.
Some people describe the recent increase in the number of languages as the Cambrian explosion, but what we need now is a mass extinction.
Speak for yourself. Like most people I learned the difference between integers and reals, and between numbers and the notation for numbers, before high school.
Not unreasonable - they're looking for people who understand time travel.
If you want billions, the choice of language doesn't matter. If you've ever seen the Curious George movie though, you'll understand that the real money is in parking garages.
So what sort of "language tradition" does PHP fall under?
The tradition of using PCP. Did you think that the name similarity is a coincidence?
Haskell is a truly different language, but what's the big deal about Python vs. Ruby Vs. Lua?
How many new languages really have anything new or interesting? Most just seem like whatever struck the author as a "best of" list. I'm learning Haskell out of curiosity, because it's genuinely different from other languages I know. However, knowing Perl and Python, learning Ruby or Lua strikes me about as interesting as watching paint dry. You can argue until hell freezes over about the pros and cons of different ones, but is there really that much difference? I'm not worried about saying that, because I'm wearing my Nomex undies today. If it makes any Ruby or Lua fans happy though, I'd feel the same way about learning Python if, for example, I already knew Ruby or Lua.
I find one of the most effective techniques is just to enforce the rule that any variable that represents a physical quantity must have the units appended to it, using std SI notation, like massCannonBall_kg, or distanceToOuthouse_m. It also helps to insist that all units be base units. With floating point, why use _kOhm or _MOhm, when you can just use _Ohm for everything? It eliminates confusion and errors to stick to base units, and you can easily convert for convenient user I/O.
generally the low level programmers just turn out more secure, stable and rock solid code
At the risk of being a bit self-serving, I agree (at least when you're talking about embedded stuff). Working in higher level languages is not intrinsically bad, but the discipline that comes from the experience working in lower level languages is valuable (especially when speed is a big consideration). It's been years since I've done more than a few dozen lines of assembly here and there, but I always found it curious that I had the lowest bug rate per line when writing assembly (though that doesn't necessarily mean the lowest bug rate for a given functionality). It's such a tedious pain to write, read and debug assembly, that I go over everything very carefully before even trying to assemble it.