While the government may be saying this, all the UK government tenders I get ALL state that the prefered OS is windows, [...] The main reason for this is that they have lots of people who claim to be windows admin but very few who claim to be unix admin.
That, and things like the half-billion pound deal the National Health Service just struck with Microsoft to supply software for them for the next nine years (IIRC). Once you've got that sort of momentum in a small organisation like the NHS (Europe's largest single employer, for those who don't know) it's very hard to change course.
So, you get +1 Informative because you read part of the article, but -1 Incomplete for not reading the whole thing.
And you get (-1, Just Plain Wrong) for failing to notice half a million prior Slashdot posts, all explaining that the points would stand independently, so if claim 1 is granted, the programming language doesn't matter.:-)
Was going to mod you, but then wasn't sure whether you should be a troll, flamebait, insightful or interesting, so thought I'd reply instead.:-)
One of your fallacies is that you presume that the RIAA is being "hurt" by internet downloading of music.
They'd like you to think that they are being so hurt.
But all the studies say otherwise, citing no statistical variance in sales compared to the general economic condition before, during, or after peak Napster use.
The fact is that the "harm" only exists in the feevered dreams of averice fixed firmly in the deluded heads of RIAA executives.
It may (or may not) only be in those heads, but it's a good bet that they do sincerely believe it.
All the usual kindergarten statistical mistakes frequently get made by both sides in this debate, particularly confusing correlation with causation. However, the RIAA execs can see the same studies as everyone else. Contrary to popular opinion in some parts, they probably didn't get to those positions by being stupid either, so they're going to be well aware of the negative PR value of their legal campaigns, and the costs of all the lawyers' time to push them.
Now, if those execs could see that allowing on-line distribution would really make them more money, or had a negligible effect on sales, they would be promoting it or ignoring it. They are trying to maximise their organisations' profits, and you don't do that by spending who knows how much on legal battles that don't help you, or by annoying significant fractions of your potential customer base without good cause.
Hence, whatever those of you who rip music illegally may choose to believe in order to justify breaking the law, it's a good bet that the RIAA execs really do believe that the illegal song-swapping is hurting their business.
This is a world where selfish people are rewarded. Hence, if you download music but then do not share it (i.e. you keep it for yourself) you are not doing anything illegal.
Obligatory note: in most jurisdictions, that is at best an assumption that has not been tested in court.
I hope that Mr. Blunkett has noticed that loyalty cards get borrowed all the time.
Well, there you go, see. If you had to carry an ID card as well, shops could stop that dubious practice and ensure the integrity of their data, making the world a better place for us all. Go Blunkett!
Everybody seems to be confusing everything :-(
on
Holub on Patterns
·
· Score: 1
The surprising thing here is that nobody seems to be considering that there are more than two concepts at work here: sure you've got the "total" and the "money to add", but you also have the operation of adding two monetary values together, and the operation of assigning that result to yield a new total.
It doesn't matter whether you call the summation operation "+=" or "addTo" or "funkyTypeConvertingSummationAlgorithm". The operation is dependent on both the total and the amount, or more precisely on how their values are represented. There could be complications, perhaps due to type conversion issues: not just the obvious double vs. float type of thing, but for example the possibility that the amounts are value-currency pairs and exchange rates need to be considered.
Until you've sorted out where responsibility for this sort of operation should lie within your design, messing around with whether the function that does it is a method of this class or that one (or a non-member function in a language that allows them) is running before you can walk.
The key concept is encapsulation. If you expose your attribute (price) to the whole world, then an unlimited number of clients can couple themselves to this, creating brittle code.
Do you often write a shopping application, and then find that the items for sale no longer have a price? Ensuring that the Price type is user-defined (if only as a synonym for double at first) should be plenty of future-proofing for now.
So use a Builder pattern . Define an interface for exporting information about your Item object. For something like a Cart, define an interface for importing information (building) a Cart. Create a concrete class(es) that implements these interfaces.
This may also seem like too much work, too difficult, etc. It is definitely not the easiest/quickest way to solve the immediate problem. That's not the point of object oriented programming. The point is that it makes for code that is more robust and easier to maintain.
Newsflash: adding vast amounts of clutter around a simple concept does not make code either more robust or easier to maintain. Your design commits the cardinal sin of over-engineering based on a hypothesised future change requirement. You can't possibly know whether all that extra rubbish will make a future change easier, because you don't know what the change will be yet. However, you can guarantee that writing all the additional clutter will take longer, leave more scope for bugs, and make the code harder to understand if it does turn out that maintenance is needed later on. This sort of ivory tower theory is exactly why so much OOP code is unmaintainable junk in practice.
So what are you supposed to do when you need to get some representation of state out of an object -- to display it? Can you do a getStateValue()? Oh, no! You have to hand that object an AWT graphics context object and have the object render itself.
When I first read that, I assumed you were joking, and had just made that up as an absurd example to exaggerate the author's point. Then I read TFA, and realised that Holub himself advocated exactly that. Talk about getting your priorities completely wrong!
Getters and setters are not "evil". They are a design choice, as Holub himself acknowledges. If you have a lot of these for a particular class, this is often symptomatic of a confused design, but the author missed the point here. The bits you're supposed to hide are the individual aspects of an object's state that must satisfy various invariant conditions. It doesn't make sense to change these independently, because you might violate that invariant. Hence, you only provide operations on the class that change them collectively such that they still satisfy the required invariant conditions.
However, if something can be changed in isolation without violating any invariants, there's no harm in providing a mutator method to do it. That applies up to and including classes with no invariants ("structs") where you can sensibly modify any aspect of the state in isolation. Moreover, if some aspect of state has a meaning in isolation, there is no harm in providing an accessor method to look up that state, even if you wouldn't allow it to be changed directly because of invariant constraints.
Confusing this with the idea that an object should be the only thing that can do anything with itself (such as drawing itself on a screen) demonstrates a spectacular failure to understand the underlying issues here. In fact, it's easy to show this: consider an operation where two or more user-defined types are involved, and you can't restrict all the knowledge about each object to that object and still perform the operation. Attempting to do so often results in exactly the problem with Holub's "draw thyself" example: it tightly binds two separate subsystems, forcing one class to live in both of them, with all the attendant spaghettiness that brings.
Now, Holub clearly realises that mixing UI code with business logic has unfortunate problems. He can protest about inner classes and facade patterns all he likes, but the fundamental design concern -- coupling the UI system to a data-handling system -- is still there. The only way to break the bad coupling is to separate out the facade code or whatever from the original class, and put it in a UI-based layer where it belongs. Of course, that probably requires using some form of accessor methods, which takes up back to where we started.
Who is this guy anyway, and why do some people here think he's good at this stuff? I honestly haven't heard of him before, and I'm fairly open-minded, but I'm not forming a good impression from reading a couple of his articles that people have cited in this thread.
I agree that composition should often be favoured over inheritance, but I think there are several reasons for this. The bottom line is that inheritance is most useful as a mechanism for allowing implicit type coercion via polymorphism. If you don't need to use polymorphism, inheritance is just another tool for organising your code, and it's often over-used in that context where simpler things like composition would avoid cluttering the class hierarchy, issues with anonymous base subobjects that could be named explicitly if they were members, etc.
Programming languages that allow writing high level code using concepts close to the application domain are simply more powerful than those that force the programmer to convert between the application domain and the computational facilities of the language all the time. Some languages support writing higher level code this way much better than others, and this is where a lot of the research behind the next generation of languages should be going.
Some use the symbol = for equality, as in a=b is true if a and b are equal. Others use = for assignment to change a variable's value, and so use == for equality, so the above test would become a==b.
The -NE- is a dig at FORTRAN programmers, I assume. (NE = not equal.)
Perfectly easy to read, after all, who wouldn't understand what "ADD VAR1 TO VAR2 GIVING VARX", but who the hell would use the word "giving" in such a way.
You're right. I prefer "yielding" myself, or perhaps "motivating" on a light day.
Then again, on the principle of never using a word where a polysyllabic construct will do, we could employ "entering the result into".
Then again again, if I may misquote Disraeli, perhaps I'm just inebriated with the exuberance of my own verbosity now.
OK, now please breathe deeply, step back, cut the implied ad hominem attacks, and think.
The problem here is not the malware, unless a patch in SP2 is intended to remove that malware. The malware is, well, "mal", but it was before anyway. The problem is that installing SP2 on many systems is making the situation worse. Please see my reply to the AC, and note the trivial steps that could be taken to fix most of the mess in the situation you guys are describing. Also consider that if installing SP2 results in more downtime than all the security flaws in recent history, as has been the case for many of the people I know who've been brave enough to try it, maybe that's not progress.
Then you might like to check the numerous tales of woe from technically competent people whose systems were swept for the usual gremlins before the install, but who still had their OS taken out. Blaming the mess entirely on malware is a cop-out, unless you consider installing the only drivers available for numerous hardware devices, which worked fine prior to SP2, to be installing malware on your system.
Do you really believe that patches should magically fix compromised systems?
Not in 100% of cases, but at the very least they shouldn't make those systems any worse. By the arguments people are giving in reply to my previous post, no security patch can ever install reliably, yet strangely, many have until this point.
For a start, Windows XP is supposed to have filesystem protection in place to prevent permanent changes to key Windows system files. This was one of the much-hyped benefits of upgrading, if you recall. If this has been circumvented, Microsoft must at least know the correct checksums etc. for all the key system files in their unmodified state.
At the very least, following the "do no harm" policy, each included patch in the SP could check whether the previous versions of the files it's changing were unmodified, and issue a warning rather than messing around trying to install over bad starting data in that case. That alone would probably prevent a lot of the problems.
Taking that to its logical conclusion, it would be hard to compromise a system without affecting any key files at all. Why can't the update include checksum information for all the key system files, check them all at the start of installation, and abort with a suitable warning rather than proceeding if the system has been compromised? It's not as though it's a small, modem-friendly download and they're worried about file sizes.
Come on guys, this isn't rocket science, it's kindergarten. Failing to read page one of the manual is no excuse for delivering an update to such essential software that takes out something like 30% of your installed base according to early adopters. I could understand the odd slip up, some particularly clever malware or a human error among hundreds of fixes, but we're talking about thousands and thousands of installations being wrecked here.
Eventually we're all going to HAVE to upgrade, MS isn't going to support SP1a forever.
They'll support it as long as megacorps are refusing to upgrade their desktops to SP2 because of all the instability problems. I work for one, and we're all under strict orders not to download the update until it's been properly checked out by our IT guys. Go on, tell me you haven't heard that from millions of others as well.:-)
It's just like dropping support for old versions of Windows itself: MS would love to, but since they've borked the update process and their major customers aren't riding with them, they can't do so without seriously damaging their business.
An SP2 installation is very unforgiving to a machine that has a lot of malware/spyware in it. A lot of that same software will cause IE to act flaky. Chances are your friend has a very compromised machine and SP2 couldn't install properly because of it.
So let me get this straight... Microsoft's ueber-update to improve Windows security works great, as long as you install it on a machine that was already secure enough not to have malware/spyware on it?
People idea of usability is usually that programs work the way they are meant without asking for too much help to do their job. For example a usability feature of Internet Explorer was to automatically execute.doc file viewers when you downloaded them. The action of executing automatically is wonderful and for many is seen as a great usability enhancement. But what happens when the.doc file can be programmed to do all kinds of problems on your computer? What if that automatically executed script within causes havoc with other seemingly non-related things?
That's a fair point, but I would ask whether the problem here is the usability benefit of allowing viewing a different type of document without fuss, or the feature creep of allowing just viewing a document to run arbitrary code that can do any harm to your computer.
I couldn't agree more. In fact, I'd go as far as to say that usability is a necessary minimum requirement for security. After all, a very large proportion of attacks succeed because of a simple human failure, not an electronic one.
For example, if banks would stop constantly requiring me to remember seventeen different ID numbers, "memorable" words and phrases, I might notice the e-mail they send out reminding me not to give out my PIN number to anyone else.
On a more techie level, languages where it's easy to code properly make careless errors like allowing buffer over-runs or SQL injection less likely.
At the heart of good usability are principles like KISS and not giving the user unnecessary chances to go wrong. These don't exclude giving the user power, but what better partner for keeping a user safe than not giving them silly chances to do dangerous things?
Do you really think that five guys armed with box cutters are going to be able to kill a plane full of people with nothing to lose? Or two guys armed with guns?
Unfortunately, the answer is clearly yes: guy points gun at side of plane and fires, cabin decompresses explosively, plane crashes, and everybody dies. No magic or cunning planning required.
The relevant question must surely be whether facilitating enormous invasion of privacy will actually make this any less likely, by reducing the risk of the gun and/or the individual willing to use it being on the plane in the first place. Given that right now airports don't even scan baggage properly, and reporters have walked onto unlocked planes in "secure areas" of airports in the middle of the night, I'm not convinced.
Slashdot Mirror
That, and things like the half-billion pound deal the National Health Service just struck with Microsoft to supply software for them for the next nine years (IIRC). Once you've got that sort of momentum in a small organisation like the NHS (Europe's largest single employer, for those who don't know) it's very hard to change course.
And you get (-1, Just Plain Wrong) for failing to notice half a million prior Slashdot posts, all explaining that the points would stand independently, so if claim 1 is granted, the programming language doesn't matter. :-)
Hmm... I'm starting to see why he's the most spammed person in the world now...
But hey, we seem to have Slashdotted the USPTO(!), so maybe an inadvertent and self-inflicted DDoS attack on Bill G's e-mail is next on the roll?
Of course, if you used a real programming language, you could just use something like
and tweak your alternative language appropriately. :-)
Was going to mod you, but then wasn't sure whether you should be a troll, flamebait, insightful or interesting, so thought I'd reply instead. :-)
It may (or may not) only be in those heads, but it's a good bet that they do sincerely believe it.
All the usual kindergarten statistical mistakes frequently get made by both sides in this debate, particularly confusing correlation with causation. However, the RIAA execs can see the same studies as everyone else. Contrary to popular opinion in some parts, they probably didn't get to those positions by being stupid either, so they're going to be well aware of the negative PR value of their legal campaigns, and the costs of all the lawyers' time to push them.
Now, if those execs could see that allowing on-line distribution would really make them more money, or had a negligible effect on sales, they would be promoting it or ignoring it. They are trying to maximise their organisations' profits, and you don't do that by spending who knows how much on legal battles that don't help you, or by annoying significant fractions of your potential customer base without good cause.
Hence, whatever those of you who rip music illegally may choose to believe in order to justify breaking the law, it's a good bet that the RIAA execs really do believe that the illegal song-swapping is hurting their business.
Obligatory note: in most jurisdictions, that is at best an assumption that has not been tested in court.
IANAL, but YHBT.
Well, there you go, see. If you had to carry an ID card as well, shops could stop that dubious practice and ensure the integrity of their data, making the world a better place for us all. Go Blunkett!
The surprising thing here is that nobody seems to be considering that there are more than two concepts at work here: sure you've got the "total" and the "money to add", but you also have the operation of adding two monetary values together, and the operation of assigning that result to yield a new total.
It doesn't matter whether you call the summation operation "+=" or "addTo" or "funkyTypeConvertingSummationAlgorithm". The operation is dependent on both the total and the amount, or more precisely on how their values are represented. There could be complications, perhaps due to type conversion issues: not just the obvious double vs. float type of thing, but for example the possibility that the amounts are value-currency pairs and exchange rates need to be considered.
Until you've sorted out where responsibility for this sort of operation should lie within your design, messing around with whether the function that does it is a method of this class or that one (or a non-member function in a language that allows them) is running before you can walk.
Do you often write a shopping application, and then find that the items for sale no longer have a price? Ensuring that the Price type is user-defined (if only as a synonym for double at first) should be plenty of future-proofing for now.
Newsflash: adding vast amounts of clutter around a simple concept does not make code either more robust or easier to maintain. Your design commits the cardinal sin of over-engineering based on a hypothesised future change requirement. You can't possibly know whether all that extra rubbish will make a future change easier, because you don't know what the change will be yet. However, you can guarantee that writing all the additional clutter will take longer, leave more scope for bugs, and make the code harder to understand if it does turn out that maintenance is needed later on. This sort of ivory tower theory is exactly why so much OOP code is unmaintainable junk in practice.
When I first read that, I assumed you were joking, and had just made that up as an absurd example to exaggerate the author's point. Then I read TFA, and realised that Holub himself advocated exactly that. Talk about getting your priorities completely wrong!
Getters and setters are not "evil". They are a design choice, as Holub himself acknowledges. If you have a lot of these for a particular class, this is often symptomatic of a confused design, but the author missed the point here. The bits you're supposed to hide are the individual aspects of an object's state that must satisfy various invariant conditions. It doesn't make sense to change these independently, because you might violate that invariant. Hence, you only provide operations on the class that change them collectively such that they still satisfy the required invariant conditions.
However, if something can be changed in isolation without violating any invariants, there's no harm in providing a mutator method to do it. That applies up to and including classes with no invariants ("structs") where you can sensibly modify any aspect of the state in isolation. Moreover, if some aspect of state has a meaning in isolation, there is no harm in providing an accessor method to look up that state, even if you wouldn't allow it to be changed directly because of invariant constraints.
Confusing this with the idea that an object should be the only thing that can do anything with itself (such as drawing itself on a screen) demonstrates a spectacular failure to understand the underlying issues here. In fact, it's easy to show this: consider an operation where two or more user-defined types are involved, and you can't restrict all the knowledge about each object to that object and still perform the operation. Attempting to do so often results in exactly the problem with Holub's "draw thyself" example: it tightly binds two separate subsystems, forcing one class to live in both of them, with all the attendant spaghettiness that brings.
Now, Holub clearly realises that mixing UI code with business logic has unfortunate problems. He can protest about inner classes and facade patterns all he likes, but the fundamental design concern -- coupling the UI system to a data-handling system -- is still there. The only way to break the bad coupling is to separate out the facade code or whatever from the original class, and put it in a UI-based layer where it belongs. Of course, that probably requires using some form of accessor methods, which takes up back to where we started.
Who is this guy anyway, and why do some people here think he's good at this stuff? I honestly haven't heard of him before, and I'm fairly open-minded, but I'm not forming a good impression from reading a couple of his articles that people have cited in this thread.
I agree that composition should often be favoured over inheritance, but I think there are several reasons for this. The bottom line is that inheritance is most useful as a mechanism for allowing implicit type coercion via polymorphism. If you don't need to use polymorphism, inheritance is just another tool for organising your code, and it's often over-used in that context where simpler things like composition would avoid cluttering the class hierarchy, issues with anonymous base subobjects that could be named explicitly if they were members, etc.
Indeed. I couldn't think of any other language that used <symbol>NE<symbol> for unequality, so I figured they got the punctuation mixed up. :-)
Finally, someone gets the point. :-)
Programming languages that allow writing high level code using concepts close to the application domain are simply more powerful than those that force the programmer to convert between the application domain and the computational facilities of the language all the time. Some languages support writing higher level code this way much better than others, and this is where a lot of the research behind the next generation of languages should be going.
I'd rather read something like
apply (set_nectar 0) flowers
Assuming a suitable functional-style language where it's well-defined, this is a clear and concise instruction, unlike the example phrase.
It's a pun on programming languages.
Some use the symbol = for equality, as in a=b is true if a and b are equal. Others use = for assignment to change a variable's value, and so use == for equality, so the above test would become a==b.
The -NE- is a dig at FORTRAN programmers, I assume. (NE = not equal.)
What are you saying? Natural language on /. is da bom. L337sp33k R0x0rz m8!
You're right. I prefer "yielding" myself, or perhaps "motivating" on a light day.
Then again, on the principle of never using a word where a polysyllabic construct will do, we could employ "entering the result into".
Then again again, if I may misquote Disraeli, perhaps I'm just inebriated with the exuberance of my own verbosity now.
Hmm. Friday must be early this week.
OK, now please breathe deeply, step back, cut the implied ad hominem attacks, and think.
The problem here is not the malware, unless a patch in SP2 is intended to remove that malware. The malware is, well, "mal", but it was before anyway. The problem is that installing SP2 on many systems is making the situation worse. Please see my reply to the AC, and note the trivial steps that could be taken to fix most of the mess in the situation you guys are describing. Also consider that if installing SP2 results in more downtime than all the security flaws in recent history, as has been the case for many of the people I know who've been brave enough to try it, maybe that's not progress.
Then you might like to check the numerous tales of woe from technically competent people whose systems were swept for the usual gremlins before the install, but who still had their OS taken out. Blaming the mess entirely on malware is a cop-out, unless you consider installing the only drivers available for numerous hardware devices, which worked fine prior to SP2, to be installing malware on your system.
Not in 100% of cases, but at the very least they shouldn't make those systems any worse. By the arguments people are giving in reply to my previous post, no security patch can ever install reliably, yet strangely, many have until this point.
For a start, Windows XP is supposed to have filesystem protection in place to prevent permanent changes to key Windows system files. This was one of the much-hyped benefits of upgrading, if you recall. If this has been circumvented, Microsoft must at least know the correct checksums etc. for all the key system files in their unmodified state.
At the very least, following the "do no harm" policy, each included patch in the SP could check whether the previous versions of the files it's changing were unmodified, and issue a warning rather than messing around trying to install over bad starting data in that case. That alone would probably prevent a lot of the problems.
Taking that to its logical conclusion, it would be hard to compromise a system without affecting any key files at all. Why can't the update include checksum information for all the key system files, check them all at the start of installation, and abort with a suitable warning rather than proceeding if the system has been compromised? It's not as though it's a small, modem-friendly download and they're worried about file sizes.
Come on guys, this isn't rocket science, it's kindergarten. Failing to read page one of the manual is no excuse for delivering an update to such essential software that takes out something like 30% of your installed base according to early adopters. I could understand the odd slip up, some particularly clever malware or a human error among hundreds of fixes, but we're talking about thousands and thousands of installations being wrecked here.
ROFLMAO. I didn't know Ian Hislop read Slashdot. :-)
They'll support it as long as megacorps are refusing to upgrade their desktops to SP2 because of all the instability problems. I work for one, and we're all under strict orders not to download the update until it's been properly checked out by our IT guys. Go on, tell me you haven't heard that from millions of others as well. :-)
It's just like dropping support for old versions of Windows itself: MS would love to, but since they've borked the update process and their major customers aren't riding with them, they can't do so without seriously damaging their business.
So let me get this straight... Microsoft's ueber-update to improve Windows security works great, as long as you install it on a machine that was already secure enough not to have malware/spyware on it?
That's a fair point, but I would ask whether the problem here is the usability benefit of allowing viewing a different type of document without fuss, or the feature creep of allowing just viewing a document to run arbitrary code that can do any harm to your computer.
I couldn't agree more. In fact, I'd go as far as to say that usability is a necessary minimum requirement for security. After all, a very large proportion of attacks succeed because of a simple human failure, not an electronic one.
For example, if banks would stop constantly requiring me to remember seventeen different ID numbers, "memorable" words and phrases, I might notice the e-mail they send out reminding me not to give out my PIN number to anyone else.
On a more techie level, languages where it's easy to code properly make careless errors like allowing buffer over-runs or SQL injection less likely.
At the heart of good usability are principles like KISS and not giving the user unnecessary chances to go wrong. These don't exclude giving the user power, but what better partner for keeping a user safe than not giving them silly chances to do dangerous things?
Unfortunately, the answer is clearly yes: guy points gun at side of plane and fires, cabin decompresses explosively, plane crashes, and everybody dies. No magic or cunning planning required.
The relevant question must surely be whether facilitating enormous invasion of privacy will actually make this any less likely, by reducing the risk of the gun and/or the individual willing to use it being on the plane in the first place. Given that right now airports don't even scan baggage properly, and reporters have walked onto unlocked planes in "secure areas" of airports in the middle of the night, I'm not convinced.