Not sure if I'm being trolled at this point, but here goes...
OP commented that the value of unfettered information exchange and knowledge access to society is high, and thus it would be good for society if Wikipedia continued to be made available to all without a monetary charge. You asked: who would pay the dollar cost of Wikipedia operation? I answered that the dollar cost of Wikipedia is low enough that this is probably not an issue. I presumed that it can continue to be funded in the same way other public services are: through some combination of taxpayer funding, corporate benevolence, and personal charity.
I'm not sure where "the legal right to free beer" comes into it. Much less pejoratives and haranguing. Certainly your comments could be taken as an argument to stop taxpayer funding of public libraries: something that both OP and I would strongly object to.
Notice that I carefully avoided the word "free" in the first paragraph, also "right". Both of these are pretty loaded and confusing terms. When you get rid of them, arguments get a lot easier to understand. Hopefully, this is what we both want.
The difference being that Wikipedia, a huge worldwide resource, costs substantially less to run annually than the public library in the small Oregon town I grew up in.
Most any state or national government could afford to contribute $50-$100K of tax money every year to keep Wikipedia up, and would barely notice it. Google can afford to do the same. It's not free, but it's so close relative to its value that it makes no difference.
With piracy resulting in only 4% loss, why are the studios making such a big deal?
Because double-layer DVD-Rs are just now hitting the market seriously. DL DVD-Rs have the same storage capacity as commercial DVDs, allowing them to be ripped directly rather than transcoded. DL media is currently $5-$10 per, which makes ripping not competitive with renting. In a few months we can expect to start seeing $1 media for the now-$100 DL burners: this is the MPAA's nightmare.
In the longer term, home network bandwidth costs are still plummeting. I'm up to 1.5Mbps/1Mbps on my cheap home link. When bandwidths like these and larger become widespread, the other shoe drops. Then MPAA finds itself in a position that in many ways is worse than the current RIAA position. It is much harder for MPAA to cut the cost of content production to establish a competitive position. Also, paid movie performances (movie theatres) are struggling in a way that paid music performances (concerts) are not.
I'd be grasping at straws like Macrovision too.../p
Keep in mind that Microsoft is also the deepest-pocket target for every crank with their own crazy patent. I know of several cases in the past few years where Microsoft spent a lot of money defending themselves in infringement suits against completely frivolous patents. Be glad that these patents were trashed, and hope that's how Microsoft continues to do its patent litigation.
The example that always cracked me up here is that of Ben & Jerry's. The Vermont ice cream company abandoned a long-standing rule that capped the highest salary in the company at no more than 7 times the lowest salary. The reason given for the change was that they couldn't hire a top-quality CEO for a salary around $120K/year.
A couple of years after hiring their new deluxe-model CEO, they sold out to Unilever, with their sales flattened out and profits considerably reduced.
The light itself is a very expensive component of the lighthouse. Extremely high-output light source plus extremely large optics = extreme maintenance costs. Keeping the lighthouse station open for the tasks you mention makes a lot of sense. Keeping the light running perhaps less so. Very few of the lighthouses on the Oregon Coast actually run the lights any more. No one I know seems to miss them much.
Amusing footnote I just remembered: my Uncle owned a commercial fishing boat in the early 70s and used to navigate by triangulating AM radio stations with a transistor radio and directional loop antenna. Actually worked really well: in particular, there was almost always a radio station somewhere in the small fishing towns he was visiting that would take him right up to the bar. Of course, cheap LORAN was a dramatic improvement...
When I was commercial fishing on the Oregon Coast in the early 1980s, it was quite rare for a commercial boat above about 20' not to have both radar and LORAN. Our family's certainly did: I have to say that we never paid attention to lighthouses. Blinking nav buoys, sure, but lighthouses? If it was dark, and the weather was bad, and you saw the lighthouse, you were probably already way too close to trouble:-).
On the Oregon Coast, most commercial fishing boats above about 20' have had radar since the mid-80s. It's not as cheap as GPS, typically costing around $1K-$2K for low-end models. On the other hand, it's somewhat more useful: you can see in the fog with it. This helps you avoid mobile obstacles, particularly other boats.
The death of lighthouses really started with the growth of LORAN. My family's 40' commercial boat got LORAN in the same time frame as marine radar. The combination made navigation in bad weather conditions highly reliable.
Dongles, friend: dongles. I worry way less about some idiot stealing my authentication device (e.g. credit card) than my car keys. Do you really have information so sensitive that cyber bad guys will track you down and steal your authenticator to get it?
The right answer IMHO, and one that I've been advocating and in fact using for years, is to augment "something you know" with "something you have". Really, the other way around, in fact. If you think about it, almost all of our one-factor authenticators are of the "have" variety: keys, tickets, etc.
The coolest thing about this is that it can be done with no changes to existing (modern i.e. handles long passwords) password systems! Generate a 16-character randomized, unmemorizable password and write it down. Append a four-character easily memorized "PIN" and use the resulting 20-character string as your authenticator. Unless someone steals your wallet and has the energy and skills to mount a dictionary attack, you're golden---except for the hassle of typing the password in each time.
Note that the public-key authentication used by SSH is just an extension of this scheme that avoids the writing down and typing in. I'd trust an SSH key protected by a "bad" memorized password over a "good" memorized password any day of the week...and do!
Again, I am not a Windows programmer, so I may have some of this wrong; the following represents my understanding. The MS debugger's visual interface is nice; it lets you quickly understand what threads are up, how they're related, and what their state is (whether they're running, and if not why not). Also, the Windows libraries are instrumented in such a way that they don't interfere with debugging.
We just got done ripping a whole bunch of threading out of something we were building on an old Linux box. (For complicated reasons---it's the flight computer for a rocket---upgrading the software would have been difficult.) It turns out ripping threads out was the right architectural decision anyhow:-), but what originally motivated it is that we couldn't debug through some code in the PThreads library.
I suspect that NGPThreads solves the system-level problem, and that once the thread-aware userspace code all uses it the infrastructure will be in place for decent debugging. But GUI-supported debugging in general has historically been pretty awful under Linux. And Java debugging is worse (again, unless they've fixed Eclipse or something). I honestly think that an IDE with a decent debugger and decent online referencing would bring a lot of Windows programmers over the fence quickly. Then we could argue whether that was a good thing:-).
Debugging. I'm a hardcore UNIX/Linux developer who never uses Windows, but I've watched folks do it, and I'm jealous of debuggers that handle threads properly, give integrated displays of state, and are easy to navigate. Maybe Eclipse is there now, but it wasn't 6 months ago when I last tried it. Nothing I'm aware of for C even comes close.
Of course, if you're going to be writing C++ against the APIs of mystery, you darn well better have a first-class debugger.
I thought the article was a good summary of a lot of important code formatting concepts. If I have a critique, it's that I saw nothing that hasn't been said before, and at greater depth. See e.g. McConnell's Code Complete for a discussion of most of the issues raised in this piece.
That said, anything that gets more exposure for these ideas increases the chances that I won't have to read so much FORTRAN-in-any-language. I view the article as a good thing.
The article asks "What good does it do you to have a cell phone and a PDA that can exchange data, if they are required by law to be powered off the moment you leave the country?"
Seems to me that it might still be a little useful, in spite of that limitation...
Yeah, here in Portland, Oregon I just got a free upgrade from Qwest: moved to 1.5Mbps/1Mbps from 640Kbps/256Kbps. And this is real bandwidth, all the time. With a cheap ISP I get basically zero terms-of-service restrictions. Can't see Comcast getting my business anytime soon.
You seem to have a marked lack of appreciation for the intelligence, knowledge, and experience of the folks behind XML. May you be cursed to use ASN.1 until your appreciation improves.
Yes, I've been fortunate in that I usually am involved with checking out folks for higher-level or more idiosyncratic positions. It's really tough when you're looking at a job that perhaps anyone could do well, and have many qualified-looking applicants for it.
About all I know to do is to concentrate on the ability to write a resume that communicates well. While I haven't studied it formally, anecdotally this skill seems to be correlated with interpersonal and communications skill in general. One of the beauties of the theory of IQ is that folks who are really "smart", i.e. creative and effective, have been shown to also usually have that sort of non-technical skills.
It's hard for me to imagine your hiring situation, but easy to sympathize:-).
In a recent job interview process for a company I was consulting for, I was handed a stack of the top 100 or so resumes out of about 500 for an application. I asked for the other 400, and re-scavenged them myself, keeping track of which pile I'd pulled from. The net result was that none of the three finalists from the position were in the company's original top 100 IIRC, and the person hired definitely was not.
Of course, I have no hard-and-fast guidelines for which resumes to filter out. I find that I can scan about 50-100 resumes per hour on a first cut, and reproduce this cut fairly accurately later if need be. I figure that the 10-20 hours to review 1000 resumes to this level will pay for the company over the succeeding few years pretty handsomely if it produces any improvement at all in the expected caliber of hire. Of course, if I ever had to deal with 10,000 applications, the tradeoff would get more complicated...
As a practicing software engineer and computer science professor (can too be both!) I'd suggest you try the following experiment:
Take a pile of resumes and filter them using your method. Then take a photocopy of the same pile of resumes, throw out everything below 2.5 GPA, and randomly select the same number of resumes your method selected. Mark the resulting piles of candidates with a random word, and hand them to one more more colleagues, explaining that you're running a blinded experiment. See if they can discern any difference in quality between the piles, and if so, which one is better.
My guess is that you'll find out that there's little measurable difference. But however it comes out, at least you won't just be fooling yourself about the validity of your method.
Sounds like you and I are in more agreement than I originally would have thought.
My co-author and I chose to write up the Z and XCB work as a case study, for understanding Z, XCB, and how a formal method could be applied in a lightweight way to open source development. If there had been more room, we would have also included more material describing the development process and the effectiveness of the methodology.
One point of disagreement: you write that "'Case studies' of the kind you presented are useful for people to understand how something works, but not as evidence that something works better than something else. Yet, you have been trying to use it as the latter." I don't think I particularly have. I have argued, and still believe, that formal methods, specifically Z notation and formal reasoning, were in absolute terms useful to me in solving a particular open source development problem. I agree that any stronger claim is unjustified by our publication. I don't think anything you've said weakens this claim, though.
You write that "The claim that the use of formal methods by software developers may lead to higher quality software and/or lower development costs is a behavioral science claim." This appears to be correct. It is also a real problem: behavioral science claims are notoriously difficult to prove. Indeed, I think the evidence for any software development methodology I am aware of "leading to higher quality software and/or lowering development costs" tends to be fairly soft stuff at this point. I'm not convinced that the literature of e.g. Extreme Programming or the CMM really justifies broad claims of productivity or quality either.
This difficulty does not excuse the formal methodists from justifying their approach, of course. But it does suggest to me that there's something off about the use of behavioral science measures as the sole criterion for objective success of a software development technique. It is hard to imagine physicists, for example, arguing that calculus of variations needs behavioral studies to discover whether it is a more efficient method of solving problems in physics than numerical methods. Physicists use what works, and tend to figure out what works through experience rather than behavioral experiment. Maybe this isn't good enough for software development. But so far it has worked pretty well for me.
Slashdot Mirror
Not sure if I'm being trolled at this point, but here goes...
OP commented that the value of unfettered information exchange and knowledge access to society is high, and thus it would be good for society if Wikipedia continued to be made available to all without a monetary charge. You asked: who would pay the dollar cost of Wikipedia operation? I answered that the dollar cost of Wikipedia is low enough that this is probably not an issue. I presumed that it can continue to be funded in the same way other public services are: through some combination of taxpayer funding, corporate benevolence, and personal charity.
I'm not sure where "the legal right to free beer" comes into it. Much less pejoratives and haranguing. Certainly your comments could be taken as an argument to stop taxpayer funding of public libraries: something that both OP and I would strongly object to.
Notice that I carefully avoided the word "free" in the first paragraph, also "right". Both of these are pretty loaded and confusing terms. When you get rid of them, arguments get a lot easier to understand. Hopefully, this is what we both want.
The difference being that Wikipedia, a huge worldwide resource, costs substantially less to run annually than the public library in the small Oregon town I grew up in.
Most any state or national government could afford to contribute $50-$100K of tax money every year to keep Wikipedia up, and would barely notice it. Google can afford to do the same. It's not free, but it's so close relative to its value that it makes no difference.
With piracy resulting in only 4% loss, why are the studios making such a big deal?
Because double-layer DVD-Rs are just now hitting the market seriously. DL DVD-Rs have the same storage capacity as commercial DVDs, allowing them to be ripped directly rather than transcoded. DL media is currently $5-$10 per, which makes ripping not competitive with renting. In a few months we can expect to start seeing $1 media for the now-$100 DL burners: this is the MPAA's nightmare.
In the longer term, home network bandwidth costs are still plummeting. I'm up to 1.5Mbps/1Mbps on my cheap home link. When bandwidths like these and larger become widespread, the other shoe drops. Then MPAA finds itself in a position that in many ways is worse than the current RIAA position. It is much harder for MPAA to cut the cost of content production to establish a competitive position. Also, paid movie performances (movie theatres) are struggling in a way that paid music performances (concerts) are not.
I'd be grasping at straws like Macrovision too.../p
You payed $500 for textbooks for a single course? In 1989?
Keep in mind that Microsoft is also the deepest-pocket target for every crank with their own crazy patent. I know of several cases in the past few years where Microsoft spent a lot of money defending themselves in infringement suits against completely frivolous patents. Be glad that these patents were trashed, and hope that's how Microsoft continues to do its patent litigation.
The example that always cracked me up here is that of Ben & Jerry's. The Vermont ice cream company abandoned a long-standing rule that capped the highest salary in the company at no more than 7 times the lowest salary. The reason given for the change was that they couldn't hire a top-quality CEO for a salary around $120K/year.
A couple of years after hiring their new deluxe-model CEO, they sold out to Unilever, with their sales flattened out and profits considerably reduced.
Huh. Might have guessed. The light source itself is probably still quite expensive, but by itself shouldn't be prohibitive.
Thanks much for the update!
The light itself is a very expensive component of the lighthouse. Extremely high-output light source plus extremely large optics = extreme maintenance costs. Keeping the lighthouse station open for the tasks you mention makes a lot of sense. Keeping the light running perhaps less so. Very few of the lighthouses on the Oregon Coast actually run the lights any more. No one I know seems to miss them much.
Amusing footnote I just remembered: my Uncle owned a commercial fishing boat in the early 70s and used to navigate by triangulating AM radio stations with a transistor radio and directional loop antenna. Actually worked really well: in particular, there was almost always a radio station somewhere in the small fishing towns he was visiting that would take him right up to the bar. Of course, cheap LORAN was a dramatic improvement...
When I was commercial fishing on the Oregon Coast in the early 1980s, it was quite rare for a commercial boat above about 20' not to have both radar and LORAN. Our family's certainly did: I have to say that we never paid attention to lighthouses. Blinking nav buoys, sure, but lighthouses? If it was dark, and the weather was bad, and you saw the lighthouse, you were probably already way too close to trouble :-).
On the Oregon Coast, most commercial fishing boats above about 20' have had radar since the mid-80s. It's not as cheap as GPS, typically costing around $1K-$2K for low-end models. On the other hand, it's somewhat more useful: you can see in the fog with it. This helps you avoid mobile obstacles, particularly other boats.
The death of lighthouses really started with the growth of LORAN. My family's 40' commercial boat got LORAN in the same time frame as marine radar. The combination made navigation in bad weather conditions highly reliable.
Thank goodness there's a processor in that thing. How else could it sense a DC voltage and light up an LED?
Ubergeeks are so cool...
Dongles, friend: dongles. I worry way less about some idiot stealing my authentication device (e.g. credit card) than my car keys. Do you really have information so sensitive that cyber bad guys will track you down and steal your authenticator to get it?
The right answer IMHO, and one that I've been advocating and in fact using for years, is to augment "something you know" with "something you have". Really, the other way around, in fact. If you think about it, almost all of our one-factor authenticators are of the "have" variety: keys, tickets, etc.
The coolest thing about this is that it can be done with no changes to existing (modern i.e. handles long passwords) password systems! Generate a 16-character randomized, unmemorizable password and write it down. Append a four-character easily memorized "PIN" and use the resulting 20-character string as your authenticator. Unless someone steals your wallet and has the energy and skills to mount a dictionary attack, you're golden---except for the hassle of typing the password in each time.
Note that the public-key authentication used by SSH is just an extension of this scheme that avoids the writing down and typing in. I'd trust an SSH key protected by a "bad" memorized password over a "good" memorized password any day of the week...and do!
Talking to a passenger isn't as distracting as talking on the cellphone, but it is certainly more distracting than not talking to anybody.
A lovely assertion. Highly scientifically testable. I'll believe it when I see the studies.
Again, I am not a Windows programmer, so I may have some of this wrong; the following represents my understanding. The MS debugger's visual interface is nice; it lets you quickly understand what threads are up, how they're related, and what their state is (whether they're running, and if not why not). Also, the Windows libraries are instrumented in such a way that they don't interfere with debugging.
We just got done ripping a whole bunch of threading out of something we were building on an old Linux box. (For complicated reasons---it's the flight computer for a rocket---upgrading the software would have been difficult.) It turns out ripping threads out was the right architectural decision anyhow :-), but what originally motivated it is that we couldn't debug through some code in the PThreads library.
I suspect that NGPThreads solves the system-level problem, and that once the thread-aware userspace code all uses it the infrastructure will be in place for decent debugging. But GUI-supported debugging in general has historically been pretty awful under Linux. And Java debugging is worse (again, unless they've fixed Eclipse or something). I honestly think that an IDE with a decent debugger and decent online referencing would bring a lot of Windows programmers over the fence quickly. Then we could argue whether that was a good thing :-).
Debugging. I'm a hardcore UNIX/Linux developer who never uses Windows, but I've watched folks do it, and I'm jealous of debuggers that handle threads properly, give integrated displays of state, and are easy to navigate. Maybe Eclipse is there now, but it wasn't 6 months ago when I last tried it. Nothing I'm aware of for C even comes close.
Of course, if you're going to be writing C++ against the APIs of mystery, you darn well better have a first-class debugger.
I thought the article was a good summary of a lot of important code formatting concepts. If I have a critique, it's that I saw nothing that hasn't been said before, and at greater depth. See e.g. McConnell's Code Complete for a discussion of most of the issues raised in this piece.
That said, anything that gets more exposure for these ideas increases the chances that I won't have to read so much FORTRAN-in-any-language. I view the article as a good thing.
The article asks "What good does it do you to have a cell phone and a PDA that can exchange data, if they are required by law to be powered off the moment you leave the country?"
Seems to me that it might still be a little useful, in spite of that limitation...
Yeah, here in Portland, Oregon I just got a free upgrade from Qwest: moved to 1.5Mbps/1Mbps from 640Kbps/256Kbps. And this is real bandwidth, all the time. With a cheap ISP I get basically zero terms-of-service restrictions. Can't see Comcast getting my business anytime soon.
You seem to have a marked lack of appreciation for the intelligence, knowledge, and experience of the folks behind XML. May you be cursed to use ASN.1 until your appreciation improves.
If they were located in the same place as our own Sun - at the centre of the Solar System...
So that's where I left it!
Yes, I've been fortunate in that I usually am involved with checking out folks for higher-level or more idiosyncratic positions. It's really tough when you're looking at a job that perhaps anyone could do well, and have many qualified-looking applicants for it.
About all I know to do is to concentrate on the ability to write a resume that communicates well. While I haven't studied it formally, anecdotally this skill seems to be correlated with interpersonal and communications skill in general. One of the beauties of the theory of IQ is that folks who are really "smart", i.e. creative and effective, have been shown to also usually have that sort of non-technical skills.
It's hard for me to imagine your hiring situation, but easy to sympathize :-).
I haven't tried this specific experiment.
In a recent job interview process for a company I was consulting for, I was handed a stack of the top 100 or so resumes out of about 500 for an application. I asked for the other 400, and re-scavenged them myself, keeping track of which pile I'd pulled from. The net result was that none of the three finalists from the position were in the company's original top 100 IIRC, and the person hired definitely was not.
Of course, I have no hard-and-fast guidelines for which resumes to filter out. I find that I can scan about 50-100 resumes per hour on a first cut, and reproduce this cut fairly accurately later if need be. I figure that the 10-20 hours to review 1000 resumes to this level will pay for the company over the succeeding few years pretty handsomely if it produces any improvement at all in the expected caliber of hire. Of course, if I ever had to deal with 10,000 applications, the tradeoff would get more complicated...
As a practicing software engineer and computer science professor (can too be both!) I'd suggest you try the following experiment:
Take a pile of resumes and filter them using your method. Then take a photocopy of the same pile of resumes, throw out everything below 2.5 GPA, and randomly select the same number of resumes your method selected. Mark the resulting piles of candidates with a random word, and hand them to one more more colleagues, explaining that you're running a blinded experiment. See if they can discern any difference in quality between the piles, and if so, which one is better.
My guess is that you'll find out that there's little measurable difference. But however it comes out, at least you won't just be fooling yourself about the validity of your method.
Sounds like you and I are in more agreement than I originally would have thought.
My co-author and I chose to write up the Z and XCB work as a case study, for understanding Z, XCB, and how a formal method could be applied in a lightweight way to open source development. If there had been more room, we would have also included more material describing the development process and the effectiveness of the methodology.
One point of disagreement: you write that "'Case studies' of the kind you presented are useful for people to understand how something works, but not as evidence that something works better than something else. Yet, you have been trying to use it as the latter." I don't think I particularly have. I have argued, and still believe, that formal methods, specifically Z notation and formal reasoning, were in absolute terms useful to me in solving a particular open source development problem. I agree that any stronger claim is unjustified by our publication. I don't think anything you've said weakens this claim, though.
You write that "The claim that the use of formal methods by software developers may lead to higher quality software and/or lower development costs is a behavioral science claim." This appears to be correct. It is also a real problem: behavioral science claims are notoriously difficult to prove. Indeed, I think the evidence for any software development methodology I am aware of "leading to higher quality software and/or lowering development costs" tends to be fairly soft stuff at this point. I'm not convinced that the literature of e.g. Extreme Programming or the CMM really justifies broad claims of productivity or quality either.
This difficulty does not excuse the formal methodists from justifying their approach, of course. But it does suggest to me that there's something off about the use of behavioral science measures as the sole criterion for objective success of a software development technique. It is hard to imagine physicists, for example, arguing that calculus of variations needs behavioral studies to discover whether it is a more efficient method of solving problems in physics than numerical methods. Physicists use what works, and tend to figure out what works through experience rather than behavioral experiment. Maybe this isn't good enough for software development. But so far it has worked pretty well for me.