But with the advent of science and philosophy, religion has become an antiquated relic of the past.
Given that I'm a flaming atheist, this will sound weird. However, I disagree.
I think science is about explaining how things are, not why they are or what we should do about it. Philosophy gives you a set of tools for approaching those questions and has a lot of interesting historical information on what people have said. But there's no right answer to many of philosophy's most interesting questions. For many people, they get those answers from one religion or another.
There is also an area that religion addresses that philosophy and science don't address at all: the lived experience of humankind, especially what many would call the spiritual side of things. Some Buddhist schools, for example, have nothing to say about gods or devils but a lot to say about how to live one's life in accordance with particular beliefs, like The Four Noble Truths and The Eightfold Path. Consider this quote:
The religion of the future will be a cosmic religion. It should transcend a personal God and avoid dogmas and theology. Covering both the natural and the spiritual, it should be based on a religious sense arising from the experience of all things, natural and spiritual as a meaningful unity. If there is any religion that would cope with modern scientific needs, it would be Buddhism.
You'd think some monk or preacher said that. Turns out, it was Albert Einstein.
I was just saying it's a pretty vague and unsupported off-the-cuff remark, rather than a scientific description, and thus incongruous in a story about hard science.
Sorry I misunderstood your point.
A scientist's motivations for doing science should not be held to the same standard of rigor that the science is. There are perfectly good scientists who do their work to, as they see it, reveal the greater glory of God. There's plenty of "vague and unsupported" in there, but I say that doesn't matter as long as the work is solid.
As to the incongruity, pop science articles regularly contain human interest hooks, so as to get people more involved in the topic. If you want your science straight up, perhaps Yahoo News isn't the best place for you to start.
Sure, for many in the creationist camp, science and God have no business mixing. But there are also those who believe as I do. Why do God and Science have to be mutually exclusive?
For me personally, it was the years of verbal harrassment I, a geeky kid, endured at the hands of Christians who seemed convinced that the main point of science was to kill and eat their precious Baby Jesus.
Now I'm mostly over it, and can actually have civilized discussions about relgion with my Christian friends. But for years I was implacably hostile to all things Christian, a flaming athiest with a grudge like a wasp-stung rhino. Now I generally save my ire for people like Pat "the gays caused 9/11" Robertson, and the creationist^W intelligent design loons who want to use political power to force their religion into science textbooks.
So putting it biblically, I'd say it's a case of, "whatsoever a man soweth, that shall he also reap". Perhaps if you're looking for more respect from pepole wearing lab coats, you could start by asking your co-religionists to practice what they're preaching about tolerance, humility, and love of their fellow man. Even unto the scientists.
So Altshuler claims, without any supporting evidence, that unnamed "people" in the undefined "ID community" make a big deal out of the unknowability of bee flight mechanics, and that having disproved this unkowability, he's successfully countered their alleged arugment?
I have personally heard this canard repeatedly from creationists. They will do it with pretty much anything that science doesn't have a ready answer to at the time. The bee one was popular because for a while it was a well-known unsolved problem that Bubba Sixpack could readily understand.
Now, of course, they've switched sides on this one. Before, the mystery of bee flight was proof of God's majestic inscrutability. Now that we've scruted it, it's proof of how darned smart God is.
For creationism to be "right" it needs to, for once, generate a testable, disproveable hypothesis and stop falling back on the old "anything we can't explain is God's will" argument.
Interestingly, this is not only bad science, it's bad theology. It's know as the "God of the gaps" problem, and it sets up a false conflict between science and religion. Just because we understand something doesn't make it any less wonderful.
Any given method should have more than one test case; any given class could have dozens.
On my projects the last few years, it's about 50% test code, 50% production code. I'd guess it's less than one test method per method under test. Not too bad to read.
Are you honestly suggesting that it's better to read and analyze all of that test code to determine what a method is and how it works -- i.e. the general context surrounding it -- rather than a simple paragraph or two in english?
I'm saying that it should already be pretty clear what a given class or method does by virtue of the design: package names, object names, object members, method names, parameter types and names, and relative relationships among all those. Failing that, I'll look at the code. When that's not clear or I suspect a bug, I go to the test cases. All of which should be written in a readable way; not a lot of analysis should be needed. Failing all of that, documentation is swell. It's great, for example, for a high-level overview document with, say, one page per 20-50 kloc to let new arrivals know the broad structure.
What you may miss if you haven't done it is that doing test-driven development forces much cleaner code. For example, I regularly see oversized methods in shops that think documentation is the only solution, but I've rarely see them in a test-driven team. It's just too hard to test. TDD also forces developers to look at their objects from the outside, yielding cleaner APIs. Once you've got 100% test coverage and have done all the refactoring you think necessary, there just isn't a lot of need for comments: 99% of the interesting information is already expressed.
Of course, it's possible that a bad programmer will make tests that are unclear, just as it's possible that they're bad writers who will make useless documentation. But if I have to bet, I'll bet on the tests, because a) they're more likely to have one skill (coding) than two (coding and writing); b) the compiler and testing framework force some semantic rigor and verify accuracy; and c) I can use coverage tools to figure out which tests really cover which code.
As for drift, you forget that refactoring is a part of test-driven development; test case code drifts just as much as API documentation can.
Not even close. Tests can be automatically verified by the computer. A human has to manually review all related documentation every time the code changes. On my projects, every time code is checked in all the tests are run. How often do you check all your docs for accuracy?
Of course, readability is still a potential problem, which is why I prefer pair programming or code reviews.
Do you like to chew tinfoil? Do you like to roll around on broken glass?
Actually, when I'm feeling masochistic, I try to have serious discussions with condescending blowhards on Slashdot. How about you?
The answer (40 years of experience with this) is not to set a standard on how much commenting is needed; it's to have walk-throughs of the code with an intelligent reader who isn't directly involved with the code. If they can read and understand the code, it's enough.
Yes! The only way to be sure that other people can understand the code is to have other people try to understand the code.
I prefer to do this with pair programming and frequent pair rotation, but inspections are ok, too.
And here is one of the reasons the agile method people get so much wrong. Automatic tests are not documentation, by any means. They do not prove that code is correct, or bug free. [...] Automatic tests have their place, but they are not equal to design or documentation. Any place that uses them as such is producing shitty software which will bite them on the ass when the original devs leave.
I note that documentation also doesn't prove that the code is correct or bug free. Tests at least prove that certain functionality is present and that certain bugs are absent. To get good design, correct code, and low bug count, you need other practices, like frequent deployment, frequent inspections, and common code ownership.
You should also consider that both tests and documentation can be written well or poorly. For both, it's only the well-written sort that is useful to those who come later. If I have a choice between code with tests but no docs or docs but no tests, I'll always take the code with the test suite.
Even if you're the best normalizer/refactorer (is "refactorer" a word?) in the world, you had better explain what a function or method or class or aspect or (etc..) does, how it's used, and what the expected results are, or you have made code that is a nightmare to maintain.
For what it does, that's what names are for. For how it's used and what the expected results are, that's what test cases are for. And the big advantage of test cases is that a computer can tell if they're still valid; comments are prone to drift.
Still, those 30 friends should bear most (possibly all) of the responsibility, since they're the ones actually calling me.
I don't see it that way. The friends may or may not have any intent to harrass. But the person orchestrating them sure does.
The analogy's especially clear with more dramatic crimes. A drug kingpin may never actually touch the drugs; in fact, drug gangs often use throwaway people at the low levels to insulate themselves. Low-level soliders are generally not the ones held responsible for war crimes. And more mundanely, the people who did the actual changing of the numbers at Enron aren't the ones the government is after. Indeed, they may have been innocent of criminal liability, acting in good faith based on what their corrupt bosses told them. But in all of these, the bosses are rightly seen as the most serious criminals.
Either way, taking you (or them) to court isn't going to resolve any personal differences between us. We'd both be better off if I found out why you had all your friends try to annoy me, and fixed that instead. If it can't be fixed (which is quite rare), I can always stop answering the phone. Jumping straight to coercion (e.g. lawsuits) is how wars get started...
That's ridiculous.
I agree that calling the law should be a matter of last resort, and I think the prosecutor and the school here are acting like idiots. But people have a right to be free of harrassment, and the reason we have a court system with powers to convict people of crimes and to issue restraining orders is to guard that freedom, and to give people an alternative to taking things into their own hands.
Wars get started because people fail to use the legal system or don't have an effective one available. That's why violence is such a problem in illegal businesses like drugs. Liquor dealers used to shoot one another up just like drug dealers do now.
Except nobody called anybody, and your analogy has no relation.
I was making no analogy. I was explaining how the legality of an action can vary with the results. If you've got an issue with somebody else's post, maybe you should talk to them instead.
The effect of your action matters. If I call you once, it's legal. If I call you thirty times a day just to be a dick, it's harrassment. And if I ask 30 friends to call you once a day, it still should be harrassment.
There isn't much that you can do when the customer is uncooperative and doesn't want to get involved or admit their ignorance.
I wouldn't go that far.
Often during a planning session I have trouble getting customers engaged. We'll come up with a stack of index cards, one per feature. I'll say, "Now just put them in order by importance and we'll start working at the top." They will say, "But they're all really important!"
Here's where the trick comes in. I look through the stack, pull out the most retarded item and say, "Oh, this looks fun to build. We'll have this ready for you next week to show to your bosses." They have a quick vision of showing something useless to the higher-ups, squawk like a rooster and say, "No! No! Do this one first," pulling out something that is actually important.
Then, a few days later we'll show them the first version. They'll say, "No, that's not what I meant at all! What I really meant is X." Then we're off and running. They're engaged in the process, and we're all talking regularly about what they want.
The magic comes from tightening the feedback loops as much as possible so that confusion get squashed quickly. Nobody minds 30 seconds of misunderstanding. It's when you stretch that out to six months of development time that people start looking up the definition of justifiable homicide.
Why are MS's policies and strategies always based around "enemy lists" rather than actual products or services?
It's a hardware problem.
One of the most interesting questions out there is, "Why did humans get so smart?" There are a number of plausible answers, and the truth probably involves several of them. But one that I think is probably a big contributor is an arms race competing with other humans for social advantage.
If evolution was driven by that, it could bias the hardware so that some people are more inclined to see things in those terms. For example, people might treat non-human things like trees, animals, and thunder as if they were people. They would find it easier to solve abstract problems when described in terms of people. And they would treat situations as tribal wars, even when you could look at them in other ways.
For some of these, there's good evidence of hardware bias. For example, if you take an abstract logic question and turn it into a question of figuring out who's cheating, people are much better at solving the latter. I assume that Bill's problem is a similar one: he's got a lot of hardware for playing zero-sum games, and consequently has a hard time playing positive-sum games.
Google and MS are software companies. All they need is a few programmers to write some software, and they can duplicate that software and minimal cost and sell it millions of times over.
Close, but wrong.
Microsoft is a software business.
IBM sells services. Humans do the work.
Google also sells services, but servers do most of the work.
Is there any reason to think that there's a correlation between who he says is the biggest threat and who he thinks is the biggest threat? I can see a lot of reasons to lie about this.
Like I said before, it's more a scale issue: filesystems don't handle large quantities of files and directories with tiny dataums very well.
Older unix filesystems don't handle this well either, but somehow/etc and ~/.foo still work. Curious, eh?
RegSaveKey [...] Remote Registry service [...] write your own search prog [...] regedit [...] export to a text reg and diff those
Yes, you're proving my point here. The introduction of a custom database format requires people to reinvent tools or bridge to old ones, and requires a whole set of registry-specific knowledge to get things done. Sometimes that's worth it (e.g., SQL databases) but it's a heavy, heavy cost.
Inline commenting vs external help is a matter of style.
That's demonstrably wrong in that it suggests the two are functionally equivalent. It's like saying that uncommented code is just as good as commented code as long as there are some external docs. Except help files are even worse in that they can't be easily maintained by people managing the configs. Apache and Postfix both have excellent external help, but they still heavily use configuration comments, and good sysadmins add in even more.
Windows already doesn't have a versioning filesystem (like VMS does), so any versioning system would have to be your own implmentation, registry or filesystem.
Also incorrect. For unix setups, I can (and do) use RCS, CVS, or SVN to manage config files. (As well as cp, rsync, and tar, of course.) Because the configuration files are text, I get a lot of configuration management functionality for free that has to be reinvented with proprietary binary formats.
Curious how Jobs being buddhist, he is responsible for such slavering of desire (according to the above, amongst the 'ignorant') in the products he works to create. I wonder if he tries to reconcile this in some consumerist branch of Buddhism.
I think the really serious Buddhists are working at other consumer products companies. Why? Because their stuff is crappy enough that their only possible goal is to help you realize the hollowness of desiring after material things. Best Buy is practically a Buddhist temple: every time I go in there I learn how completely stupid my urge to make impulse purchases is.
What an idiot. Look at the carnage afterwards. Nevermind the few people that lost their jobs, tragic as that is, the real damage is the money from pension and investment funds that was squandered. That is people having their entire retirement thrown away.
Prudent investors did fine: the tech stocks as a whole did reasonably well. The people who got burned were people who ignored basic rules of investing. If you lost your entire retirement fund, there was negligence involved. Probably your own.
Which is of course why those who hold The Market up as if were the sacrosanct invisible hand of God ought to be taken out and shot. It demotes human society to barbarism, with no regard for the better aspects of human nature: the capacity for compassion, cooperation, and reason. I'm not advocating communism, because that has its own problems, but deifying The Market to justify whatever it does is definitely not the answer.
I agree that the people who deify The Market are idiots; I think of them as fundamentalist capitalists, and they're just as annoying as any other kind of fundie. Personally, I think markets are a really useful tool for solving certain problems. In the same way that digitization can make tractable a lot of ugly analog problems, casting things in market terms make a host of problems easier. But as with computers, some people treat markets as a magic wand rather than a tool with particular requirements and limitations.
That said, I think at the same time you reject some of their notions, you're implicitly buying into others. Fundamentalist capitalists are making the same mistake that the social darwinists made. First, they take the obvious features from a first analysis: commerce is war; evolution is survival of the fittest. Then, they commit the naturalistic fallacy and say that because that's how something is, that's how we should act.
You've identified the latter part as wrong, of course. Just because nature is red in tooth and claw doesn't mean we should be. But the first part is wrong as well. War is a natural condition, but cooperation is equally natural, and much more common. The problem is that cooperation is a much more subtle phenomenon: we understood the nature-as-warfare bit early on, but it wasn't until Axelrod's work in the 80s that we had a framework for understanding why cooperation is so widespread in nature. And as with evolution, so with commerce: simpleminded people focus on the zero-sum fights, when most of the value is actually in the positive-sum cooperative interactions.
Playing the stock market is like every other form of gambling: The house always wins. You lose.
I do not believe that I have seen such a completely misleading and or misinformed statement in a very long time. If you have no idea what you are doing, yeah, you could get burned. If you are smart, do your research and invest wisely, such as by diversifying, you can come out pretty darn well.
Investing is entirely different than "playing the stock market". You guys are both right. You can use your brokerage account to invest or to gamble. During the internet boom, most of the tech investors and day traders were gambling, not investing.
Slashdot Mirror
Given that I'm a flaming atheist, this will sound weird. However, I disagree.
I think science is about explaining how things are, not why they are or what we should do about it. Philosophy gives you a set of tools for approaching those questions and has a lot of interesting historical information on what people have said. But there's no right answer to many of philosophy's most interesting questions. For many people, they get those answers from one religion or another.
There is also an area that religion addresses that philosophy and science don't address at all: the lived experience of humankind, especially what many would call the spiritual side of things. Some Buddhist schools, for example, have nothing to say about gods or devils but a lot to say about how to live one's life in accordance with particular beliefs, like The Four Noble Truths and The Eightfold Path. Consider this quote:
You'd think some monk or preacher said that. Turns out, it was Albert Einstein.
I was just saying it's a pretty vague and unsupported off-the-cuff remark, rather than a scientific description, and thus incongruous in a story about hard science.
Sorry I misunderstood your point.
A scientist's motivations for doing science should not be held to the same standard of rigor that the science is. There are perfectly good scientists who do their work to, as they see it, reveal the greater glory of God. There's plenty of "vague and unsupported" in there, but I say that doesn't matter as long as the work is solid.
As to the incongruity, pop science articles regularly contain human interest hooks, so as to get people more involved in the topic. If you want your science straight up, perhaps Yahoo News isn't the best place for you to start.
Sure, for many in the creationist camp, science and God have no business mixing. But there are also those who believe as I do. Why do God and Science have to be mutually exclusive?
For me personally, it was the years of verbal harrassment I, a geeky kid, endured at the hands of Christians who seemed convinced that the main point of science was to kill and eat their precious Baby Jesus.
Now I'm mostly over it, and can actually have civilized discussions about relgion with my Christian friends. But for years I was implacably hostile to all things Christian, a flaming athiest with a grudge like a wasp-stung rhino. Now I generally save my ire for people like Pat "the gays caused 9/11" Robertson, and the creationist^W intelligent design loons who want to use political power to force their religion into science textbooks.
So putting it biblically, I'd say it's a case of, "whatsoever a man soweth, that shall he also reap". Perhaps if you're looking for more respect from pepole wearing lab coats, you could start by asking your co-religionists to practice what they're preaching about tolerance, humility, and love of their fellow man. Even unto the scientists.
So Altshuler claims, without any supporting evidence, that unnamed "people" in the undefined "ID community" make a big deal out of the unknowability of bee flight mechanics, and that having disproved this unkowability, he's successfully countered their alleged arugment?
I have personally heard this canard repeatedly from creationists. They will do it with pretty much anything that science doesn't have a ready answer to at the time. The bee one was popular because for a while it was a well-known unsolved problem that Bubba Sixpack could readily understand.
Now, of course, they've switched sides on this one. Before, the mystery of bee flight was proof of God's majestic inscrutability. Now that we've scruted it, it's proof of how darned smart God is.
For creationism to be "right" it needs to, for once, generate a testable, disproveable hypothesis and stop falling back on the old "anything we can't explain is God's will" argument.
Interestingly, this is not only bad science, it's bad theology. It's know as the "God of the gaps" problem, and it sets up a false conflict between science and religion. Just because we understand something doesn't make it any less wonderful.
I would love to see posts like this once a month or so! How about it?
Any given method should have more than one test case; any given class could have dozens.
On my projects the last few years, it's about 50% test code, 50% production code. I'd guess it's less than one test method per method under test. Not too bad to read.
Are you honestly suggesting that it's better to read and analyze all of that test code to determine what a method is and how it works -- i.e. the general context surrounding it -- rather than a simple paragraph or two in english?
I'm saying that it should already be pretty clear what a given class or method does by virtue of the design: package names, object names, object members, method names, parameter types and names, and relative relationships among all those. Failing that, I'll look at the code. When that's not clear or I suspect a bug, I go to the test cases. All of which should be written in a readable way; not a lot of analysis should be needed. Failing all of that, documentation is swell. It's great, for example, for a high-level overview document with, say, one page per 20-50 kloc to let new arrivals know the broad structure.
What you may miss if you haven't done it is that doing test-driven development forces much cleaner code. For example, I regularly see oversized methods in shops that think documentation is the only solution, but I've rarely see them in a test-driven team. It's just too hard to test. TDD also forces developers to look at their objects from the outside, yielding cleaner APIs. Once you've got 100% test coverage and have done all the refactoring you think necessary, there just isn't a lot of need for comments: 99% of the interesting information is already expressed.
Of course, it's possible that a bad programmer will make tests that are unclear, just as it's possible that they're bad writers who will make useless documentation. But if I have to bet, I'll bet on the tests, because a) they're more likely to have one skill (coding) than two (coding and writing); b) the compiler and testing framework force some semantic rigor and verify accuracy; and c) I can use coverage tools to figure out which tests really cover which code.
As for drift, you forget that refactoring is a part of test-driven development; test case code drifts just as much as API documentation can.
Not even close. Tests can be automatically verified by the computer. A human has to manually review all related documentation every time the code changes. On my projects, every time code is checked in all the tests are run. How often do you check all your docs for accuracy?
Of course, readability is still a potential problem, which is why I prefer pair programming or code reviews.
Do you like to chew tinfoil? Do you like to roll around on broken glass?
Actually, when I'm feeling masochistic, I try to have serious discussions with condescending blowhards on Slashdot. How about you?
The answer (40 years of experience with this) is not to set a standard on how much commenting is needed; it's to have walk-throughs of the code with an intelligent reader who isn't directly involved with the code. If they can read and understand the code, it's enough.
Yes! The only way to be sure that other people can understand the code is to have other people try to understand the code.
I prefer to do this with pair programming and frequent pair rotation, but inspections are ok, too.
And here is one of the reasons the agile method people get so much wrong. Automatic tests are not documentation, by any means. They do not prove that code is correct, or bug free. [...] Automatic tests have their place, but they are not equal to design or documentation. Any place that uses them as such is producing shitty software which will bite them on the ass when the original devs leave.
I note that documentation also doesn't prove that the code is correct or bug free. Tests at least prove that certain functionality is present and that certain bugs are absent. To get good design, correct code, and low bug count, you need other practices, like frequent deployment, frequent inspections, and common code ownership.
You should also consider that both tests and documentation can be written well or poorly. For both, it's only the well-written sort that is useful to those who come later. If I have a choice between code with tests but no docs or docs but no tests, I'll always take the code with the test suite.
Even if you're the best normalizer/refactorer (is "refactorer" a word?) in the world, you had better explain what a function or method or class or aspect or (etc..) does, how it's used, and what the expected results are, or you have made code that is a nightmare to maintain.
For what it does, that's what names are for. For how it's used and what the expected results are, that's what test cases are for. And the big advantage of test cases is that a computer can tell if they're still valid; comments are prone to drift.
Still, those 30 friends should bear most (possibly all) of the responsibility, since they're the ones actually calling me.
I don't see it that way. The friends may or may not have any intent to harrass. But the person orchestrating them sure does.
The analogy's especially clear with more dramatic crimes. A drug kingpin may never actually touch the drugs; in fact, drug gangs often use throwaway people at the low levels to insulate themselves. Low-level soliders are generally not the ones held responsible for war crimes. And more mundanely, the people who did the actual changing of the numbers at Enron aren't the ones the government is after. Indeed, they may have been innocent of criminal liability, acting in good faith based on what their corrupt bosses told them. But in all of these, the bosses are rightly seen as the most serious criminals.
Either way, taking you (or them) to court isn't going to resolve any personal differences between us. We'd both be better off if I found out why you had all your friends try to annoy me, and fixed that instead. If it can't be fixed (which is quite rare), I can always stop answering the phone. Jumping straight to coercion (e.g. lawsuits) is how wars get started...
That's ridiculous.
I agree that calling the law should be a matter of last resort, and I think the prosecutor and the school here are acting like idiots. But people have a right to be free of harrassment, and the reason we have a court system with powers to convict people of crimes and to issue restraining orders is to guard that freedom, and to give people an alternative to taking things into their own hands.
Wars get started because people fail to use the legal system or don't have an effective one available. That's why violence is such a problem in illegal businesses like drugs. Liquor dealers used to shoot one another up just like drug dealers do now.
Except nobody called anybody, and your analogy has no relation.
I was making no analogy. I was explaining how the legality of an action can vary with the results. If you've got an issue with somebody else's post, maybe you should talk to them instead.
How can it be a felony to incite lawful action?
The effect of your action matters. If I call you once, it's legal. If I call you thirty times a day just to be a dick, it's harrassment. And if I ask 30 friends to call you once a day, it still should be harrassment.
There isn't much that you can do when the customer is uncooperative and doesn't want to get involved or admit their ignorance.
I wouldn't go that far.
Often during a planning session I have trouble getting customers engaged. We'll come up with a stack of index cards, one per feature. I'll say, "Now just put them in order by importance and we'll start working at the top." They will say, "But they're all really important!"
Here's where the trick comes in. I look through the stack, pull out the most retarded item and say, "Oh, this looks fun to build. We'll have this ready for you next week to show to your bosses." They have a quick vision of showing something useless to the higher-ups, squawk like a rooster and say, "No! No! Do this one first," pulling out something that is actually important.
Then, a few days later we'll show them the first version. They'll say, "No, that's not what I meant at all! What I really meant is X." Then we're off and running. They're engaged in the process, and we're all talking regularly about what they want.
The magic comes from tightening the feedback loops as much as possible so that confusion get squashed quickly. Nobody minds 30 seconds of misunderstanding. It's when you stretch that out to six months of development time that people start looking up the definition of justifiable homicide.
High Speed, Low Cost, High Quality. Pick 2 out of 3.
And that's only if you're very lucky. There are a lot of projects that get none of those. Often because they were trying to get 3 out of 3.
What they really meant was "we can't hire competent people at the same prices as Jimmy the mounth-breather." Take that as you will.
They may also mean, "I am not smart enough to tell the difference between competent people and mouth breathers during interviews."
Why are MS's policies and strategies always based around "enemy lists" rather than actual products or services?
It's a hardware problem.
One of the most interesting questions out there is, "Why did humans get so smart?" There are a number of plausible answers, and the truth probably involves several of them. But one that I think is probably a big contributor is an arms race competing with other humans for social advantage.
If evolution was driven by that, it could bias the hardware so that some people are more inclined to see things in those terms. For example, people might treat non-human things like trees, animals, and thunder as if they were people. They would find it easier to solve abstract problems when described in terms of people. And they would treat situations as tribal wars, even when you could look at them in other ways.
For some of these, there's good evidence of hardware bias. For example, if you take an abstract logic question and turn it into a question of figuring out who's cheating, people are much better at solving the latter. I assume that Bill's problem is a similar one: he's got a lot of hardware for playing zero-sum games, and consequently has a hard time playing positive-sum games.
Google and MS are software companies. All they need is a few programmers to write some software, and they can duplicate that software and minimal cost and sell it millions of times over.
Close, but wrong.
Microsoft is a software business.
IBM sells services. Humans do the work.
Google also sells services, but servers do most of the work.
Is there any reason to think that there's a correlation between who he says is the biggest threat and who he thinks is the biggest threat? I can see a lot of reasons to lie about this.
I wonder how hard it would be to write a FS driver that would wrap the underlying registry up in a file like interface.
Interesting! That's a great idea, and what they should have done all along.
Like I said before, it's more a scale issue: filesystems don't handle large quantities of files and directories with tiny dataums very well.
/etc and ~/.foo still work. Curious, eh?
Older unix filesystems don't handle this well either, but somehow
RegSaveKey [...] Remote Registry service [...] write your own search prog [...] regedit [...] export to a text reg and diff those
Yes, you're proving my point here. The introduction of a custom database format requires people to reinvent tools or bridge to old ones, and requires a whole set of registry-specific knowledge to get things done. Sometimes that's worth it (e.g., SQL databases) but it's a heavy, heavy cost.
Inline commenting vs external help is a matter of style.
That's demonstrably wrong in that it suggests the two are functionally equivalent. It's like saying that uncommented code is just as good as commented code as long as there are some external docs. Except help files are even worse in that they can't be easily maintained by people managing the configs. Apache and Postfix both have excellent external help, but they still heavily use configuration comments, and good sysadmins add in even more.
Windows already doesn't have a versioning filesystem (like VMS does), so any versioning system would have to be your own implmentation, registry or filesystem.
Also incorrect. For unix setups, I can (and do) use RCS, CVS, or SVN to manage config files. (As well as cp, rsync, and tar, of course.) Because the configuration files are text, I get a lot of configuration management functionality for free that has to be reinvented with proprietary binary formats.
Curious how Jobs being buddhist, he is responsible for such slavering of desire (according to the above, amongst the 'ignorant') in the products he works to create. I wonder if he tries to reconcile this in some consumerist branch of Buddhism.
I think the really serious Buddhists are working at other consumer products companies. Why? Because their stuff is crappy enough that their only possible goal is to help you realize the hollowness of desiring after material things. Best Buy is practically a Buddhist temple: every time I go in there I learn how completely stupid my urge to make impulse purchases is.
What an idiot. Look at the carnage afterwards. Nevermind the few people that lost their jobs, tragic as that is, the real damage is the money from pension and investment funds that was squandered. That is people having their entire retirement thrown away.
Prudent investors did fine: the tech stocks as a whole did reasonably well. The people who got burned were people who ignored basic rules of investing. If you lost your entire retirement fund, there was negligence involved. Probably your own.
Which is of course why those who hold The Market up as if were the sacrosanct invisible hand of God ought to be taken out and shot. It demotes human society to barbarism, with no regard for the better aspects of human nature: the capacity for compassion, cooperation, and reason. I'm not advocating communism, because that has its own problems, but deifying The Market to justify whatever it does is definitely not the answer.
I agree that the people who deify The Market are idiots; I think of them as fundamentalist capitalists, and they're just as annoying as any other kind of fundie. Personally, I think markets are a really useful tool for solving certain problems. In the same way that digitization can make tractable a lot of ugly analog problems, casting things in market terms make a host of problems easier. But as with computers, some people treat markets as a magic wand rather than a tool with particular requirements and limitations.
That said, I think at the same time you reject some of their notions, you're implicitly buying into others. Fundamentalist capitalists are making the same mistake that the social darwinists made. First, they take the obvious features from a first analysis: commerce is war; evolution is survival of the fittest. Then, they commit the naturalistic fallacy and say that because that's how something is, that's how we should act.
You've identified the latter part as wrong, of course. Just because nature is red in tooth and claw doesn't mean we should be. But the first part is wrong as well. War is a natural condition, but cooperation is equally natural, and much more common. The problem is that cooperation is a much more subtle phenomenon: we understood the nature-as-warfare bit early on, but it wasn't until Axelrod's work in the 80s that we had a framework for understanding why cooperation is so widespread in nature. And as with evolution, so with commerce: simpleminded people focus on the zero-sum fights, when most of the value is actually in the positive-sum cooperative interactions.
Investing is entirely different than "playing the stock market". You guys are both right. You can use your brokerage account to invest or to gamble. During the internet boom, most of the tech investors and day traders were gambling, not investing.