A firewall could easily filter out executables by using a mime-type whitelist.
That's just covering up a symptom of the underlying problem. Why do applications like web browsers, word processors and spreadsheets need the ability to run code, and automatically at that, when that code can damage the data on my computer?
Newsflash: The only people calling it stealing are the RIAA
Bullshit. People have been calling using terms like "software theft" since they copied games off tape for the Spectrum and BBC Micro. The only people who object to the terms are those who are using diversionary tactics while attempting to morally justify breaking the law.
You know you can't fight things like this based on substance, because you know damn well that what you're doing is illegal and you're doing it because you think you can get away with it, so you revert to arguments marginally above name calling and proof by intimidation to support your case.
While I agree wholeheartedly with most of your points, I disagree with this one:
Refusing to buy is the only legitimate course of action.
Another perfectly reasonable course of action would be to investigate whether the big players in the music industry effectively form a complex monopoly that results in price fixing. The problem with the music biz isn't the existence of copyright, or even their legally supported enforcement of it, it's the abuse of the current market position. The latter is certainly a dicey legal proposition, yet no-one has DOJ'd the RIAA yet. I wonder why...
But I think you could successfully argue that the downloader opted to make a copy that would not have been made; the machine that makes the copy may be the downloadee's, but it makes that copy on the directive of the downloader and thus the downloader is the one actually making the copy.
I never understand how anyone could rationally dispute this. If I cracked someone's PC and all of the data on their hard drive found its way onto mine, would you really claim I hadn't copied anything? Would you claim that really they made the copy? Would you claim that I wasn't in breach of copyright, and was perfectly entitled to keep the data on my own computer?
Come on, guys. Claiming that really the distributor is making the copy and the downloader isn't, just because the distributor knows what's happening, is just trying to pass the buck, pure and simple. Take a little responsibility for your actions now and then, huh?
I don't think anyone reasonable is arguing that there should be no intellectual property, that creators should not be recompensed at all, or that we should return to some sort of unregulated state of nature
Unfortunately, that is exactly what a significant number of people around here argue. They want everything to be free, and see no reason to pay for any knowledge-based commodity. The fact that it requires a significant amount of work to produce those commodities, and that most people don't just want to give away a full time job's worth of work without compensation, doesn't seem to occur to them.
Besides technical issues of how they can find who downloaded what on P2P (unless they share their stuff themselves), do you mind explaining what is illegal about downloading files? Are downloaders required to verify all copyright and legal issues before downloading anything over the Internet?
Um... Actually...
Yes, both morally speaking, and as I understand it legally speaking as well in some jursidictions, that onus is on the downloader. This isn't dissimilar to several other laws on related matters.
What a staggering piece of wishful thinking. How the hell did this get modded up so high?
Granted, the file they are stored in is "My Shared Files" or whatnot... but does shared there mean files I'm sharing or files that were shared with me? There are ambiguities here that definately prevent criminal charges (to say nothing of the fact that Copyright infringement is, in most (all?) cases a civil violation anyhow).
Ignorance is not usually a defence in law. Incompetence may reduce the level of the offence, but normally won't get you off the hook either. To claim that misunderstanding what "My Shared Folders" means and that you didn't know that others could rip stuff from your machien that you'd ripped yourself does not change the fact that you are breaking the law, and if you were ripping in the first place, I'm kinda lacking in sympathy.
If you think copyright infringement is a purely civil offence, you need to do more homework. Various recent laws, notably the DMCA in the US, seek to change that. Given the wholesale abuse of the system that goes on and the impracticality of waiting while the civil legal process does its thing, I'm inclined to side with the big media companies on this one, too. I don't like them, I detest their business practices, and I think they're stupid not to take advantage of the on-line world, but abusive Internet users have brought this fate upon themselves, and have no-one else to blame.
Point being that some of these people will have clever lawyers. Many of them will get off or have charges dropped.
Very few people the RIAA go after will have clever lawyers, particularly in the US. That's why they use intimidation and threats of legal action to encourage settlements, as has often been reported here. It's a scummy practice that ought to be illegal (and probably is, if you have the effective power to challenge it). However, it makes a mockery of your implication that they are likely to come up against great lawyers defending their targets.
As long as I can stick a server in Zimbabwe and serve files off of it there's jack shit the RIAA can do about it.
You can stick your server in Zimbabwe and hope, but if too many people start doing that you can bet that draconian restrictions on getting data over the 'net from that country will follow. In the meantime, do be careful never to set foot on US soil, won't you?
Oh, and as for having no legal way to take down these networks and being unwilling to sue the downloaders, um, did you notice what this discussion is all about?
Once again the RIAA proves itself little more than a collection of jack booted thugs engaging in terror tactics to frighten its market into compliance with its desires. Unfortuately, much like the undertow of a sinking ship, the death throws of a dieing regime can be dangerous to hapless bystanders.
Once again Slashdot proves the world is full of wishful kids who want everything to be free but haven't thought it through. Unfortunately for them, the real world does not work that way. Unfortunately for the rest of us, in their zeal for advocation they ignore the current legal system and motivate big business to bring this sort of crap down on everyone else as well.
Cigarette smoking is a huge public health problem, and the costs of that problem are borne by society via the government.
You're half right. Smoking is antisocial, and does cause health problems. I'm all in favour of stamping it out anywhere I'm around for that reason alone.
However, smoking actually benefits many governments economically. They gain a vast income from taxation on the raw materials, and in places like the UK, while the National Health Service does have to spend a lot of money treating people with lung cancer etc. as a result, those people also live much shorter lives on average and don't drain the system via other ailments that older people tend to get. Most of the figures I've seen suggest that an adult smoker costs the health service significantly less on average than a non-smoker. Of course, there are all the other intangibles: whether smoking affects the amount of exercise you want to do, and thus reduces your overall level of fitness and resilience to other problems, for example.
But given the huge income from tax, there seems little doubt that smoking is a positive thing for the economy in most countries. This is why governments are trapped between a morally and politically correct anti-smoking stance and the harsh economic reality that if they succeed in dramatically reducing the level of smoking in society then they'll have to make money elsewhere.
Which isn't the point. If you ever wondered why some software is the size it is, now you know.
It is entirely the point. Compatibility with existing software, particularly such dominant software as IE, is vital to any competitor that hopes to go anywhere. Can you name a single widely-used and successful product that has taken the crown in its field from an incumbent market leader without being compatible with it?
So what is your plan, and how will bending your principles to more closely align with Microsoft's reduce the influence of their closed standards? You can't have your cake and eat it to. That's the price of principles.
I'm not bending any of my principles. I value a useful product that is compatible with its peers above some theoretical advantage of compliance with a standard to which more than 90% of users do not adhere. One of the great claims of the whole "open whatever" movement is that it promotes compatibility and you can't be locked out. And yet here is a leading open product deliberately locking itself out of being compatible with the tool most people use.
As has been pointed out time and again. You can't face Microsoft and win by playing by their rules. Go study the hustory of those companies that did and failed. Now study OSS and see why they haven't stomped us out, and never will. Aint principles grand?
You can face Microsoft, play by their rules but better, and win. Linux, Apache and Java come to mind as examples where Microsoft has lost overall control of a market it previously dominated to a superior product.
Now study OSS and ask yourself why tools like Mozilla and OpenOffice still have a market penetration that barely registers, when Mozilla is superior to IE in several important ways, and OpenOffice is a plausible and much cheaper alternative to Word for casual home users. They have the same disadvantages as so much open source: incompatibility, poor usability and poor marketing compared to the big players.
It is this "double-guessing" behaviour that has encouraged and propagated viruses.
I disagree. I think it's a poorly thought out security policy that runs executable code without proper checks that has done that. The fact that the flaw was in how MIME types were handled is coincidental. There are no MIME types in propagating a Word macro virus, but the underlying problem is the same.
People don't realize that "small" compatibility problems are Microsoft's way of forcing its own incompatible standards, thus forcing their own clients.
If another client provided an option to be compatible with the Microsoft client used by 90% of the world, then users wouldn't be forced to use Microsoft's, would they?:-)
It's a required part of the HTTP specification. Every browser other than Internet Explorer gets this right.
And that makes what, 10% of the end user market between all of them? That's probably generous.
Granted, there are a few wonky servers out there, but they aren't anywhere near as widespread as you make out. If the server you are on is serving your files incorrectly, and you cannot fix this yourself, then complain. You are getting a substandard service.
Yes, I'm getting a substandard service. And right now, as far as I can see, I'd get the same substandard service from every other major UK ISP I know about. And yes, I have mailed my ISP about it, long ago, but nothing's been done. Short of setting up my own server, at great expense I can't afford, I have no option but to rely on ISPs, who aren't exactly well-known for getting this sort of thing right.
If Mozilla and other browsers do the exact opposite of what the public specifications require, and instead blindly copy Internet Explorer, then they have essentially given control of that specification to Microsoft. How can this be a good thing?
OK, reality check please. I use a browser because I want to see the information. That information may not be sent perfectly to spec, and as I've said elsewhere I have nothing against defaulting to standard-compliant behaviour. However, failing to acknowledge that this is a common error in the protocol, and for that matter that Microsoft does effectively define the standard web formats today given their market penetration, is simply burying your head in the sand. Providing a compatibility option wouldn't be rocket science.
I don't want to see Microsoft control the web any more than the next guy. But refusing to accept that it currently holds a dominant position, and sticking to open standards on principle even when that fails to achieve what the user wants, is not the way to reduce the influence of Microsoft and the market share of their closed standards. It's a fight no free alternative, not even the likes of Mozilla or OpenOffice, can possibly win.
If I tell a browser to display something as text/plain, I don't want it rendered as html.
Unfortunately, you are in a tiny minority. The vast majority of web sites I've seen trying to deliver XML content but sending it with a text/plain MIME type wanted it interpreted as XML.
By all means leave the standard compliant interpretation in Moz, but at least provide an override to deal with the vast majority of cases where it's a simple error on the part of the server administrator (who frequently has nothing to do with either the information provider nor the end user).
IE handles XML+XSLT+CSS pretty well, certainly in version 6.
Mozilla's support would be OK, but it suffers from the same overly nitpicky irritation as it does with HTML+CSS: it stubbornly refuses to acknowledge that a file could possibly be XML or whatever unless the MIME type is correct. Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS, Moz is out of the race as a serious contender no matter how good its standards support may be.
In an attempt to preempt the inevitable slashbot responses, yes, I agree that standards are important, but they are only a means to an end. If you stick to standards so religiously that you can't actually do the job -- in this case, displaying the content as the provider and end user want -- what's the point?
Copyright law is doing something that could not be achieved through contracts and agreements. You were wrong to suggest that it was (which doesn't in any way imply that copyright is therefore bad (or good)).
I didn't say copyright could be achieved through contracts. I said it did represent an agreement between everyone (just as, effectively, all laws do). The fact that contract law is too limited to express that agreement explicitly is probably the reason separate intellectual property laws have evolved.
i'd add OCG to my 'friends' list if i wasnt AC now. his criticism is right on the money.
I'd probably do it too, if I used the friends list. His comments on subjects like this are far more rational and well argued than most of his critics. I particularly enjoy the replies that argue that no-one's backing him up because his posts are so stupid. They miss the plausible alternative that we agree with him entirely and have nothing to add.
Sometimes the truth hurts, and if you're a slashbot who really wants everything to be free because then it wouldn't cost you anything, but tries to justify that on the basis of some moral high ground, I guess the truth hurts you more than most.
Oh, and the one about having IDs less than 200,000 posted by an AC was priceless.:-)
Keep it up OCG. It's hard to beat an honest man in an argument. There are serious problems with the music industry at the moment, but the typical slashbot response isn't the way to fix them.
Here's a question: if I go down to the bookstore and buy a copy of your book, what right do you have to tell me I can't make copies and pass them around to my friends and family? What right do you have to tell me what I can and can't do with the book I purchased?
When you bought the book, you agreed not to do that. At the moment, that agreement is implicit in our intellectual property laws, but it's no difference to my explicitly saying "You can buy this book from me if you wish, at this price, as long as you agree not to copy it" and you agreeing to those terms. Morally speaking, you are now bound to honour your side of the deal, and the current legal position reflects that.
Now, you are perfectly entitled to make me a counter offer: "I will offer you $xxx for your work, on the understanding that I may make copies of it to give to others if I wish." (In fact, this is often precisely what happens in the publishing business.) We can negotiate until we reach a fair deal with which we're both happy. It is simply likely that I would ask a higher price of you for the book if I knew that you would be allowed to copy it and give it to others, since obviously you would then be able to reduce the number of others who would pay me for my work.
There's really nothing very special about this situation compared to any other fair deal in a business transaction. We agree what you're paying for and a fair price, you pay that price, you get the goods/rights/whatever. Copyright laws simply define a known set of agreements that are commonly useful, such that if you want to do something unusual you have to say so explicitly.
If I find a bug and upgrading doesn't help, the first thing I do is look in the source. It doesn't matter how big the project is. If I personally use it I want it to be bug free.
Sure, but do you review the source code for every project you use, in its entirety, before you start? Or do you just look at it to fix bugs?
The proposition here, as I understand it, seems to be that it's easier to debug open source code because the code is more maintainable as a result of more people having access to it. But if no-one other than the original author and perhaps a very small number of reviewers actually looks at things routinely, then the theoretical advantage makes no difference in practice.
We have egos at work too. I am not supposed to TOUCH anything my coworkers do, it is THEIR code and THEIRS to command, hands off! Even when I sneak a peek and find obvious bugs, I am not allowed to fix them because it violates territoriality. This sort of code hording is impossible in OSS [...]
It should be impossible in a sensibly run closed source project as well. If you have a development team whose egos are such that they can't stand criticism and claim unique ownership, you are on the absolute lowest rung of the smart development process ladder. Teams full of such people will never produce good results, whether their source is closed or not.
As with many of the points raised in a thread like this, though, the problem is with industrial development processes and not actually with closed source. In a decent coding shop, no-one has sole knowledge or control of any area of code. In better shops, reviews are routine, and the good guys actively solicit feedback from their peers.
This is just another case (like the "many eyes" argument, and others) where the argument made in favour of open source looks great at first glance, but doesn't stand up to much scrutiny. To date, the most convincing argument I've seen for why some of the big open source projects have generally good code is still that those who do it frequently do so out of interest, rather than just to pay the rent (though certainly most of the work on the big OSS projects is done by pro's these days).
A more likely explanation is the 'many eyes' that can review the code.
Many eyes can. How many actually do? Unless you're talking about the really big projects, probably very few indeed -- one, I suspect, in many cases.
It's not fair to cite mainstream developments like Linux or Mozilla as the way all open source is any more than it's fair to cite Microsoft's history on things like security and reliability as the way all closed source is.
Thank you for taking the time to post a calm and informed reply. I probably didn't deserve that after taking your original reply the wrong way and flaming it. To return in kind...
I understand that you are considering the wider picture throughout the book, and that your chapter on OO is considered within that framework. In fact, I very much like your "kernel language" approach, and the emphasis you place on commonality; I have no disagreement with that principle at all.
I think my big objection to your presentation as it stands is that while you've covered a lot of the issues in general, I felt that the specific applications to OO were mostly overlooked. For example, you place a great deal of emphasis on inheritance, where I would argue that inheritance is actually the most overhyped aspect of OO. It usually adds value only when used in conjunction with polymorphism, and actually reduces maintainability when used indiscriminately. I realise that you have the underlying structure to discuss these ideas, I just felt that the "last step" was missing, and that last step is the really important one if you've got relative beginners to OO meeting the general concepts in that context for the first time.
The same goes for things like invariant conditions. I understand that you've covered the concept, but your discussion in the chapter on OO doesn't give any real discussion of the role of initialisation as a means of getting an object's current state to satisfy the invariant conditions required by the class, for example. It would be hard to explain why constructors exist and work as they do in C++ or Java in the absence of that link between invariant state and initialisation of an object when it is first created.
Similarly, I found no discussion of using pre- and post-conditions on the external view of a class' state when defining its interface. Given the natural links between these conditions, inheritance and the substitution principle, I felt this was a serious omission. Perhaps you've again covered the principles elsewhere in the book, but if so, I think this is another case where some specific discussion in the OO chapter definitely has merit.
Finally, regarding your AccountWithFee example, my problem is that nothing you've shown us from your class' interface implies that the condition you give (B+S-@fee=B2) must hold. As I read it, you have a method balance that reports the current balance of the account, and a method transfer that accepts a certain amount of money into the account.
Now, if the latter were called increaseBalance, or had an explicit postcondition in its interface that balance would now be higher than it used to be by exactly the amount transferred, then I would not have an objection. However, in the absence of such conditions, I regard any code outside the class that makes that assumption as being what is broken, because it is relying on implementation details not defined in the interface. As things stand, if code in the outside world wants to know the balance of the account, it should use the balance method to ask, and if it wants to know how much the balance has increased after a transfer, it should look at the difference in the values provided by balance before and after the transfer. This appears to give well-defined results under the interface as we see it in your example, which the other assumption does not.
I feel that the lack of emphasis on separating interface from implementation (what IIRC Meyer describes as "design by contract") and the lack of consideration of invariant conditions (internal to a class) and pre- and post-conditions (both internal and as defining properties of the external interface) really hurt here. If you could show that a derived class method did not satisfy a post-condition of the class interface (whether that condition is stated explicitly or implied by calling the method increaseBalance) then you would have a rock-solid case. As it stands
...I'll apologise now for the perhaps overly harsh tone of the parent post. As I noted in my original reply, there seems to be a lot of worthwhile material elsewhere in the book. I'm afraid I really don't like your presentation of OO, though.
Programming is my full-time job, and I use this stuff (and other programming styles you mention) all day. I also teach it to newbies from time to time. At that level, I've found that it's vital to get across concepts like invariant/pre-/post-conditions, and the focus on using inheritance with polymorphism and aggregation when it's not required. You can worry about the technical differences between subtyping and subclassing later, once they have some framework for the concepts. Introducing it all up-front from a purely theoretical viewpoint loses the major practical points of using OO, and leads to people like me objecting to examples of "bad" inheritance such as the one in the book. Obviously, this is just MHO and you're free to disagree.:-)
Why, the LSP is known by many different names. The 'substitution property' for example.
What they called the "substitution property" is a waffly version of Liskov's clear and concise principle.
Why not try actually *reading* the OO chapter before giving such a sweeping judgement:-).
I appreciate the smiley there, but OK, I've now read the first half of the OO chapter in its entirety. Not only does it fail to mention the LSP in any useful way, it also fails to stress the interface/implementation separation, the significance of polymorphism and the way inheritance is used in many languages to allow it, the concepts of invariant conditions on a class' state and pre- and post-conditions on its methods, and just about everything else that's actually important about OO. Instead, they seem to spend lots of time going on about the cute syntax in their pet language.
Just to finally convince me that they don't really understand OO, their example (in section 7.4.1) of bad inheritance is dubious at best. They could have used the circle/ellipse or integer/rational "paradoxes" to demonstrate the hazards of using inheritance poorly, but instead they use an example that actually seems entirely reasonable to me. Their claim about what the outside world can expect violates the very principle of encapsulation: the outside world shouldn't know that, because it's an internal proprerty of that class... Unless, of course, it's documented in the interface as a post-condition of the method calls, but in that case, the derived class is breaking LSP. Oh, but they haven't mentioned post-conditions and how they are constrained by LSP, so it's kinda hard to say that.
Sorry, but having read 50 pages of that book, I'm quite convinced that it's not the new bible of programming. On the contrary, I would actually steer anyone interested in learning OO away from it, as I think its overweight theory and underpowered practice would be harmful to a newbie.
Is this book really as authoratitive as it tries to appear?
I had a quick scan over it, and while I'm reluctant to judge on first impressions, I couldn't help feeling that it had a lot of breadth but not much depth. It struck me as somewhat similar in style to the wizard book, though obviously with wider coverage.
I had the same immediate reservation as you did: the OOP section seemed weak compared to established "classics" in the field. Failure to mention things like LSP is unforgivable in a book aiming for a theoretical approach. The offhand comment about "whatever that means" in reference to sending messages to everything didn't much help, either; I'm guessing anyone who's used a language like Smalltalk or Ruby would be quite comfortable with the idea.
All of that said, there appears to be a lot of useful and worthwhile material in the book, and I'll certainly be dipping into other parts of it as time allows over the next few days. It's only a preprint, and I only looked at one section in any real detail at all, so I'll give it the benefit of the doubt for now.
Slashdot Mirror
It's past 1am and some **** is throwing inexact representations and fuzzy logic at me.... This must be a nightmare... Must... wake... up... Aaaaaargh!
That's just covering up a symptom of the underlying problem. Why do applications like web browsers, word processors and spreadsheets need the ability to run code, and automatically at that, when that code can damage the data on my computer?
Bullshit. People have been calling using terms like "software theft" since they copied games off tape for the Spectrum and BBC Micro. The only people who object to the terms are those who are using diversionary tactics while attempting to morally justify breaking the law.
You know you can't fight things like this based on substance, because you know damn well that what you're doing is illegal and you're doing it because you think you can get away with it, so you revert to arguments marginally above name calling and proof by intimidation to support your case.
While I agree wholeheartedly with most of your points, I disagree with this one:
Another perfectly reasonable course of action would be to investigate whether the big players in the music industry effectively form a complex monopoly that results in price fixing. The problem with the music biz isn't the existence of copyright, or even their legally supported enforcement of it, it's the abuse of the current market position. The latter is certainly a dicey legal proposition, yet no-one has DOJ'd the RIAA yet. I wonder why...
I never understand how anyone could rationally dispute this. If I cracked someone's PC and all of the data on their hard drive found its way onto mine, would you really claim I hadn't copied anything? Would you claim that really they made the copy? Would you claim that I wasn't in breach of copyright, and was perfectly entitled to keep the data on my own computer?
Come on, guys. Claiming that really the distributor is making the copy and the downloader isn't, just because the distributor knows what's happening, is just trying to pass the buck, pure and simple. Take a little responsibility for your actions now and then, huh?
Unfortunately, that is exactly what a significant number of people around here argue. They want everything to be free, and see no reason to pay for any knowledge-based commodity. The fact that it requires a significant amount of work to produce those commodities, and that most people don't just want to give away a full time job's worth of work without compensation, doesn't seem to occur to them.
Um... Actually...
Yes, both morally speaking, and as I understand it legally speaking as well in some jursidictions, that onus is on the downloader. This isn't dissimilar to several other laws on related matters.
What a staggering piece of wishful thinking. How the hell did this get modded up so high?
Ignorance is not usually a defence in law. Incompetence may reduce the level of the offence, but normally won't get you off the hook either. To claim that misunderstanding what "My Shared Folders" means and that you didn't know that others could rip stuff from your machien that you'd ripped yourself does not change the fact that you are breaking the law, and if you were ripping in the first place, I'm kinda lacking in sympathy.
If you think copyright infringement is a purely civil offence, you need to do more homework. Various recent laws, notably the DMCA in the US, seek to change that. Given the wholesale abuse of the system that goes on and the impracticality of waiting while the civil legal process does its thing, I'm inclined to side with the big media companies on this one, too. I don't like them, I detest their business practices, and I think they're stupid not to take advantage of the on-line world, but abusive Internet users have brought this fate upon themselves, and have no-one else to blame.
Very few people the RIAA go after will have clever lawyers, particularly in the US. That's why they use intimidation and threats of legal action to encourage settlements, as has often been reported here. It's a scummy practice that ought to be illegal (and probably is, if you have the effective power to challenge it). However, it makes a mockery of your implication that they are likely to come up against great lawyers defending their targets.
You can stick your server in Zimbabwe and hope, but if too many people start doing that you can bet that draconian restrictions on getting data over the 'net from that country will follow. In the meantime, do be careful never to set foot on US soil, won't you?
Oh, and as for having no legal way to take down these networks and being unwilling to sue the downloaders, um, did you notice what this discussion is all about?
Once again Slashdot proves the world is full of wishful kids who want everything to be free but haven't thought it through. Unfortunately for them, the real world does not work that way. Unfortunately for the rest of us, in their zeal for advocation they ignore the current legal system and motivate big business to bring this sort of crap down on everyone else as well.
You're half right. Smoking is antisocial, and does cause health problems. I'm all in favour of stamping it out anywhere I'm around for that reason alone.
However, smoking actually benefits many governments economically. They gain a vast income from taxation on the raw materials, and in places like the UK, while the National Health Service does have to spend a lot of money treating people with lung cancer etc. as a result, those people also live much shorter lives on average and don't drain the system via other ailments that older people tend to get. Most of the figures I've seen suggest that an adult smoker costs the health service significantly less on average than a non-smoker. Of course, there are all the other intangibles: whether smoking affects the amount of exercise you want to do, and thus reduces your overall level of fitness and resilience to other problems, for example.
But given the huge income from tax, there seems little doubt that smoking is a positive thing for the economy in most countries. This is why governments are trapped between a morally and politically correct anti-smoking stance and the harsh economic reality that if they succeed in dramatically reducing the level of smoking in society then they'll have to make money elsewhere.
It is entirely the point. Compatibility with existing software, particularly such dominant software as IE, is vital to any competitor that hopes to go anywhere. Can you name a single widely-used and successful product that has taken the crown in its field from an incumbent market leader without being compatible with it?
I'm not bending any of my principles. I value a useful product that is compatible with its peers above some theoretical advantage of compliance with a standard to which more than 90% of users do not adhere. One of the great claims of the whole "open whatever" movement is that it promotes compatibility and you can't be locked out. And yet here is a leading open product deliberately locking itself out of being compatible with the tool most people use.
You can face Microsoft, play by their rules but better, and win. Linux, Apache and Java come to mind as examples where Microsoft has lost overall control of a market it previously dominated to a superior product.
Now study OSS and ask yourself why tools like Mozilla and OpenOffice still have a market penetration that barely registers, when Mozilla is superior to IE in several important ways, and OpenOffice is a plausible and much cheaper alternative to Word for casual home users. They have the same disadvantages as so much open source: incompatibility, poor usability and poor marketing compared to the big players.
I disagree. I think it's a poorly thought out security policy that runs executable code without proper checks that has done that. The fact that the flaw was in how MIME types were handled is coincidental. There are no MIME types in propagating a Word macro virus, but the underlying problem is the same.
If another client provided an option to be compatible with the Microsoft client used by 90% of the world, then users wouldn't be forced to use Microsoft's, would they? :-)
And that makes what, 10% of the end user market between all of them? That's probably generous.
Yes, I'm getting a substandard service. And right now, as far as I can see, I'd get the same substandard service from every other major UK ISP I know about. And yes, I have mailed my ISP about it, long ago, but nothing's been done. Short of setting up my own server, at great expense I can't afford, I have no option but to rely on ISPs, who aren't exactly well-known for getting this sort of thing right.
OK, reality check please. I use a browser because I want to see the information. That information may not be sent perfectly to spec, and as I've said elsewhere I have nothing against defaulting to standard-compliant behaviour. However, failing to acknowledge that this is a common error in the protocol, and for that matter that Microsoft does effectively define the standard web formats today given their market penetration, is simply burying your head in the sand. Providing a compatibility option wouldn't be rocket science.
I don't want to see Microsoft control the web any more than the next guy. But refusing to accept that it currently holds a dominant position, and sticking to open standards on principle even when that fails to achieve what the user wants, is not the way to reduce the influence of Microsoft and the market share of their closed standards. It's a fight no free alternative, not even the likes of Mozilla or OpenOffice, can possibly win.
Unfortunately, you are in a tiny minority. The vast majority of web sites I've seen trying to deliver XML content but sending it with a text/plain MIME type wanted it interpreted as XML.
By all means leave the standard compliant interpretation in Moz, but at least provide an override to deal with the vast majority of cases where it's a simple error on the part of the server administrator (who frequently has nothing to do with either the information provider nor the end user).
IE handles XML+XSLT+CSS pretty well, certainly in version 6.
Mozilla's support would be OK, but it suffers from the same overly nitpicky irritation as it does with HTML+CSS: it stubbornly refuses to acknowledge that a file could possibly be XML or whatever unless the MIME type is correct. Given that even fewer servers, particularly those run by ISPs for their personal subscribers rather than run by companies for themselves, get the MIME type right for X* than they do for HTML+CSS, Moz is out of the race as a serious contender no matter how good its standards support may be.
In an attempt to preempt the inevitable slashbot responses, yes, I agree that standards are important, but they are only a means to an end. If you stick to standards so religiously that you can't actually do the job -- in this case, displaying the content as the provider and end user want -- what's the point?
I didn't say copyright could be achieved through contracts. I said it did represent an agreement between everyone (just as, effectively, all laws do). The fact that contract law is too limited to express that agreement explicitly is probably the reason separate intellectual property laws have evolved.
On the contrary, that is exactly what copyright is, though obviously it's not quite worldwide.
I'd probably do it too, if I used the friends list. His comments on subjects like this are far more rational and well argued than most of his critics. I particularly enjoy the replies that argue that no-one's backing him up because his posts are so stupid. They miss the plausible alternative that we agree with him entirely and have nothing to add.
Sometimes the truth hurts, and if you're a slashbot who really wants everything to be free because then it wouldn't cost you anything, but tries to justify that on the basis of some moral high ground, I guess the truth hurts you more than most.
Oh, and the one about having IDs less than 200,000 posted by an AC was priceless. :-)
Keep it up OCG. It's hard to beat an honest man in an argument. There are serious problems with the music industry at the moment, but the typical slashbot response isn't the way to fix them.
When you bought the book, you agreed not to do that. At the moment, that agreement is implicit in our intellectual property laws, but it's no difference to my explicitly saying "You can buy this book from me if you wish, at this price, as long as you agree not to copy it" and you agreeing to those terms. Morally speaking, you are now bound to honour your side of the deal, and the current legal position reflects that.
Now, you are perfectly entitled to make me a counter offer: "I will offer you $xxx for your work, on the understanding that I may make copies of it to give to others if I wish." (In fact, this is often precisely what happens in the publishing business.) We can negotiate until we reach a fair deal with which we're both happy. It is simply likely that I would ask a higher price of you for the book if I knew that you would be allowed to copy it and give it to others, since obviously you would then be able to reduce the number of others who would pay me for my work.
There's really nothing very special about this situation compared to any other fair deal in a business transaction. We agree what you're paying for and a fair price, you pay that price, you get the goods/rights/whatever. Copyright laws simply define a known set of agreements that are commonly useful, such that if you want to do something unusual you have to say so explicitly.
Sure, but do you review the source code for every project you use, in its entirety, before you start? Or do you just look at it to fix bugs?
The proposition here, as I understand it, seems to be that it's easier to debug open source code because the code is more maintainable as a result of more people having access to it. But if no-one other than the original author and perhaps a very small number of reviewers actually looks at things routinely, then the theoretical advantage makes no difference in practice.
It should be impossible in a sensibly run closed source project as well. If you have a development team whose egos are such that they can't stand criticism and claim unique ownership, you are on the absolute lowest rung of the smart development process ladder. Teams full of such people will never produce good results, whether their source is closed or not.
As with many of the points raised in a thread like this, though, the problem is with industrial development processes and not actually with closed source. In a decent coding shop, no-one has sole knowledge or control of any area of code. In better shops, reviews are routine, and the good guys actively solicit feedback from their peers.
This is just another case (like the "many eyes" argument, and others) where the argument made in favour of open source looks great at first glance, but doesn't stand up to much scrutiny. To date, the most convincing argument I've seen for why some of the big open source projects have generally good code is still that those who do it frequently do so out of interest, rather than just to pay the rent (though certainly most of the work on the big OSS projects is done by pro's these days).
Many eyes can. How many actually do? Unless you're talking about the really big projects, probably very few indeed -- one, I suspect, in many cases.
It's not fair to cite mainstream developments like Linux or Mozilla as the way all open source is any more than it's fair to cite Microsoft's history on things like security and reliability as the way all closed source is.
Thank you for taking the time to post a calm and informed reply. I probably didn't deserve that after taking your original reply the wrong way and flaming it. To return in kind...
I understand that you are considering the wider picture throughout the book, and that your chapter on OO is considered within that framework. In fact, I very much like your "kernel language" approach, and the emphasis you place on commonality; I have no disagreement with that principle at all.
I think my big objection to your presentation as it stands is that while you've covered a lot of the issues in general, I felt that the specific applications to OO were mostly overlooked. For example, you place a great deal of emphasis on inheritance, where I would argue that inheritance is actually the most overhyped aspect of OO. It usually adds value only when used in conjunction with polymorphism, and actually reduces maintainability when used indiscriminately. I realise that you have the underlying structure to discuss these ideas, I just felt that the "last step" was missing, and that last step is the really important one if you've got relative beginners to OO meeting the general concepts in that context for the first time.
The same goes for things like invariant conditions. I understand that you've covered the concept, but your discussion in the chapter on OO doesn't give any real discussion of the role of initialisation as a means of getting an object's current state to satisfy the invariant conditions required by the class, for example. It would be hard to explain why constructors exist and work as they do in C++ or Java in the absence of that link between invariant state and initialisation of an object when it is first created.
Similarly, I found no discussion of using pre- and post-conditions on the external view of a class' state when defining its interface. Given the natural links between these conditions, inheritance and the substitution principle, I felt this was a serious omission. Perhaps you've again covered the principles elsewhere in the book, but if so, I think this is another case where some specific discussion in the OO chapter definitely has merit.
Finally, regarding your AccountWithFee example, my problem is that nothing you've shown us from your class' interface implies that the condition you give (B+S-@fee=B2) must hold. As I read it, you have a method balance that reports the current balance of the account, and a method transfer that accepts a certain amount of money into the account.
Now, if the latter were called increaseBalance, or had an explicit postcondition in its interface that balance would now be higher than it used to be by exactly the amount transferred, then I would not have an objection. However, in the absence of such conditions, I regard any code outside the class that makes that assumption as being what is broken, because it is relying on implementation details not defined in the interface. As things stand, if code in the outside world wants to know the balance of the account, it should use the balance method to ask, and if it wants to know how much the balance has increased after a transfer, it should look at the difference in the values provided by balance before and after the transfer. This appears to give well-defined results under the interface as we see it in your example, which the other assumption does not.
I feel that the lack of emphasis on separating interface from implementation (what IIRC Meyer describes as "design by contract") and the lack of consideration of invariant conditions (internal to a class) and pre- and post-conditions (both internal and as defining properties of the external interface) really hurt here. If you could show that a derived class method did not satisfy a post-condition of the class interface (whether that condition is stated explicitly or implied by calling the method increaseBalance) then you would have a rock-solid case. As it stands
...I'll apologise now for the perhaps overly harsh tone of the parent post. As I noted in my original reply, there seems to be a lot of worthwhile material elsewhere in the book. I'm afraid I really don't like your presentation of OO, though.
Programming is my full-time job, and I use this stuff (and other programming styles you mention) all day. I also teach it to newbies from time to time. At that level, I've found that it's vital to get across concepts like invariant/pre-/post-conditions, and the focus on using inheritance with polymorphism and aggregation when it's not required. You can worry about the technical differences between subtyping and subclassing later, once they have some framework for the concepts. Introducing it all up-front from a purely theoretical viewpoint loses the major practical points of using OO, and leads to people like me objecting to examples of "bad" inheritance such as the one in the book. Obviously, this is just MHO and you're free to disagree. :-)
What they called the "substitution property" is a waffly version of Liskov's clear and concise principle.
I appreciate the smiley there, but OK, I've now read the first half of the OO chapter in its entirety. Not only does it fail to mention the LSP in any useful way, it also fails to stress the interface/implementation separation, the significance of polymorphism and the way inheritance is used in many languages to allow it, the concepts of invariant conditions on a class' state and pre- and post-conditions on its methods, and just about everything else that's actually important about OO. Instead, they seem to spend lots of time going on about the cute syntax in their pet language.
Just to finally convince me that they don't really understand OO, their example (in section 7.4.1) of bad inheritance is dubious at best. They could have used the circle/ellipse or integer/rational "paradoxes" to demonstrate the hazards of using inheritance poorly, but instead they use an example that actually seems entirely reasonable to me. Their claim about what the outside world can expect violates the very principle of encapsulation: the outside world shouldn't know that, because it's an internal proprerty of that class... Unless, of course, it's documented in the interface as a post-condition of the method calls, but in that case, the derived class is breaking LSP. Oh, but they haven't mentioned post-conditions and how they are constrained by LSP, so it's kinda hard to say that.
Sorry, but having read 50 pages of that book, I'm quite convinced that it's not the new bible of programming. On the contrary, I would actually steer anyone interested in learning OO away from it, as I think its overweight theory and underpowered practice would be harmful to a newbie.
I had a quick scan over it, and while I'm reluctant to judge on first impressions, I couldn't help feeling that it had a lot of breadth but not much depth. It struck me as somewhat similar in style to the wizard book, though obviously with wider coverage.
I had the same immediate reservation as you did: the OOP section seemed weak compared to established "classics" in the field. Failure to mention things like LSP is unforgivable in a book aiming for a theoretical approach. The offhand comment about "whatever that means" in reference to sending messages to everything didn't much help, either; I'm guessing anyone who's used a language like Smalltalk or Ruby would be quite comfortable with the idea.
All of that said, there appears to be a lot of useful and worthwhile material in the book, and I'll certainly be dipping into other parts of it as time allows over the next few days. It's only a preprint, and I only looked at one section in any real detail at all, so I'll give it the benefit of the doubt for now.