Excuse me, but why would they put RFID tags on items like medicines and then design bags to block them from the view of the RFID system? Why not, uh...just not tag them in the first place?
The more I read about this RFID thing, the more I'm thinking the idea just hasn't come along to the point where it has to be. Obviously, if these issues are getting discussed at a high level, we need to put something in place that's a bit more targetted to the problem: we want to be able to read items for a specific purpose, and no other purpose. Walk out of a store with items, get automatically charged to the credit card = good. Someone sitting in the parking lot with an RFID reader able to tell you just walked out with Preparation H, herpes medication, and a coffee enema kit = bad.
I'm betting that the propeller-heads among us have the capability to solve this problem, technologically I'm talking. Also, do we have to start out tagging everything? Why not just tag the non-controversial items? Let's not start with the Complete Homeopathic Colon Invasion Toolkit (TM), or people themselves. Let's start with something a bit more pedestrian and refine things from there...
sev
Now That It's Written Down
on
Debugging
·
· Score: 5, Interesting
Well, even though I think most people 'round these parts would agree with me that the book covers the fairly obvious, I will say this: it's absolutely necessary to have an "expert" write these things down because all too often, us developers try to proceed and get blocked by management. At my last job, we had a big problem with WebLogic transaction management, some bizarre confluence of events was causing a HeuristicMixedException to be thrown by the platform--by the way, WebLogic people, thanks a lot for naming this exception this way and taking the time to make sure it gets thrown in no less than six totally unrelated (as far as I can tell) circumstances. I love it when exceptions originate ambiguously, from several sources, and no one part of the platform has authority over the problem.
This was a big enough problem that we had to set up a separate, isolated environment to figure out what was going on. 4 out of the 5 architects involved on the project (no it wasn't a huge project--you can see HME wasn't the only problem here) had cemented ideas about what was going wrong...none of them agreed of course...and we had no less than 3 managers with theories based on the idea that the Earth sweeps through an aether against which all things can be measured.
The biggest issue with this testing environment was keeping everyone's mitts off of it, especially those people who didn't have to ask for permissions to the system (the architects, managers...in other words everyone). And the managers didn't agree that it was particularly important to record every step methodically, or limit the number of people making changes to the system to 1 at a time. Instead, they set up a war room and engaged in what I like to call: Fix By Chaotic Typing. (It's chaotic in the sense that, there are definitely patterns to the activity taking place, but you have to be Stephen Wolfram to find and understand them.)
Needless to say, that didn't work. If I'd had access to this book, an authority willing to put the obvious in print might have bolstered my argument that we needed to take resources OFF this issue, not add more. Alas, it was not to be. The bigwigs decided that, since the current manpower wasn't able to track down this bug, it was time to bring in the high-priced WebLogic consultants. We got some 1st generation WebLogic people, 3 of them eventually, and they came in and immediately set themselves to the task of learning our business, telecommunications. And at a mere $150/hour, why not? (Management decided the bug was non-deterministic at some point and this assembly of people was given the informal team moniker: the Heuristics team. I preferred "the Histrionics team".)
So I eventually teamed up with the lead architect on the project and we solved the problem by subterfuge. We had to intentionally set these people working in a direction--everyone, employees and WebLogic consultants alike--that was so off-the-track they actually didn't interfere with any part of the system likely containing the error. This gave us a reasonable amount of time and space to track down the bug in 3 days' time.
At only the loss of 6 weeks and several thousand dollars in expenses alone for the WL consultants.
I remember in college adminning a lab of HP-UX's when the "let's send more than 64K ping packets" caused a buffer overflow and a reboot. So it's definitely not exclusively a Windows problem. On the other hand, the article leaves it a little ambiguous as to whether or not this hardware fix will be exclusively useful to Windows (though I don't see how they could do that, there could be some fancy hoops that Windows jumps through anyway that are necessarily to exploit the fix? doubt it, though).
I don't believe people still write things like, "Why doesn't everyone just write better code?" This reminds me of this one start-up I was working for during the dot com boom. I worked for one company that was so hard up to find managers they hired one guy to oversee the software department who'd never worked in the industry before. He had all sorts of unrealistic expectations, like "If you guys agree to double-check your code, we can save a lot of money by getting rid of the testing phase. We could release like three months early!" He was exasperated that professional coders couldn't write bug-free code on try #1.
To everyone who says, let's write better code...why don't you write better code? No more bugs in your code ever again!
Clearly, this is not the answer. What we need to do is take a step back and figure out the environment today, which we can do so much better than 25 years ago. We've seen a lot of the unintended consequences and now we know they exist. Intel or someone needs to develop a new processor from the ground up that addresses all the issues that we now know about through experience.
One thing I've learned in this business is that you cannot achieve quality through gentleman's agreement, simply by getting someone to agree to write better code.
Does anyone see war 50 years from now as a sort of Attack of the Clones affair? We'll have fleets of UAVs, the enemy will have them, it'll just be hoardes of them flying into each other and shooting each other down before any make it to tactical targets. War will amount to how much junk you can throw up into the air. Then we'll start using huge EMP weapons or nukes because they're not employed against actual people, so what's the big deal. The beginning of the end, taking the human risk out of war sort of implications...
One problem I've had on every job with CVS is that, eventually, every long-running project has to support multiple versions. These invariably go off onto their own branches, and then you have whatever branching scheme for continuing development superimposed on these version maintenance branches and it ends up looking like a bunch of spreading cracks on a frozen pond threatening to swallow the whole project.
I know there's a better way to handle this than CVS allows--does subversion implement it?
I wonder if the guy that put this article summary up read the article. They very clearly stated therein what the difficulty was and the unique confluence of events--specific to the rover's hardware and OS architecture--that led to the shutdown. What on earth (or on Mars) could we possibly take away from this experience that would lead to some ability to troubleshoot systems remotely?
I just don't see it...and I'm in computers for a living.
I'm tired of people competing for frequency bands. Where are all the super-antennae that allow you to focus in a signal that's only 0.00001 Hz different than another, different signal next to it?
Come on, technology! Figure it out! It's the 20-somethingth century for crying out loud. We should be able to have high-speed Internet connections and Morse code wonks. Why do we have to choose?
I like how the very first post discounts the point of this article right off by saying, sure, maybe linux got attacked successfully a lot, but what about all the other attacks that would've succeeded on Windows?
Come on, people. The fact is, the linux boxes got attacked successfully. That's a Bad Thing, regardless of what happened to Windows. It's an embarrassing thing for us linux people. Here's the real rub...
I've read studies over several years saying that linux boxes are nearly as secure as FreeBSD installations if the administrator sets up the environment properly. The results of the slashdotted study here is the result of the RTFM culture...hard to operate and administer, very little respect for the user in the design of the OS as a whole. I mean "respect" in the sense of "let's make this trivially easy to use because it's possible and respect the user's time" rather than "let's respect the user's intellect by reasoning they'll figure out how to work this thing no matter how ridiculously complicated we make it."
This study ought to convince all the people out there that don't worry about linux being too hard to use...it's affecting everyone, not just newbies. Not just dummies. Even admins can't set up a secure box. We have to keep working on usability folks. Fact is linux is more potentially secure than Windows--but not in practice because no one can figure out how to lock it down.
I TOTALLY AGREE--100%!!! If you use Hungarian notation correctly (if you visit this link do a page search for "hung" to find the appropriate section), not only do you get the many benefits of it, you can never be fired.
(Don't just stick to that one page, go to the main page for more information on writing code "properly".)
Not true--I wholeheartedly disagree! There are plenty of bad winemakers and people that don't know what they're doing working in the wine industry. They can take good grapes and wreck them. On the opposite side of the spectrum, winemakers like Helen Turley can take a mediocre year and still turn it into a well-balanced enjoyable wine to drink for a reasonable price.
One of the chief examples of turning good grapes into bad wine is the tendency to over-oak Chardonnay, which is prevalent. Another problem that happens fairly frequently is winemakers get skittish towards the end of the growing season and they pick before the grapes have attained the proper sugar level and ripeness.
My opinion is that anything that makes programs to design is a Good Thing. One problem I've always had with Perl is that when you sit down to do something significant, you run into all kinds of options. An embarrassment of options, really. Options that allow you to do the same thing several different ways, so there's no reason to choose one way over another.
This is what makes Perl so great for little knock-off scripts, but it can never be a serious contender for serious jobs because no two people have a reason to agree on how to accomplish any given complex task. Code readability is out the window. Transfer of knowledge goes down as TCO and maintainability goes up. The object of Perl's game was to provide an extremely terse way to do little things...but let's keep in mind that terseness only works to deal with the little problems.
Having said that, if the new release can maintain Perl's legacy and give us a way to encapsulate terse solutions to small problems, but in a structured, regularized way, then we might just get the thing we need. Done correctly, any big problem can be sensibly solved in the new Perl by breaking it down into a bunch of little problems. Each little problem solved tersely, understandable on its own, connected together with a somewhat less-terse but sensibly high-level structure...sounds like most OO solutions to me and a good thing for Perl.
I worry about celebrities making wine. Often, the wine's price gets a bump just for the name recognition factor, regardless of how good it is. This is the deal with Coppola's wines--they're just ok wines for better-than-ok prices.
Celebrity winemakers overally have little impact on serious wine drinkers. Obviously, though, Coppola proved there's a market segment that will spend money for a name on the bottle.
I would like to point out a brand new up-and-comer, non-celebrity wine--Sawkar Family Vineyards. They make a delicious Syrah that's probably in the upper scale of what most people want to pay for a bottle, but it's one of those that's actually worth it.
Cosmonaut: Hey...what's all that stuff floating away from the space station over there? Astronaut: Uh oh. That's not gonna to be good for business... Jerry Seinfeld: --that's not gonna be good for anybody.
(Kramer floats by in a space suit, visibly upset.)
I literally could not care less. If we have to sacrifice an extra few years developing the next-gen programming languages (come on people, it's not like we'd NEVER figure it out without some esoteric ancestor of Hmong reminding us), it's a small price to pay in exchange for the ability to call up the Chinese mail order warehouse and explain--in one common tongue--that I ordered an ocean barge full of chrome and blue electric scooters, not the combination trampoline/tamborine home amusement kit.
(For those of you wondering, yes, they always mix those two up if you don't make sure you circle the kit number on the order form.)
I hate to break it to this author, but no matter what product you're talking about, there is a certain amount of trust involved. The question he raises is should one put more faith in open source software, or closed?
I would predict that the rate at which malicious code gets rooted out for any software project is roughly proportional to any other code that gets tossed (buggy, unnecessary, etc). So, if we look at it that way, is open source more at risk or less?
The author has also made the argument that it's not just a matter of getting rid of bad code, though, it's also the frequency at which it is inserted into the project. According to him, this is much more likely in open source. He asks, who's watching the watchers? Well, I am. All the other open source coders are. I would like to ask him, with respect to proprietary code: who's watching those watchers?
There's so much comedy on television. Does that cause comedy on the streets?
I think that it boils down to parents. I grew up watching violence on TV all the time, and in my case I barely ever torture animals for fun...like once a month tops.
Seriously, though, it really is the parents' influence over the kids. Kids without good guidance might never see a TV in their lives, but they'll end up doing drugs, or being violent, or joining the Jehovah's Witnesses. That why I roll my eyes when I hear O'Reilly on TV going after rappers and other people who he says are damaging kids who don't have good supervision at home. Rappers or not, those kids aren't going to turn out any different if they don't have responsible parents, man! Wise up!
I have to agree with BillyBlaze on this one. As a practical matter, you're comparing your total intake with what you thought you drank, you're not comparing it to zero intake.
Though I'll give you this...I accept your comment because you seem to be basing it on research that says overall, coffee adds hydration, though not nearly as much as an equal volume of water (though, to be fair to coffee, Gatorade is in the same boat to a lesser extent). To take my point to hyperbole so as to understand its general bearing, though...
Imagine drinking a liquid comprised mostly of water and a small amount of super-dehydrating compound that acts over a long time. The water passes, the compound goes to work sucking up the next twenty glasses of water you have.
This little thought experiment is just that--it's not meant to contradict anything you said, just to make my thinking clear if it wasn't before.
I too thought of this as a possible means of explaining this situation, but rejected it (and I'm referring to your intended meaning pointed out by tbspit in this thread). The explanation you put forth here does not satisfy because the same argument could be applied to Integer[]s and Number[]s.
Alas, the corresponding array code does indeed fail at compile-time, and it is well-defined and unambiguous:
Integer[] i = new Integer[3];
Number[] n = i;
n[0] = new Float(1.1);
There's no reason in generics why the compiler couldn't have been designed to similarly reject code if you replace the arrays with type-parameterized ArrayLists.
I have indeed set off a number of bullshit detectors, and rightly so. I apologize. My statement that C# code must be run on a Windows-supported platform under Windows is incorrect. This is admittedly very old information that I should have checked out, in fact the only time it could have been true was in the formative stages of the language and the.NET platform.
I try to be as responsible as I can in posts to the/. community because it is the first forum I've found that self-moderates so well (in most cases, anyway--I'd apply a negative mod to my own post here if I could).
I read through the majority of the 310 comments on this story (310 as of this moment) and I can't believe no one has touched on an important aspect of the scientific community's backlash against Wolfram's book: he end-ran them.
He may be egotistical (I read most of ANKOS and I did not find his constant self-laudation very charming), but so are many people in science and math. In what other fields can one prove beyond a shadow of a doubt the significance of one's contributions? The Huxleys and Jungs of history could never have felt quite the same tinge of accomplishment as Einstein must have, because literature and psychology have no such measure of the value of an idea. So there is more to scientific self-puffery than just ego, it is a very human thing for humans to fall into this trap when they have managed to make a real, recognizable contribution. (Earlier in this thread, in fact, I saw someone taken to task for Newton's ever-misunderstood "on the shoulders of giants" as a symbol of his humility...which it was not, though arguably so.)
So I think we can all agree, if on nothing else, that Wolfram's ego is definitely not the only ego involved here. Instead of publishing his ideas in the framework of the mathematical and scientific research communities, he chose to publish his findings to the world-at-large. This, in and of itself, can be seen as an immensely egotistical act (one I'm glad of, though, as I'll explain). By doing this, he is essentially saying that his ideas are so great they are likely to be misunderstood (the plaintive cry of many a genius) by his peers and relegated to the back shelf until the community catches up with him. He's confident he's hit on some seed of truth, and he wants to spur the world to cultivate it so he can live to see its fruits...probably so he can hear his praises sung while still living. Not very selfless.
His feeling that his genius is too great to be contained by the research community is felt by every other member of that community, but they lack the means to do anything about it. ANKOS (the book, not the science) is quite enough of an affront to these people for them to bring the full weight of their intellectual wrecking ball to bear on Wolfram's tome. Certainly this is not true across the board, but just as certainly there is at least some venom reserved for him out of animus.
The problem with all this demogoguery that inevitably follows great men around is that the focus very quickly falls upon the men involved instead of the ideas. (One thing we all must admit: Wolfram is a great man. Keep in mind that I'm using "great" in the sense of the gravitas of his ideas. In this same sense Hitler was one of history's terrible greats, as the grand sum of his ideas had enough weight to sweep an entire nation to madness. In fact, in this sense I supposed Hitler was a much greater man than Wolfram; if Hitler's ideas swept a community to madness, Wolfram's ideas only achieved anger.:-) ) So to Wolfram's serious detractors, I hear you with a suspicious ear, while fairness requires that I simply ignore Wolfram's own self-congratulations. If only all such commentary were passionate only toward ideas and dispassionate towards men, it would not take history so long to sift through the idea pile.
We ought to judge people for the most part based on their actions and the results of those actions, not their motivations. Wolfram may have end-run his community out of ego, but I believe the effect in this particular case to be positive. Look at it this way: he has taken the time to introduce these ideas to an entire generation of laypeople. This may present the work in a form that is undesirable to academic researchers, but it certainly does not preclude them from judging those ideas. The upshot is, it's an inclusive strategy that makes the work accessible to everyone. What's bad about t
No "cueing" at the checkouts is fine for you Brits, but that won't work over here in the States. We don't queue at checkouts, we line up. So how would RFID help us Yanks, hm?
I never created container classes for every type-specific container I wanted. If I wanted typing in the elements of an ArrayList, for example, I wouldn't create a FloatArrayList and an IntegerArrayList. That'd be a waste of time. Instead, I'd create a TypedArrayList that extends ArrayList and takes a Class in the constructor. Then, whenever you store anything in that collection, it checks the class of the object you're trying to store against the class specified at instantiation time.
It's not as clean as generics (I'm glad they're here), but did anyone seriously write fifty different ArrayLists, one for each type they needed to store in there? That's not using your head...
This is one of the most misunderstood aspects of the C# vs Java debate.
If you write code in Java, you can run the same compiled class files on any platform. In C#, any code you write MUST run on a Windows-supported platform under Windows, but because every.NET language compiles to the CLA (Common Language Architecture), they are all translated into a single, compatible language before going to bytecode. Meaning, you can interoperate between any.NET language, have C# functions call a C++ function (assuming C++ is a.NET supported language now or someday) and just have it work...no CORBA, no distributed programming, etc. Furthermore, the CLA common language provides stuff like garbage collection so you can neglect free() and delete() in C++ and not worry about memory leaks (just don't compile that code with a non-.NET C++ compiler). The grand vision here is that everyone using.NET is locked into the.NET framework running on a Windows platform. There's nothing open about that.
I'm guessing that you dropped some text between angle brackets, and what you meant to say was something along the lines of:
ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<Number> t = s;// does not compile
It is indeed true that, though s contains only Integers, which are all indeed Numbers as well, you cannot make this assignment. The reason is that, though Integer extends Number, the new types you've created (ArrayList<Integer> and ArrayList<Number>) using the genericized code have no such inheritance relationship with each other that would allow such an assignment.
In generics, when you instantiate a genericized class and specify a type parameter, you're effectively creating a new type. In the example of the ArrayList, an ArrayList<Integer> extends whatever object that ArrayList does, and implements all of its interfaces, but it does not extend ArrayList itself or any type-parameterized variant of ArrayList.
Slashdot Mirror
Excuse me, but why would they put RFID tags on items like medicines and then design bags to block them from the view of the RFID system? Why not, uh...just not tag them in the first place?
The more I read about this RFID thing, the more I'm thinking the idea just hasn't come along to the point where it has to be. Obviously, if these issues are getting discussed at a high level, we need to put something in place that's a bit more targetted to the problem: we want to be able to read items for a specific purpose, and no other purpose. Walk out of a store with items, get automatically charged to the credit card = good. Someone sitting in the parking lot with an RFID reader able to tell you just walked out with Preparation H, herpes medication, and a coffee enema kit = bad.
I'm betting that the propeller-heads among us have the capability to solve this problem, technologically I'm talking. Also, do we have to start out tagging everything? Why not just tag the non-controversial items? Let's not start with the Complete Homeopathic Colon Invasion Toolkit (TM), or people themselves. Let's start with something a bit more pedestrian and refine things from there...
sev
Well, even though I think most people 'round these parts would agree with me that the book covers the fairly obvious, I will say this: it's absolutely necessary to have an "expert" write these things down because all too often, us developers try to proceed and get blocked by management. At my last job, we had a big problem with WebLogic transaction management, some bizarre confluence of events was causing a HeuristicMixedException to be thrown by the platform--by the way, WebLogic people, thanks a lot for naming this exception this way and taking the time to make sure it gets thrown in no less than six totally unrelated (as far as I can tell) circumstances. I love it when exceptions originate ambiguously, from several sources, and no one part of the platform has authority over the problem.
This was a big enough problem that we had to set up a separate, isolated environment to figure out what was going on. 4 out of the 5 architects involved on the project (no it wasn't a huge project--you can see HME wasn't the only problem here) had cemented ideas about what was going wrong...none of them agreed of course...and we had no less than 3 managers with theories based on the idea that the Earth sweeps through an aether against which all things can be measured.
The biggest issue with this testing environment was keeping everyone's mitts off of it, especially those people who didn't have to ask for permissions to the system (the architects, managers...in other words everyone). And the managers didn't agree that it was particularly important to record every step methodically, or limit the number of people making changes to the system to 1 at a time. Instead, they set up a war room and engaged in what I like to call: Fix By Chaotic Typing. (It's chaotic in the sense that, there are definitely patterns to the activity taking place, but you have to be Stephen Wolfram to find and understand them.)
Needless to say, that didn't work. If I'd had access to this book, an authority willing to put the obvious in print might have bolstered my argument that we needed to take resources OFF this issue, not add more. Alas, it was not to be. The bigwigs decided that, since the current manpower wasn't able to track down this bug, it was time to bring in the high-priced WebLogic consultants. We got some 1st generation WebLogic people, 3 of them eventually, and they came in and immediately set themselves to the task of learning our business, telecommunications. And at a mere $150/hour, why not? (Management decided the bug was non-deterministic at some point and this assembly of people was given the informal team moniker: the Heuristics team. I preferred "the Histrionics team".)
So I eventually teamed up with the lead architect on the project and we solved the problem by subterfuge. We had to intentionally set these people working in a direction--everyone, employees and WebLogic consultants alike--that was so off-the-track they actually didn't interfere with any part of the system likely containing the error. This gave us a reasonable amount of time and space to track down the bug in 3 days' time. At only the loss of 6 weeks and several thousand dollars in expenses alone for the WL consultants.
sev
I remember in college adminning a lab of HP-UX's when the "let's send more than 64K ping packets" caused a buffer overflow and a reboot. So it's definitely not exclusively a Windows problem. On the other hand, the article leaves it a little ambiguous as to whether or not this hardware fix will be exclusively useful to Windows (though I don't see how they could do that, there could be some fancy hoops that Windows jumps through anyway that are necessarily to exploit the fix? doubt it, though).
I don't believe people still write things like, "Why doesn't everyone just write better code?" This reminds me of this one start-up I was working for during the dot com boom. I worked for one company that was so hard up to find managers they hired one guy to oversee the software department who'd never worked in the industry before. He had all sorts of unrealistic expectations, like "If you guys agree to double-check your code, we can save a lot of money by getting rid of the testing phase. We could release like three months early!" He was exasperated that professional coders couldn't write bug-free code on try #1.
To everyone who says, let's write better code...why don't you write better code? No more bugs in your code ever again!
Clearly, this is not the answer. What we need to do is take a step back and figure out the environment today, which we can do so much better than 25 years ago. We've seen a lot of the unintended consequences and now we know they exist. Intel or someone needs to develop a new processor from the ground up that addresses all the issues that we now know about through experience.
One thing I've learned in this business is that you cannot achieve quality through gentleman's agreement, simply by getting someone to agree to write better code.
sev
Does anyone see war 50 years from now as a sort of Attack of the Clones affair? We'll have fleets of UAVs, the enemy will have them, it'll just be hoardes of them flying into each other and shooting each other down before any make it to tactical targets. War will amount to how much junk you can throw up into the air. Then we'll start using huge EMP weapons or nukes because they're not employed against actual people, so what's the big deal. The beginning of the end, taking the human risk out of war sort of implications...
sev
One problem I've had on every job with CVS is that, eventually, every long-running project has to support multiple versions. These invariably go off onto their own branches, and then you have whatever branching scheme for continuing development superimposed on these version maintenance branches and it ends up looking like a bunch of spreading cracks on a frozen pond threatening to swallow the whole project.
I know there's a better way to handle this than CVS allows--does subversion implement it?
sev
I wonder if the guy that put this article summary up read the article. They very clearly stated therein what the difficulty was and the unique confluence of events--specific to the rover's hardware and OS architecture--that led to the shutdown. What on earth (or on Mars) could we possibly take away from this experience that would lead to some ability to troubleshoot systems remotely?
I just don't see it...and I'm in computers for a living.
sev
I'm tired of people competing for frequency bands. Where are all the super-antennae that allow you to focus in a signal that's only 0.00001 Hz different than another, different signal next to it?
Come on, technology! Figure it out! It's the 20-somethingth century for crying out loud. We should be able to have high-speed Internet connections and Morse code wonks. Why do we have to choose?
sev
I like how the very first post discounts the point of this article right off by saying, sure, maybe linux got attacked successfully a lot, but what about all the other attacks that would've succeeded on Windows?
Come on, people. The fact is, the linux boxes got attacked successfully. That's a Bad Thing, regardless of what happened to Windows. It's an embarrassing thing for us linux people. Here's the real rub...
I've read studies over several years saying that linux boxes are nearly as secure as FreeBSD installations if the administrator sets up the environment properly . The results of the slashdotted study here is the result of the RTFM culture...hard to operate and administer, very little respect for the user in the design of the OS as a whole. I mean "respect" in the sense of "let's make this trivially easy to use because it's possible and respect the user's time" rather than "let's respect the user's intellect by reasoning they'll figure out how to work this thing no matter how ridiculously complicated we make it."
This study ought to convince all the people out there that don't worry about linux being too hard to use...it's affecting everyone, not just newbies. Not just dummies. Even admins can't set up a secure box. We have to keep working on usability folks. Fact is linux is more potentially secure than Windows--but not in practice because no one can figure out how to lock it down.
sev
I TOTALLY AGREE--100%!!! If you use Hungarian notation correctly (if you visit this link do a page search for "hung" to find the appropriate section), not only do you get the many benefits of it, you can never be fired.
(Don't just stick to that one page, go to the main page for more information on writing code "properly".)
sev
Not true--I wholeheartedly disagree! There are plenty of bad winemakers and people that don't know what they're doing working in the wine industry. They can take good grapes and wreck them. On the opposite side of the spectrum, winemakers like Helen Turley can take a mediocre year and still turn it into a well-balanced enjoyable wine to drink for a reasonable price.
One of the chief examples of turning good grapes into bad wine is the tendency to over-oak Chardonnay, which is prevalent. Another problem that happens fairly frequently is winemakers get skittish towards the end of the growing season and they pick before the grapes have attained the proper sugar level and ripeness.
sev
My opinion is that anything that makes programs to design is a Good Thing. One problem I've always had with Perl is that when you sit down to do something significant, you run into all kinds of options. An embarrassment of options, really. Options that allow you to do the same thing several different ways, so there's no reason to choose one way over another.
This is what makes Perl so great for little knock-off scripts, but it can never be a serious contender for serious jobs because no two people have a reason to agree on how to accomplish any given complex task. Code readability is out the window. Transfer of knowledge goes down as TCO and maintainability goes up. The object of Perl's game was to provide an extremely terse way to do little things...but let's keep in mind that terseness only works to deal with the little problems.
Having said that, if the new release can maintain Perl's legacy and give us a way to encapsulate terse solutions to small problems, but in a structured, regularized way, then we might just get the thing we need. Done correctly, any big problem can be sensibly solved in the new Perl by breaking it down into a bunch of little problems. Each little problem solved tersely, understandable on its own, connected together with a somewhat less-terse but sensibly high-level structure...sounds like most OO solutions to me and a good thing for Perl.
sev
I worry about celebrities making wine. Often, the wine's price gets a bump just for the name recognition factor, regardless of how good it is. This is the deal with Coppola's wines--they're just ok wines for better-than-ok prices.
Celebrity winemakers overally have little impact on serious wine drinkers. Obviously, though, Coppola proved there's a market segment that will spend money for a name on the bottle.
I would like to point out a brand new up-and-comer, non-celebrity wine--Sawkar Family Vineyards. They make a delicious Syrah that's probably in the upper scale of what most people want to pay for a bottle, but it's one of those that's actually worth it.
sev
Cosmonaut: Hey...what's all that stuff floating away from the space station over there?
Astronaut: Uh oh. That's not gonna to be good for business...
Jerry Seinfeld: --that's not gonna be good for anybody.
(Kramer floats by in a space suit, visibly upset.)
Thank you, thank you. Thank you all very much.
sev
I literally could not care less. If we have to sacrifice an extra few years developing the next-gen programming languages (come on people, it's not like we'd NEVER figure it out without some esoteric ancestor of Hmong reminding us), it's a small price to pay in exchange for the ability to call up the Chinese mail order warehouse and explain--in one common tongue--that I ordered an ocean barge full of chrome and blue electric scooters, not the combination trampoline/tamborine home amusement kit.
(For those of you wondering, yes, they always mix those two up if you don't make sure you circle the kit number on the order form.)
sev
Couldn't this story have waited one more day until after Valentine's? To raise expectations last minute like that is just...well...brutal.
sev
I hate to break it to this author, but no matter what product you're talking about, there is a certain amount of trust involved. The question he raises is should one put more faith in open source software, or closed?
I would predict that the rate at which malicious code gets rooted out for any software project is roughly proportional to any other code that gets tossed (buggy, unnecessary, etc). So, if we look at it that way, is open source more at risk or less?
The author has also made the argument that it's not just a matter of getting rid of bad code, though, it's also the frequency at which it is inserted into the project. According to him, this is much more likely in open source. He asks, who's watching the watchers? Well, I am. All the other open source coders are. I would like to ask him, with respect to proprietary code: who's watching those watchers?
No one, that's who.
sev
It's like Dick Cavett said:
I think that it boils down to parents. I grew up watching violence on TV all the time, and in my case I barely ever torture animals for fun...like once a month tops.Seriously, though, it really is the parents' influence over the kids. Kids without good guidance might never see a TV in their lives, but they'll end up doing drugs, or being violent, or joining the Jehovah's Witnesses. That why I roll my eyes when I hear O'Reilly on TV going after rappers and other people who he says are damaging kids who don't have good supervision at home. Rappers or not, those kids aren't going to turn out any different if they don't have responsible parents, man! Wise up!
sev
I have to agree with BillyBlaze on this one. As a practical matter, you're comparing your total intake with what you thought you drank, you're not comparing it to zero intake.
Though I'll give you this...I accept your comment because you seem to be basing it on research that says overall, coffee adds hydration, though not nearly as much as an equal volume of water (though, to be fair to coffee, Gatorade is in the same boat to a lesser extent). To take my point to hyperbole so as to understand its general bearing, though...
Imagine drinking a liquid comprised mostly of water and a small amount of super-dehydrating compound that acts over a long time. The water passes, the compound goes to work sucking up the next twenty glasses of water you have.
This little thought experiment is just that--it's not meant to contradict anything you said, just to make my thinking clear if it wasn't before.
sev
I too thought of this as a possible means of explaining this situation, but rejected it (and I'm referring to your intended meaning pointed out by tbspit in this thread). The explanation you put forth here does not satisfy because the same argument could be applied to Integer[]s and Number[]s.
Alas, the corresponding array code does indeed fail at compile-time, and it is well-defined and unambiguous:
There's no reason in generics why the compiler couldn't have been designed to similarly reject code if you replace the arrays with type-parameterized ArrayLists.sev
I have indeed set off a number of bullshit detectors, and rightly so. I apologize. My statement that C# code must be run on a Windows-supported platform under Windows is incorrect. This is admittedly very old information that I should have checked out, in fact the only time it could have been true was in the formative stages of the language and the .NET platform.
I try to be as responsible as I can in posts to the /. community because it is the first forum I've found that self-moderates so well (in most cases, anyway--I'd apply a negative mod to my own post here if I could).
Anyway, thanks to those who pointed this out.
sev
I read through the majority of the 310 comments on this story (310 as of this moment) and I can't believe no one has touched on an important aspect of the scientific community's backlash against Wolfram's book: he end-ran them.
He may be egotistical (I read most of ANKOS and I did not find his constant self-laudation very charming), but so are many people in science and math. In what other fields can one prove beyond a shadow of a doubt the significance of one's contributions? The Huxleys and Jungs of history could never have felt quite the same tinge of accomplishment as Einstein must have, because literature and psychology have no such measure of the value of an idea. So there is more to scientific self-puffery than just ego, it is a very human thing for humans to fall into this trap when they have managed to make a real, recognizable contribution. (Earlier in this thread, in fact, I saw someone taken to task for Newton's ever-misunderstood "on the shoulders of giants" as a symbol of his humility...which it was not, though arguably so.)
So I think we can all agree, if on nothing else, that Wolfram's ego is definitely not the only ego involved here. Instead of publishing his ideas in the framework of the mathematical and scientific research communities, he chose to publish his findings to the world-at-large. This, in and of itself, can be seen as an immensely egotistical act (one I'm glad of, though, as I'll explain). By doing this, he is essentially saying that his ideas are so great they are likely to be misunderstood (the plaintive cry of many a genius) by his peers and relegated to the back shelf until the community catches up with him. He's confident he's hit on some seed of truth, and he wants to spur the world to cultivate it so he can live to see its fruits...probably so he can hear his praises sung while still living. Not very selfless.
His feeling that his genius is too great to be contained by the research community is felt by every other member of that community, but they lack the means to do anything about it. ANKOS (the book, not the science) is quite enough of an affront to these people for them to bring the full weight of their intellectual wrecking ball to bear on Wolfram's tome. Certainly this is not true across the board, but just as certainly there is at least some venom reserved for him out of animus.
The problem with all this demogoguery that inevitably follows great men around is that the focus very quickly falls upon the men involved instead of the ideas. (One thing we all must admit: Wolfram is a great man. Keep in mind that I'm using "great" in the sense of the gravitas of his ideas. In this same sense Hitler was one of history's terrible greats, as the grand sum of his ideas had enough weight to sweep an entire nation to madness. In fact, in this sense I supposed Hitler was a much greater man than Wolfram; if Hitler's ideas swept a community to madness, Wolfram's ideas only achieved anger. :-) ) So to Wolfram's serious detractors, I hear you with a suspicious ear, while fairness requires that I simply ignore Wolfram's own self-congratulations. If only all such commentary were passionate only toward ideas and dispassionate towards men, it would not take history so long to sift through the idea pile.
We ought to judge people for the most part based on their actions and the results of those actions, not their motivations. Wolfram may have end-run his community out of ego, but I believe the effect in this particular case to be positive. Look at it this way: he has taken the time to introduce these ideas to an entire generation of laypeople. This may present the work in a form that is undesirable to academic researchers, but it certainly does not preclude them from judging those ideas. The upshot is, it's an inclusive strategy that makes the work accessible to everyone. What's bad about t
No "cueing" at the checkouts is fine for you Brits, but that won't work over here in the States. We don't queue at checkouts, we line up. So how would RFID help us Yanks, hm?
sev
I never created container classes for every type-specific container I wanted. If I wanted typing in the elements of an ArrayList, for example, I wouldn't create a FloatArrayList and an IntegerArrayList. That'd be a waste of time. Instead, I'd create a TypedArrayList that extends ArrayList and takes a Class in the constructor. Then, whenever you store anything in that collection, it checks the class of the object you're trying to store against the class specified at instantiation time.
It's not as clean as generics (I'm glad they're here), but did anyone seriously write fifty different ArrayLists, one for each type they needed to store in there? That's not using your head...
sev
This is one of the most misunderstood aspects of the C# vs Java debate.
If you write code in Java, you can run the same compiled class files on any platform. In C#, any code you write MUST run on a Windows-supported platform under Windows, but because every .NET language compiles to the CLA (Common Language Architecture), they are all translated into a single, compatible language before going to bytecode. Meaning, you can interoperate between any .NET language, have C# functions call a C++ function (assuming C++ is a .NET supported language now or someday) and just have it work...no CORBA, no distributed programming, etc. Furthermore, the CLA common language provides stuff like garbage collection so you can neglect free() and delete() in C++ and not worry about memory leaks (just don't compile that code with a non-.NET C++ compiler). The grand vision here is that everyone using .NET is locked into the .NET framework running on a Windows platform. There's nothing open about that.
sev
I'm guessing that you dropped some text between angle brackets, and what you meant to say was something along the lines of:
It is indeed true that, though s contains only Integers, which are all indeed Numbers as well, you cannot make this assignment. The reason is that, though Integer extends Number, the new types you've created (ArrayList<Integer> and ArrayList<Number>) using the genericized code have no such inheritance relationship with each other that would allow such an assignment.In generics, when you instantiate a genericized class and specify a type parameter, you're effectively creating a new type. In the example of the ArrayList, an ArrayList<Integer> extends whatever object that ArrayList does, and implements all of its interfaces, but it does not extend ArrayList itself or any type-parameterized variant of ArrayList.
sev