Naive about the purpose of C, anyway. C was never designed to prevent you from shooting yourself in the foot. Writing C requires you to think, which is sadly out of vogue these days, as you point out later.
I know, it's insane nowadays! Why, just the other day I was just remarking to my barefoot wife, who was cleaning our clothes by beating them against the rocks in the river, and then rolling them through a wringer, that all these fancyboys with their pushbutton machines and laundry powder just don't value godly, manual labor anymore! Then I went to my factory job where the machines have no safety features, so they really require you to think, which is sadly out of vogue these days with OSHA and safety goggles and whatnots.
I read an interesting book (can't remember the name right now) where the author posited as follows:
For an advanced sentience, simulating universes is easy and efficient. They could simulate many universes. Therefore, if we face the question of whether our universe is real or simulated probabilistically, then it should be far likelier that we are in a simulated universe than a real one.
The same author made an argument which seems to hold much more rigor for me: the universe operates off fixed-point arithmetic. Real numbers have an infinite number of digits. Therefore, any operation performed by the universe (from an information-theoretic point of view, where physics is information) must be performed on an infinite number of digits. Because these calculations clearly end, and you could never end any operation that works on an infinite number of digits, the number of digits the universe operates with must be finite.
A root password of "Fiona"? Wasn't that the name of the girl in Neal Stephenson's novel _The Diamond Age_? The one who was educated by the nanotechnological Primer book?
Although you got modded funny, consider the opposite point. By attacking cancers and other medical ailments, we add years to human lifespan -- years that can now be spent hunting for aliens.
Kurzweil
believes that humanity will accelerate itself to utopia (immortality,
ubiquitous AI, nanotech abundance) in the next 20 to 30 years. For
example, he noted that average life expectancy increases by about 3
months every year. Kurzweil then claimed that longevity trends are
accelerating so fast that the life expectancy will increase more than
one year for each year that passes in about 15 years. In other words,
if you can hang on another 15 years, your life expectancy could be
indefinitely long.
It's not that Intel was open with their intentions, and so kudos to Intel. OLPC didn't trust Intel. OLPC told Intel that they could join up IF AND ONLY IF Intel dropped their competing product, thus removing Intel's temptation to screw OLPC over. If Intel's intentions were truly evil, they had just been exposed. Intel refused to give up their own effort, thus signaling to OLPC that it would have gotten intentionally or unintentionally poor support. OLPC did the smart thing here, not Intel.
Personally, I think that if you should have the right to profit on your creative work for a period of many years then there should also be the obligation to punish you for crimes and misdemeanors for a period of many years.
How would you like to pay for that parking ticket every year for the next twenty years?
This is how people start thinking when their old business model starts falling into pieces.
I told the PBAE (Pyramid Building Association of Egypt) that suing kids and grandmothers for drawing triangles and lions was a bad move. I told them that in 1,000 BCE, but would they listen?
If you know Haskell and Erlang, please comment: do those languages bring enough power or convenience for concurrency that they will rise in popularity? People grow very attached to their familiar languages and tools; to displace the entrenched languages, alternative languages need to not just be better, they need to be a lot better.
I know some Erlang. The key behind Erlang's concurrency model is that there is no global state, which means that threading becomes easy. In addition, the threads are extremely light-weight, so context-switching between a bazillion threads is not a worry. Erlang encourages you to make everything a thread, because there is just no downside. And, it's been proven in a highly demanding environment -- Ericsson's telecom switches.
The biggest problem with Erlang -- which is more like a problem with programmers -- is that Erlang is a functional language. If you've been working in procedural languages for the last few decades, then getting your head around a functional language requires a lot of effort. Where you would normally fire off code that does this, then that, then loops this, then switch-cases that, then recurses, then does some more stuff, functional programming feels more like a punch in the nose than the solution to massive concurrency.
I think Erlang could be big Big BIG, but we would have to run up against a wall where the existing procedural programming paradigms are insufficient and very ungraceful when they are sufficient. I sense that this is why Java, JavaScript, Python, PHP, and Ruby came about. Not because you can't do the same thing in C, but because it hurts like hell when you try (imagine client-side code in web pages when you only have C to work with).
Now if there were a procedural-looking language with the features of Erlang, I think that would be an instant success.
You don't get a lawyer in Small Claims court, AFAIK. You represent yourself.
I guess Small Claims is there to make fools of people (like on Judge Judy). Because after all, a person who represents himself has a fool for a lawyer. Or something like that.
I would have thought the EFF ("Defending Freedom in the Digital Age") would be the more appropriate NGO to address this issue. I thought the FSF was just an organization promoting the GPL?
Suppose there's a disease for which there is a genetic test, but also good preventative care options. Ideally, you'd want to take the test, find out that you're at risk, and have the insurance company pay for the prevantative care. In an ideal world, that's what they would want too -- the preventative care would cost them less than paying if you actually did get sick.
I disagree.
Suppose the insurance company gets the results of the test. Then the company could just drop coverage altogether, so that they have to pay neither the preventive care cost, nor the cost of the disease.
Suppose the insurance company does NOT get the results of the test. Then the company could just drop coverage as soon as the cost of the disease becomes apparent.
Dropping coverage could also involve increasing premiums to an unaffordable rate, thus having the same effect.
Is it an enhancement, or a bug fix? If an enhancement, then you'll have to leave it to the marketeers who will always assume the enhancement is needed RIGHT NOW! Unfortunately, your bosses will determine the schedule for enhancements.
Bug fixes are a little easier to get a handle on. Determine what impact the bug has. Is it leaking data to unauthorized users? If so, is the data private or public? Use the egg-on-face test. If the data got out to the press, would the PR have a highly negative effect on the company? Negligable effect?
Is it corrupting data? If so, same analysis, but does the corruption of data have a highly negative impact on the application's usefulness? Negligable? Does it destroy very important customer data? Not so important?
Is it delaying data? Is the data involved very time-sensitive? Not so much?
Each of these criteria can help you determine how important it is to fix the bug. Unfortunately, it's your company's culture that will determine the timeframe. Laid-back company? Large company? Going downhill and everyone knows it? Critical fixes: 1 week, important fixes: 2 weeks, nice-to-have fixes: 4 weeks. Small company? Foaming-at-the-mouth company? Critical fixes: 24 hours, important fixes: 4 days, nice-to-have fixes: 2 weeks.
These are just guesses. Again, it depends on what your company has historically done.
And if, at the end, you still feel the deadline is unreasonable, I guess you can always just slow the work down without telling anyone;)
Slashdot Mirror
I know, it's insane nowadays! Why, just the other day I was just remarking to my barefoot wife, who was cleaning our clothes by beating them against the rocks in the river, and then rolling them through a wringer, that all these fancyboys with their pushbutton machines and laundry powder just don't value godly, manual labor anymore! Then I went to my factory job where the machines have no safety features, so they really require you to think, which is sadly out of vogue these days with OSHA and safety goggles and whatnots.
The shame!
--Rob
I prefer Penrose's description of the halting problem, from The Missing Science of Consciousness. But that's just me :)
--Rob
I read an interesting book (can't remember the name right now) where the author posited as follows:
For an advanced sentience, simulating universes is easy and efficient. They could simulate many universes. Therefore, if we face the question of whether our universe is real or simulated probabilistically, then it should be far likelier that we are in a simulated universe than a real one.
The same author made an argument which seems to hold much more rigor for me: the universe operates off fixed-point arithmetic. Real numbers have an infinite number of digits. Therefore, any operation performed by the universe (from an information-theoretic point of view, where physics is information) must be performed on an infinite number of digits. Because these calculations clearly end, and you could never end any operation that works on an infinite number of digits, the number of digits the universe operates with must be finite.
--Rob
Looking for tuberculosis? Buy tuberculosis now!
A root password of "Fiona"? Wasn't that the name of the girl in Neal Stephenson's novel _The Diamond Age_? The one who was educated by the nanotechnological Primer book?
--Rob
Although you got modded funny, consider the opposite point. By attacking cancers and other medical ailments, we add years to human lifespan -- years that can now be spent hunting for aliens.
--Rob
It's not that Intel was open with their intentions, and so kudos to Intel. OLPC didn't trust Intel. OLPC told Intel that they could join up IF AND ONLY IF Intel dropped their competing product, thus removing Intel's temptation to screw OLPC over. If Intel's intentions were truly evil, they had just been exposed. Intel refused to give up their own effort, thus signaling to OLPC that it would have gotten intentionally or unintentionally poor support. OLPC did the smart thing here, not Intel.
--Rob
Personally, I think that if you should have the right to profit on your creative work for a period of many years then there should also be the obligation to punish you for crimes and misdemeanors for a period of many years.
How would you like to pay for that parking ticket every year for the next twenty years?
--Rob
I told the PBAE (Pyramid Building Association of Egypt) that suing kids and grandmothers for drawing triangles and lions was a bad move. I told them that in 1,000 BCE, but would they listen?
--Rob
What if it isn't "fixing something that's broken" but "enhancing something that could be improved"?
--Rob
What about Ramsey Electronics?
--Rob
5 1/2. ????
Your Slashdot card is hereby revoked.
I think the OP was saying that tides rely on the moon. And we know how unreliable that thing is.
I know some Erlang. The key behind Erlang's concurrency model is that there is no global state, which means that threading becomes easy. In addition, the threads are extremely light-weight, so context-switching between a bazillion threads is not a worry. Erlang encourages you to make everything a thread, because there is just no downside. And, it's been proven in a highly demanding environment -- Ericsson's telecom switches.
The biggest problem with Erlang -- which is more like a problem with programmers -- is that Erlang is a functional language. If you've been working in procedural languages for the last few decades, then getting your head around a functional language requires a lot of effort. Where you would normally fire off code that does this, then that, then loops this, then switch-cases that, then recurses, then does some more stuff, functional programming feels more like a punch in the nose than the solution to massive concurrency.
I think Erlang could be big Big BIG, but we would have to run up against a wall where the existing procedural programming paradigms are insufficient and very ungraceful when they are sufficient. I sense that this is why Java, JavaScript, Python, PHP, and Ruby came about. Not because you can't do the same thing in C, but because it hurts like hell when you try (imagine client-side code in web pages when you only have C to work with).
Now if there were a procedural-looking language with the features of Erlang, I think that would be an instant success.
--Rob
LOL, Limewire
http://tera-3.ul.cs.cmu.edu/
Must... resist... must... oh, heck with it:
In Soviet Russia, Prince stalks YOU!
--Rob
You don't get a lawyer in Small Claims court, AFAIK. You represent yourself.
I guess Small Claims is there to make fools of people (like on Judge Judy). Because after all, a person who represents himself has a fool for a lawyer. Or something like that.
--Rob
Because nobody is interested in the view pointing towards the roof of the car?
:)
--Rob
I would have thought the EFF ("Defending Freedom in the Digital Age") would be the more appropriate NGO to address this issue. I thought the FSF was just an organization promoting the GPL?
--Rob
I thought the EFF was the software equivalent of the ACLU?
--Rob
I disagree.
Suppose the insurance company gets the results of the test. Then the company could just drop coverage altogether, so that they have to pay neither the preventive care cost, nor the cost of the disease.
Suppose the insurance company does NOT get the results of the test. Then the company could just drop coverage as soon as the cost of the disease becomes apparent.
Dropping coverage could also involve increasing premiums to an unaffordable rate, thus having the same effect.
Relatedly, the House passed the Genetic Information Nondiscrimination Act of 2007 (H.R. 493) by 420-3. The three were Republicans: Flake (AZ), Paul (TX), and Royce (CA). Well done, nutjobs. The Senate has yet to pass its version (S.358).
In any case, since the bill is not yet law, there may be nothing stopping insurance companies from discriminating against your genetic makeup.
--Rob
My argument would be that an insurance company is incapable of determining a person's future worth outside of their genetic cost.
--Rob
Yeah, but what if you're already doing that?
--Rob
Is it an enhancement, or a bug fix? If an enhancement, then you'll have to leave it to the marketeers who will always assume the enhancement is needed RIGHT NOW! Unfortunately, your bosses will determine the schedule for enhancements.
Bug fixes are a little easier to get a handle on. Determine what impact the bug has. Is it leaking data to unauthorized users? If so, is the data private or public? Use the egg-on-face test. If the data got out to the press, would the PR have a highly negative effect on the company? Negligable effect?
Is it corrupting data? If so, same analysis, but does the corruption of data have a highly negative impact on the application's usefulness? Negligable? Does it destroy very important customer data? Not so important?
Is it delaying data? Is the data involved very time-sensitive? Not so much?
Each of these criteria can help you determine how important it is to fix the bug. Unfortunately, it's your company's culture that will determine the timeframe. Laid-back company? Large company? Going downhill and everyone knows it? Critical fixes: 1 week, important fixes: 2 weeks, nice-to-have fixes: 4 weeks. Small company? Foaming-at-the-mouth company? Critical fixes: 24 hours, important fixes: 4 days, nice-to-have fixes: 2 weeks.
These are just guesses. Again, it depends on what your company has historically done.
And if, at the end, you still feel the deadline is unreasonable, I guess you can always just slow the work down without telling anyone ;)