This being the sort of place that it is, some people will probably not realize you're being sarcastic. It wouldn't hurt to add explicit markers so that people won't flame you for being an idiot.
much clearer syntax for things like instance variables (non of this execrable 'self' gunk that python forces upon you).
There's a reason for 'self' in Python, which is that if you don't distinguish local variables from instance variables then you can forget which something is, and then you either have to go hunting for the declaration or you risk getting yourself in trouble. Ruby acknowledges this by using '@', which is easier to tune out (which is dangerous) and contributes to the "line noise" appearance of the language (beloved of Perl weenies, loathed by real programmers) without actually adding anything compared to "self".
Python and Perl always feel like procedural scripting languages with some OO bolted on
While the object model in Python is less than complete, it's generally only noticeable in some edge cases, and objects are far from "bolted on". They've been there since Day One, and they're integral to the language despite their incompleteness.
That actually leads into a question: can you create dynamically-loaded modules containing first-class extension types in Ruby? The not-quite-first-class nature of Python's extension types has always bugged me quite a bit.
And iterators -- baby, they are the coolest
Yes, they are very cool, though I'm not as convinced as you seem to be that they always improve readability. I think in some cases they can have the opposite effect.
Ruby implements multiple-inheritance type stuff using "mixins."
Sorry, but there's really no complete substitute for true multiple inheritance. Yes, mixins or interfaces might be preferable in the vast majority of cases, but if you hit a case where MI is the right approach and it's not supported then that sucks. At least Java had the excuse that it's hard to reconcile MI with code mobility. It seems to me that a lot of language designers are inventing alternatives to MI as much to get out of the work of implementing it as for any other reason, and then trying to rationalize their choice after the fact with a wall of academic BS.
what do you think a supercomputer is? It is thousands of CPU clustered. Only difference is that a supercomputer is pre-packaged.
I beg to differ. One of the major things differentiating supercomputers from anything else is the presence of *huge* internal memory and I/O bandwidth. That will never be duplicated by a distributed group of machines, and so for a certain very large and important class of programs distributed computation will never be a substitute for supercomputers. Fortunately, there are enough problems out there that *do* partition very easily, so that distributed computing is still worthwhile.
I think one of the things people need to get straight in their heads wrt P2P is the difference between temporary and permanent roles. Obviously, if node A is always and forever a server, and node B is always and forever a client, and they're totally incapable of switching roles (e.g. neither even has the code to do so) then that's not P2P. Just as obviously, if there's not even a notion of client and server, if every node is necessarily able to perform in either role at any instant, that's about as P2P as you can get. (Note, however, that with respect to an individual transaction there is still one node acting as client/requester and another acting as server/responder).
The real battleground is the area in between, where a node may be a server one moment, or a client the next, changing according to the needs of the network (e.g. nodes entering and leaving). Is that P2P? The P2P purists ("peerier than thou", to use Dr. Shirky's term) would say no. More practical people would say yes, or close enough to yes that it doesn't matter. One trend that more and more people are noticing is that many P2P protocols/applications are developing ideas of "supernodes" or "reflectors" or "defenders" (my candidate for stupidest term yet) that, because of their superior resources, are given additional responsibilities. In other cases, certain functions have been partly or completely centralized within a mostly P2P framework, because nobody could figure out how to make that particular piece - usually a location, searching, or indexing piece - scale within a pure P2P paradigm.
The important thing about P2P is not "oh my god, there's a server, we must eliminate such heresy from our design!" What's important is decentralization and automatic reconfiguration, to avoid bottlenecks and single points of failure. Those are the problems we're trying to solve, remember? If the system is flexible so that work can be redistributed seamlessly from one place to handle either overload or failure, that's "P2P enough for me" even if a picture of the system at any one point in time shows some nodes in server roles and others in client roles. That generally means that each node must be capable of performing the different roles - i.e. the code must be present, the protocols must support it - but whether a given node actually does ever perform a given role doesn't matter.
One more idea which has not been implemented currently (or at least not on a large scale) is random connectivity. Every computer would be connected to about 16 others or so (I'm guessing at this) and theoretically you get all computers connected together, but with a formless topolgy. Routing would be quite difficult in this setup.
Difficult, but far from impossible. Mesh routing - which is really what you're talking about here - is a much-studied field and pretty reasonable solutions to all of the major problems are known. Check out Routing in the Internet by Christian Huitema for a pretty good overview of the relevant theory and practice.
IMO one of the big problems with P2P is that too many P2P implementors are either ignorant or disdainful of related work in this and other areas - usually both, which is a bad combination. I went to the O'Reilly P2P conference in SF a couple of months ago, and overall it was fantastic, but I did notice one thing. Everyone there seemed very sophisticated about crypto and security etc. but at the same time most were stunningly ignorant about routing, protocol design, performance management, and a bunch of other fields. There were exceptions, of course, don't get me wrong, but there's still way too much fad-following in the P2P community and not enough solid science or engineering.
That's fine, but I was quite deliberately only addressing the issue of users' choices. Issues surrounding MS's business, development, and standards-compliance processes are a whole different matter.
No, not limiting their choices. Putting a big warning sign on the preferences menu
I thought I was pretty explicit about why that's not sufficient. Something about newbies hitting the "expert mode" button, I believe. Then again, people hitting the "reply" button before they finish reading is a related phenomenon, so I should have expected that too.
Speaking as someone who flipped every switch in the software I could find when I was little
I'll bet that led to one of two outcomes. Either you sometimes managed to mess something up and learned to fix it (good for you!) or you messed it up and found someone else to fix it. In either case, you probably found that outcome pretty acceptable. Here's the crux: most people find neither acceptable. They'll just be pissed that it was ever possible for things to be rendered unusable by what they considered (rightly or not) to be innocent experimentation. Before you think they're being unfair, stop for a moment and ask yourself honestly whether you've ever had the same reaction. Have you really *never* said "I can't believe they didn't handle that properly" or cursed a sloppy programmer for not testing all the cases? Yeah, right. I'd wager a drink that you've even criticized *Microsoft products* for exactly those kind of failures, whether it's as a user or as an anti-MS zealot. Well, MS wants to avoid that. They're willing to take the hit for being too inflexible or dictatorial or whatever, in preference to being slammed for being flaky or counterintuitive or hard to configure. Again, it might not be *your* choice but it's a *valid* choice.
This seems to be the pervailing attitude among those at Microsoft and elsewhere: users are stupid, so stupid that we must make all their decisions for them.
Many - not all - users *are* stupid. Even many of the supposedly computer-savvy people on Slashdot are *frighteningly* stupid. Everyone in this field learns sooner or later that if you provide an option, some idiot will set it inappropriately. The world is full of newbies clicking the "expert mode" button. If you're providing products for millions of users, the vast majority of whom can barely handle anything more complicated than clicking on an icon, then limiting those users' choices seems like a pretty valid design decision.
There rarely is One Right Way
...unless it's your way, apparently. I hack kernels for a living, and I also *choose* to use MS products for some things. Are you, the champion of free choice, going to tell me my choice is invalid, that the products I prefer *shouldn't even be on the market* because they don't satisfy your desire for twiddling and tweaking? Yes, choice is good, and one valid choice is to *forego* certain other choices in the interests of getting on with life and getting things done. Windows users forego some choices, Linux users forego others. Live and let live.
First of all realize that the pair works together, they are not trying to get something past the other.
Ideally, yes, but reality does not always live up to our ideals. Let me guess, though: if the pair programming doesn't work the way we're told it should, then it's not really XP, right?
The other big benefit of pair programming is that two people know the code. So you can go on vacation and not worry that you'll get called to fix production problems...
Yes, that's a big benefit, but one not unique to pair programming. Before XP even existed, I once took a three-week vacation right in the middle of "crunch time", leaving a very complex piece of software (the central decision-making component of a high-availability clustering product) in a colleague's hands. How was I able to do this? It's simple. The component was sufficiently documented, commented, and accompanied by unit tests that the colleague was able to understand it, and none of that had squat to do with XP. It was just common sense and professionalism.
If we want to evaluate XP's merits vis a vis other methodologies, we need to consider the ways in which it differs from other methodologies. All this crap about "turning the dial to ten" and applying practices that were known twenty years ago to be beneficial gets us absolutely nowhere. The only aspects of XP that seem to be actual parts rather than prerequisites, and that are not already common knowledge, seem to be:
Attitudes about code ownership, including pair programming.
Very short "cycle times".
Frequent refactoring (the fancy name for rewriting).
So far, the arguments and evidence contrary to the XP approach in each of these areas seem at least as compelling as the arguments in favor. For example, the recognized goodness of modular decomposition is hard to reconcile with XP's attitude toward code ownership. XP's focus on short cycle times and refactoring, taking focus *away* from trying (trying, mind you) to get it right the first time, directly contradicts a huge body of evidence about what works and what doesn't on most types of projects. Yes, you should always plan to throw away the first version, but that doesn't mean it's even better to plan on throwing away the first seven or eight. I could go on, but I hope you see the point.
Many reasonable but negative comments and observations have been made about XP here. The answers from the XP proponents have so far been more evasive than convincing, mostly consisting of either "is so!" or "do all of this and magic will happen". Some of us don't believe in magic, and would prefer an actual explanation of how and why a reasonable person might expect practices that fly in the face of decades of software-engineering knowledge to work for non-toy projects.
Only the WEP attacks require computation, and even those are so trivial as to be not worth coding up except to fuel the script kiddies.
Wrong. You obviously missed this very important sentence at the end of section 5:
Only the WEP attacks require computation, and even those are so trivial as to be not worth coding up except to fuel the script kiddies
What's the significance of that? Well, we already knew that running an 802.11b network without WEP would be the act of a total moron. What the paper is saying is that *with* WEP you can attach to the network but you can't actually use it without the methods mentioned in the Borisov/Goldberg/Wagner paper. Those methods, in turn, are far from trivial. In fact, they're extremely difficult (but, admittedly, not impossible) to implement in the real world. In other words, nobody's network is actually likely to be compromised in this way. As another poster said, it's theoretically interesting, but of very little practical import.
If no one is watching, I'll get lazy, (do) cut-and-paste programming, no test writing, no re-factoring--the sort of anti-patterns that make software suck," Extreme programmer Lyle Hayhurst said via e-mail. "If someone is watching me, I'll probably feel guilty and do the right thing.
If that quote is accurate, then I'd say Lyle Hayhurst simply lacks self-discipline. Every bad habit he mentions is likely to catch up with him sooner or later. Which is better?
Sneak it in, hope nobody notices, get burned when it's a customer who notices.
Sneak it in, get caught in the code review.
Try to sneak it in, get caught by your code partner.
Discipline yourself not to do do something you know is bad in the first place.
#1 is obviously the worst case. #2 and #3 - standard methodology and XP respectively - are both improvements, and #4 is the best of all.
Is #3 better than #2? Maybe, maybe not. On the one hand, it avoids the necessity of going back and doing it again. On the other hand, think about which one helps programmers develop to #4. Getting caught in a code review and having to redo your work can be painful, but often the painful lessons are the ones best learned. I don't see that happening with #3. What I see happening instead is programmers relying on their partners to act as conscience instead of having a conscience of their own, "putting things past" less competent partners whenever they can, and generally not learning the lessons that help them get to #4.
BTW, this is only one example of how XP depends on programmers being of near-equal ability. Unfortunately, that just isn't the case in most of real life.
Isn't detecting CPU and internal system temperature already done at the BIOS level?
Perhaps the example was poorly chosen, or poorly worded. The problem mentioned is very real, though. Trying to distinguish between transient and permanent errors, HBA and device errors, or HW-RAID controller and actual-disk errors, is hard enough even when you have access to all of the available information - e.g. sense data for SCSI. I know this because I wrote one of the very first UNIX-based multi-path disk driver extensions, and nearly went insane dealing with this exact problem. Linux makes this problem even worse by basically throwing away most of the useful information at various points along the way from adapter driver to SCSI mid-layer to generic block-device layer, etc. I'm glad they're finally doing something about it.
Oh yeah? Check out HKCU\Software\Human\BodyParts\Boobs\Parameters, and you'll see a DWORD value for it. If you don't, you probably need to fix your registry, because several MS applications will crash if they can't find it.
I don't see Jesus accumulating wealth but I see Adam Smith doing it
Man, you really need to get off the shrooms and onto Prozac or something. Jesus and Adam Smith are both dead, and if you see either of them accumulating wealth you have a problem.
The probelm with a "take whatever you want" approach is that it gives other people take whatever portion of the bible they like and ignore the rest.
That's not a problem with religion. *People* tend to pick and choose their moral beliefs; non-religious people tend to be even more inconsistent and self-serving about it than religious people. Why should religious people be less free to choose their beliefs than non-religious people? Is the message here supposed to be "your ethics can be whatever you want, as long as they're not mandated by a religious authority"? Balls to that.
Just exacly what is the difference between believing that thetans are locked in your body and that an invisible, all powerful, omnicient man who lives in the sky caused a virgin to give birth?
Not much, really.
Sure christians like to disregard any part of the bible they don't like (which IMHO also gives me the right to ignore any part of the bible I don't like BTW) but you can not deny that they are a part and parcel of your religion.
I already pointed out that it's not my religion. Some of us are actually willing to defend people's right to hold viewpoints that differ from our own.
More importantly, why do you assume faith is an "all or nothing" thing? Sure, the Roman Catholics might present it that way, but many other branches of Christianity require little or nothing beyond belief in the existence of God[1]. To address your example, Unitarians in particular are famous for their acceptance of gay people. There's a pretty well established body of historical scholarship proving that much of what's in the Bible was politically rather than divinely inspired - particularly by Paul - leading to a natural questioning of how much credence it should really be given. Much of this knowledge and debate is filtering into the theological community, and is leading to a sort of "neo-Fundamentalism" that draws sharp distinctions between the words/teachings of Christ and other stuff that has been attached to those teachings by other people.
The point, at long last, is that religion is not an all-or-nothing thing. What objection do you have, for example, to someone who happens to believe in God and in salvation through Christ, but eschews sexist/xenophobic ranting by people like Paul or Augustine? What's your dispute with someone who, based on such a faith, exhibits forgiveness, charity, and other positive behaviors to a degree they otherwise might not? It is because the previous poster's broad brush would tar such people along with those who subscribe to the most twisted and harmful kinds of religious belief that I called his comments obnoxious.
If you want to criticize the behavior of religious people, that's fine. If you want to criticize specific religious beliefs as origins of those behaviors, that's fine too but I'd recommend a little caution. If you want to lambaste all religion everywhere, without regard for (or even familiarity with) how it actually affects people, I think you'll find many people like me leaving your side to stand shoulder to shoulder with people of faith.
[1] It's easier for me to limit my comments to Christianity due to familiarity, but that shouldn't be taken to imply that other religions don't have the same issues.
Y'know, you come off sounding every bit as self-righteous and narrow-minded as any preacher ever did.
your retort that 'but everything wonderful around you is a result of the beauty of Jesus and God'
But s/he never said that; the claim was that *some* of the good around us came from work inspired by or dedicated to religion - not all. Constructing strawmen won't help you deconstruct religion.
I know alot of people will consider this flamebait
Because it is. You might not be religious, religion - particularly the organized kind - might have its flaws, but using phrases like "mass hysteria" or "brainwashing" or "fantasy" to descibe *all* religion is just obnoxious.
you are going to believe it? You don't have to believe - do you - because you have faith. No reason - just faith.
And what's wrong with faith? Solipsism is a singularly useless philosophy, and for anything else you need faith in *something*. Even Descartes recognized as much in his Meditations of First Philosophy, and that's really basic stuff. You seem to have a lot of faith, if I may say so, in your own perceptions and reasoning, incomplete as those might be.
So, again, what's wrong with faith? I'm not asking what's wrong with the Scientologists, or the Catholic Church, or with things that people who have faith happen to do. What's wrong with faith in and of itself? Obviously if one's faith is contradicted by observation that's one thing, but is there anything wrong with believing something not contradicted by observation?
Im finished being afraid and guilty
Apparently you're not finished with being angry, though. The Church still seems to have quite a hold on you, if the mere mention of faith can cause you to have such a hissy fit.
Like you, I was brought up in a very religious environment. Like you, I broke away from it. Unlike you, I've learned to accept that what's right or wrong for me is not necessarily right or wrong for everyone, recognize that I have my own faith (even if it's not religious) and allow other people theirs.
I make every decision in my life for myself, I *own* all the consequences
And you always did. Religion doesn't change that; most don't even try.
It scares me to wonder what my 'thought' processes would have been like if I had not abandoned my indoctrination.
Here's some news: from where I sit, your thought processes don't look all that great. I've met many religious people who could construct a better argument for their POV than you have done, and then present it more persuasively. Maybe religion isn't to blame for any deficiency in thought processes, and lack of religion is no panacea.
Back in the really old days, DECnet would set the MAC address to a value simply derived from the DECnet address. If you couldn't set the MAC, you couldn't use DECnet.
Back in the old days, before the DMCA, there seemed to be strong concepts of "common carriers" and public forums. The basic idea was that if someone provided a "public" facility they could not be held responsible for how that facility was used. The definition of "public" was that there had to be absolutely no monitoring or censorship, and for that reason phone companies and large BBSes or conferencing systems were careful to avoid any such activities. As soon as they took any interest, basically, they also took responsibility.
I guess my question, which I was sort of hoping the article would answer, was whether the "safe harbors" of the DMCA were intended or interpreted to supplant or augment these older concepts. It seems to me that it supplants them, and sets a much higher standard for the facility owner/operator, but I'd appreciate it if anyone with better knowledge could clarify. It used to be that you could choose not to monitor or censor activity even if you had the technical means, publicize that choice, and be safe legally. Now it seems that you're left with no choice; the mere ability is enough and if you have the ability but choose not to exercise it that doesn't get you anything but trouble. Is that really the case?
Hardly a surprise. Laptops tend to incorporate a lot more vendor-specific hardware than desktops, and as a result tend to be much more of a pain for *any* OS. Comparing laptop installations to desktop installations is simply invalid.
Someone mentioned CalTech - sorry, I forgot the cid, but thank you - so I went and did a little digging. Here is a link to the CalTech Asynchronous VLSI group. Right on the page are some cogent explanations of why they believe asynchronous designs will eventually become commonplace. Further in are pointers to some good papers, and an interesting discussion of their results implementing an asynchronous version of the MIPS R3000 architecture.
To use a software analogy, how easy would it be to debug a program where half of the code consisted of conditional branches ?
A little bit of a pain, but far from impossible. Anyone who works on software for a multithreaded, multiprocessor, or distributed environment solves asynchrony-related problems all the time. We do it by having locks instead of clocks; hardware folks can do and on occasion have done just the same. I'm sorry to hear that such basically simple problems are considered unsolvable by garden-variety EEs.
Slashdot Mirror
This being the sort of place that it is, some people will probably not realize you're being sarcastic. It wouldn't hurt to add explicit markers so that people won't flame you for being an idiot.
There's a reason for 'self' in Python, which is that if you don't distinguish local variables from instance variables then you can forget which something is, and then you either have to go hunting for the declaration or you risk getting yourself in trouble. Ruby acknowledges this by using '@', which is easier to tune out (which is dangerous) and contributes to the "line noise" appearance of the language (beloved of Perl weenies, loathed by real programmers) without actually adding anything compared to "self".
While the object model in Python is less than complete, it's generally only noticeable in some edge cases, and objects are far from "bolted on". They've been there since Day One, and they're integral to the language despite their incompleteness.
That actually leads into a question: can you create dynamically-loaded modules containing first-class extension types in Ruby? The not-quite-first-class nature of Python's extension types has always bugged me quite a bit.
Yes, they are very cool, though I'm not as convinced as you seem to be that they always improve readability. I think in some cases they can have the opposite effect.
Sorry, but there's really no complete substitute for true multiple inheritance. Yes, mixins or interfaces might be preferable in the vast majority of cases, but if you hit a case where MI is the right approach and it's not supported then that sucks. At least Java had the excuse that it's hard to reconcile MI with code mobility. It seems to me that a lot of language designers are inventing alternatives to MI as much to get out of the work of implementing it as for any other reason, and then trying to rationalize their choice after the fact with a wall of academic BS.
What use of Python have you found that surprised you the most, that gave you the strongest "I can't believe they did that" reaction?
I beg to differ. One of the major things differentiating supercomputers from anything else is the presence of *huge* internal memory and I/O bandwidth. That will never be duplicated by a distributed group of machines, and so for a certain very large and important class of programs distributed computation will never be a substitute for supercomputers. Fortunately, there are enough problems out there that *do* partition very easily, so that distributed computing is still worthwhile.
That looks like a nice paper. Thanks!
I think one of the things people need to get straight in their heads wrt P2P is the difference between temporary and permanent roles. Obviously, if node A is always and forever a server, and node B is always and forever a client, and they're totally incapable of switching roles (e.g. neither even has the code to do so) then that's not P2P. Just as obviously, if there's not even a notion of client and server, if every node is necessarily able to perform in either role at any instant, that's about as P2P as you can get. (Note, however, that with respect to an individual transaction there is still one node acting as client/requester and another acting as server/responder).
The real battleground is the area in between, where a node may be a server one moment, or a client the next, changing according to the needs of the network (e.g. nodes entering and leaving). Is that P2P? The P2P purists ("peerier than thou", to use Dr. Shirky's term) would say no. More practical people would say yes, or close enough to yes that it doesn't matter. One trend that more and more people are noticing is that many P2P protocols/applications are developing ideas of "supernodes" or "reflectors" or "defenders" (my candidate for stupidest term yet) that, because of their superior resources, are given additional responsibilities. In other cases, certain functions have been partly or completely centralized within a mostly P2P framework, because nobody could figure out how to make that particular piece - usually a location, searching, or indexing piece - scale within a pure P2P paradigm.
The important thing about P2P is not "oh my god, there's a server, we must eliminate such heresy from our design!" What's important is decentralization and automatic reconfiguration, to avoid bottlenecks and single points of failure. Those are the problems we're trying to solve, remember? If the system is flexible so that work can be redistributed seamlessly from one place to handle either overload or failure, that's "P2P enough for me" even if a picture of the system at any one point in time shows some nodes in server roles and others in client roles. That generally means that each node must be capable of performing the different roles - i.e. the code must be present, the protocols must support it - but whether a given node actually does ever perform a given role doesn't matter.
Difficult, but far from impossible. Mesh routing - which is really what you're talking about here - is a much-studied field and pretty reasonable solutions to all of the major problems are known. Check out Routing in the Internet by Christian Huitema for a pretty good overview of the relevant theory and practice.
IMO one of the big problems with P2P is that too many P2P implementors are either ignorant or disdainful of related work in this and other areas - usually both, which is a bad combination. I went to the O'Reilly P2P conference in SF a couple of months ago, and overall it was fantastic, but I did notice one thing. Everyone there seemed very sophisticated about crypto and security etc. but at the same time most were stunningly ignorant about routing, protocol design, performance management, and a bunch of other fields. There were exceptions, of course, don't get me wrong, but there's still way too much fad-following in the P2P community and not enough solid science or engineering.
That's fine, but I was quite deliberately only addressing the issue of users' choices. Issues surrounding MS's business, development, and standards-compliance processes are a whole different matter.
I thought I was pretty explicit about why that's not sufficient. Something about newbies hitting the "expert mode" button, I believe. Then again, people hitting the "reply" button before they finish reading is a related phenomenon, so I should have expected that too.
I'll bet that led to one of two outcomes. Either you sometimes managed to mess something up and learned to fix it (good for you!) or you messed it up and found someone else to fix it. In either case, you probably found that outcome pretty acceptable. Here's the crux: most people find neither acceptable. They'll just be pissed that it was ever possible for things to be rendered unusable by what they considered (rightly or not) to be innocent experimentation. Before you think they're being unfair, stop for a moment and ask yourself honestly whether you've ever had the same reaction. Have you really *never* said "I can't believe they didn't handle that properly" or cursed a sloppy programmer for not testing all the cases? Yeah, right. I'd wager a drink that you've even criticized *Microsoft products* for exactly those kind of failures, whether it's as a user or as an anti-MS zealot. Well, MS wants to avoid that. They're willing to take the hit for being too inflexible or dictatorial or whatever, in preference to being slammed for being flaky or counterintuitive or hard to configure. Again, it might not be *your* choice but it's a *valid* choice.
Many - not all - users *are* stupid. Even many of the supposedly computer-savvy people on Slashdot are *frighteningly* stupid. Everyone in this field learns sooner or later that if you provide an option, some idiot will set it inappropriately. The world is full of newbies clicking the "expert mode" button. If you're providing products for millions of users, the vast majority of whom can barely handle anything more complicated than clicking on an icon, then limiting those users' choices seems like a pretty valid design decision.
...unless it's your way, apparently. I hack kernels for a living, and I also *choose* to use MS products for some things. Are you, the champion of free choice, going to tell me my choice is invalid, that the products I prefer *shouldn't even be on the market* because they don't satisfy your desire for twiddling and tweaking? Yes, choice is good, and one valid choice is to *forego* certain other choices in the interests of getting on with life and getting things done. Windows users forego some choices, Linux users forego others. Live and let live.
Ideally, yes, but reality does not always live up to our ideals. Let me guess, though: if the pair programming doesn't work the way we're told it should, then it's not really XP, right?
Yes, that's a big benefit, but one not unique to pair programming. Before XP even existed, I once took a three-week vacation right in the middle of "crunch time", leaving a very complex piece of software (the central decision-making component of a high-availability clustering product) in a colleague's hands. How was I able to do this? It's simple. The component was sufficiently documented, commented, and accompanied by unit tests that the colleague was able to understand it, and none of that had squat to do with XP. It was just common sense and professionalism.
If we want to evaluate XP's merits vis a vis other methodologies, we need to consider the ways in which it differs from other methodologies. All this crap about "turning the dial to ten" and applying practices that were known twenty years ago to be beneficial gets us absolutely nowhere. The only aspects of XP that seem to be actual parts rather than prerequisites, and that are not already common knowledge, seem to be:
So far, the arguments and evidence contrary to the XP approach in each of these areas seem at least as compelling as the arguments in favor. For example, the recognized goodness of modular decomposition is hard to reconcile with XP's attitude toward code ownership. XP's focus on short cycle times and refactoring, taking focus *away* from trying (trying, mind you) to get it right the first time, directly contradicts a huge body of evidence about what works and what doesn't on most types of projects. Yes, you should always plan to throw away the first version, but that doesn't mean it's even better to plan on throwing away the first seven or eight. I could go on, but I hope you see the point.
Many reasonable but negative comments and observations have been made about XP here. The answers from the XP proponents have so far been more evasive than convincing, mostly consisting of either "is so!" or "do all of this and magic will happen". Some of us don't believe in magic, and would prefer an actual explanation of how and why a reasonable person might expect practices that fly in the face of decades of software-engineering knowledge to work for non-toy projects.
Wrong. You obviously missed this very important sentence at the end of section 5:
What's the significance of that? Well, we already knew that running an 802.11b network without WEP would be the act of a total moron. What the paper is saying is that *with* WEP you can attach to the network but you can't actually use it without the methods mentioned in the Borisov/Goldberg/Wagner paper. Those methods, in turn, are far from trivial. In fact, they're extremely difficult (but, admittedly, not impossible) to implement in the real world. In other words, nobody's network is actually likely to be compromised in this way. As another poster said, it's theoretically interesting, but of very little practical import.
If that quote is accurate, then I'd say Lyle Hayhurst simply lacks self-discipline. Every bad habit he mentions is likely to catch up with him sooner or later. Which is better?
#1 is obviously the worst case. #2 and #3 - standard methodology and XP respectively - are both improvements, and #4 is the best of all.
Is #3 better than #2? Maybe, maybe not. On the one hand, it avoids the necessity of going back and doing it again. On the other hand, think about which one helps programmers develop to #4. Getting caught in a code review and having to redo your work can be painful, but often the painful lessons are the ones best learned. I don't see that happening with #3. What I see happening instead is programmers relying on their partners to act as conscience instead of having a conscience of their own, "putting things past" less competent partners whenever they can, and generally not learning the lessons that help them get to #4.
BTW, this is only one example of how XP depends on programmers being of near-equal ability. Unfortunately, that just isn't the case in most of real life.
Perhaps the example was poorly chosen, or poorly worded. The problem mentioned is very real, though. Trying to distinguish between transient and permanent errors, HBA and device errors, or HW-RAID controller and actual-disk errors, is hard enough even when you have access to all of the available information - e.g. sense data for SCSI. I know this because I wrote one of the very first UNIX-based multi-path disk driver extensions, and nearly went insane dealing with this exact problem. Linux makes this problem even worse by basically throwing away most of the useful information at various points along the way from adapter driver to SCSI mid-layer to generic block-device layer, etc. I'm glad they're finally doing something about it.
Oh yeah? Check out HKCU\Software\Human\BodyParts\Boobs\Parameters, and you'll see a DWORD value for it. If you don't, you probably need to fix your registry, because several MS applications will crash if they can't find it.
Man, you really need to get off the shrooms and onto Prozac or something. Jesus and Adam Smith are both dead, and if you see either of them accumulating wealth you have a problem.
That's not a problem with religion. *People* tend to pick and choose their moral beliefs; non-religious people tend to be even more inconsistent and self-serving about it than religious people. Why should religious people be less free to choose their beliefs than non-religious people? Is the message here supposed to be "your ethics can be whatever you want, as long as they're not mandated by a religious authority"? Balls to that.
Not much, really.
I already pointed out that it's not my religion. Some of us are actually willing to defend people's right to hold viewpoints that differ from our own.
More importantly, why do you assume faith is an "all or nothing" thing? Sure, the Roman Catholics might present it that way, but many other branches of Christianity require little or nothing beyond belief in the existence of God[1]. To address your example, Unitarians in particular are famous for their acceptance of gay people. There's a pretty well established body of historical scholarship proving that much of what's in the Bible was politically rather than divinely inspired - particularly by Paul - leading to a natural questioning of how much credence it should really be given. Much of this knowledge and debate is filtering into the theological community, and is leading to a sort of "neo-Fundamentalism" that draws sharp distinctions between the words/teachings of Christ and other stuff that has been attached to those teachings by other people.
The point, at long last, is that religion is not an all-or-nothing thing. What objection do you have, for example, to someone who happens to believe in God and in salvation through Christ, but eschews sexist/xenophobic ranting by people like Paul or Augustine? What's your dispute with someone who, based on such a faith, exhibits forgiveness, charity, and other positive behaviors to a degree they otherwise might not? It is because the previous poster's broad brush would tar such people along with those who subscribe to the most twisted and harmful kinds of religious belief that I called his comments obnoxious.
If you want to criticize the behavior of religious people, that's fine. If you want to criticize specific religious beliefs as origins of those behaviors, that's fine too but I'd recommend a little caution. If you want to lambaste all religion everywhere, without regard for (or even familiarity with) how it actually affects people, I think you'll find many people like me leaving your side to stand shoulder to shoulder with people of faith.
[1] It's easier for me to limit my comments to Christianity due to familiarity, but that shouldn't be taken to imply that other religions don't have the same issues.
Y'know, you come off sounding every bit as self-righteous and narrow-minded as any preacher ever did.
But s/he never said that; the claim was that *some* of the good around us came from work inspired by or dedicated to religion - not all. Constructing strawmen won't help you deconstruct religion.
Because it is. You might not be religious, religion - particularly the organized kind - might have its flaws, but using phrases like "mass hysteria" or "brainwashing" or "fantasy" to descibe *all* religion is just obnoxious.
And what's wrong with faith? Solipsism is a singularly useless philosophy, and for anything else you need faith in *something*. Even Descartes recognized as much in his Meditations of First Philosophy, and that's really basic stuff. You seem to have a lot of faith, if I may say so, in your own perceptions and reasoning, incomplete as those might be.
So, again, what's wrong with faith? I'm not asking what's wrong with the Scientologists, or the Catholic Church, or with things that people who have faith happen to do. What's wrong with faith in and of itself? Obviously if one's faith is contradicted by observation that's one thing, but is there anything wrong with believing something not contradicted by observation?
Apparently you're not finished with being angry, though. The Church still seems to have quite a hold on you, if the mere mention of faith can cause you to have such a hissy fit.
Like you, I was brought up in a very religious environment. Like you, I broke away from it. Unlike you, I've learned to accept that what's right or wrong for me is not necessarily right or wrong for everyone, recognize that I have my own faith (even if it's not religious) and allow other people theirs.
And you always did. Religion doesn't change that; most don't even try.
Here's some news: from where I sit, your thought processes don't look all that great. I've met many religious people who could construct a better argument for their POV than you have done, and then present it more persuasively. Maybe religion isn't to blame for any deficiency in thought processes, and lack of religion is no panacea.
This has already been discussed here several times. My response from the last round can be found here.
That's actually my old website. The main one seems to be down.
Back in the really old days, DECnet would set the MAC address to a value simply derived from the DECnet address. If you couldn't set the MAC, you couldn't use DECnet.
Back in the old days, before the DMCA, there seemed to be strong concepts of "common carriers" and public forums. The basic idea was that if someone provided a "public" facility they could not be held responsible for how that facility was used. The definition of "public" was that there had to be absolutely no monitoring or censorship, and for that reason phone companies and large BBSes or conferencing systems were careful to avoid any such activities. As soon as they took any interest, basically, they also took responsibility.
I guess my question, which I was sort of hoping the article would answer, was whether the "safe harbors" of the DMCA were intended or interpreted to supplant or augment these older concepts. It seems to me that it supplants them, and sets a much higher standard for the facility owner/operator, but I'd appreciate it if anyone with better knowledge could clarify. It used to be that you could choose not to monitor or censor activity even if you had the technical means, publicize that choice, and be safe legally. Now it seems that you're left with no choice; the mere ability is enough and if you have the ability but choose not to exercise it that doesn't get you anything but trouble. Is that really the case?
Hardly a surprise. Laptops tend to incorporate a lot more vendor-specific hardware than desktops, and as a result tend to be much more of a pain for *any* OS. Comparing laptop installations to desktop installations is simply invalid.
Someone mentioned CalTech - sorry, I forgot the cid, but thank you - so I went and did a little digging. Here is a link to the CalTech Asynchronous VLSI group. Right on the page are some cogent explanations of why they believe asynchronous designs will eventually become commonplace. Further in are pointers to some good papers, and an interesting discussion of their results implementing an asynchronous version of the MIPS R3000 architecture.
A little bit of a pain, but far from impossible. Anyone who works on software for a multithreaded, multiprocessor, or distributed environment solves asynchrony-related problems all the time. We do it by having locks instead of clocks; hardware folks can do and on occasion have done just the same. I'm sorry to hear that such basically simple problems are considered unsolvable by garden-variety EEs.