Before we let a random person into our country, we need to verify his identity to make sure he's not a criminal or terrorist.
Of course. And to do that you take his fingerprint and look for the lines crossing to make a big "T" in the middle, right? Seriously, what on earth makes you think you can reliably identify someone in this way, or that having done so, you will reliably be able to determine whether or not they have criminal intent?
Biometrics are one way to do this since documents can and will be forged.
So will biometric ID, not that it matters since the mismatch rates for most of the proposed technologies are so bad that they may well prove worse than useless in practice.
There are a lot of people who hate us, perhaps justifiably.
Indeed. The US is the only country I have actively declined to visit in recent years when I had a reasonable opportunity to do so. Would you like to guess why? (Hint: It has nothing to do with disliking the US in general or American citizens, and everyone to do with not trusting the US government and not wanting to subject myself to their draconian border controls.)
Given a tight border, there'll be (in theory) much less of a need for Draconian domestic laws.
You haven't been keeping up with who's been committing the major acts of terrorism in recent years, have you? (Hint: Many of them were citizens of the nation they attacked, and carrying genuine ID, too.)
They'd be trying to force ID cards on the whole population
Fortunately for our way of life, trying is not the same as succeeding.
Seriously, the last proper poll we discussed here, by YouGov I think, had a small overall majority agreeing with some sort of ID card in general, but a heavy majority not believing in most of the claimed benefits of the actual scheme proposed by the government and agreeing that the scheme was dangerous in various ways. According to other polls there are easily enough people in my country who will actively refuse to be catalogued like this on principle that it will never fly. Combine that with a population very sceptical about the whole thing and attempting to force it through is going to become political suicide real soon now.
Thanks for some additional FUD. Flash supports bookmarking and has for years. Just because people don't know how to do it doesn't mean it can't be done.
You can support this sort of thing with AJAX if you're clever enough, too. But the point is, most people don't, which means it isn't worth very much right now.
Perhaps some people will care because (a) they have the slightest grasp of economics, (b) they don't support breaking the law and not compensating someone fairly for their work, and/or (c) they're not so blinded by the letters DRM that they can't see it's the people who have paid good money for the e-books who are being screwed the most and not the person who supplied them?
The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it.
Well, considering that AJAX is used on only a tiny proportion of web sites, and often not to particularly good effect, I'd say that's a bit of a silly claim. In any case, AJAX often suffers from the same flaws as pseudo-web technologies like Flash before it: lack of bookmarkability, breaking back buttons, etc. These are far more likely to doom it than any random security flaw.
I view DRM scheme creators in a similar light to anti-virus software makers: their task is never-ending because they are attacking the symptoms of a problem, not the problem itself and it's a very thankless job.
Flawed alternative problem in case 2: No technological solution exists for a social problem.
Should software 'just work', or are users too lazy?
Yes, and usually (but it depends on the market).
Of course, there are a lot of things that aren't excluded by those constraints. For example, software may be simple-but-effective or complicated-but-powerful, yet still "just work" for its desired target audience. It can lead new users clearly and effectively through the more complicated functionality, yet still provide a streamlined interface for experts who already know the software and don't need their hand holding. And most important of all, easy-to-use does not imply under-powered, and powerful does not necessarily mean you have to present everything in a convoluted and cluttered interface. Desirable traits are rarely mutually exclusive.
If I'm in danger of successfully suing one company, do you think the other companies in the same industry are going to line up with signs saying "Sue us too!"?
That's a very shortsighted view. We had defamation laws for a reason, and that reason is that while sticks and stones will break your bones, words most certainly can hurt you as well. I don't see why the actions of SORBS -- which sound like a pretty obvious protection racket looking at the comments in this thread -- wouldn't lead to a very fast court case with a very negative result for the operators of SORBS.
Yes, combination techniques are definitely the way to go. Any one RBL (or content test for that matter) can be fooled or make a mistake. Fooling many such tests or accidentally hitting all of them is much less likely.
Looking at the filtered headers for a system I admin, which catches nearly all incoming spam and very rarely (perhaps once in six months) gets any false positives, the vast majority of the real spam is picked up by several RBLs, and then fails several of the content tests as well.
There is simply no need to rely on any single point of failure in spam control, and given the notorious unreliability of several major RBLs, it would be insane to do so.
The problem with this argument is, as usual, collateral damage. While there may be a spammer using Wanadoo somewhere, there are also many legitimate users who will be caught in the blast radius.
Before anyone replies with the usual holier-than-thou "Well they should change their ISP then", please consider that this is not trivial for a lot of people. Moreover -- and here's the real kicker -- pretty much every ISP is "spam-friendly" because, as the recent spam wave has demonstrated all too clearly, pretty much every ISP has lots of compromised machines running on it, and those machines can be abused without the informed consent of either their owner or the ISP.
Funnily enough, that's pretty much my reaction to that sort of recruitment process as well. I don't care if you're $BIG_NAME_EMPLOYER. I'm good at what I do, and plenty of good places to work will hire me in any moderately employee-friendly market. I have better things to do than jump through apparently pointless hoops for extended periods of time because one particular company is incapable of making a reasonably quick decision about its interviewees.
I think we're in pretty close agreement (even on the digression about new:-)).
In general, I tend to think that in practice, very uniform or punctuation-free languages actually become harder to read, just as those with too much clutter do. I also think the places you need punctuation differ depending on the programming style: a lot of functional programming languages don't use () in a mathematical way to denote function calls, for example, while it's common to do so in procedural languages.
Just the type of constructive critism a language needs. If it has problems don't include it.
Considering how often exactly that position is taken by adovcates of languages like Java and now D, at the expense of alternatives like C++, your position is rather hypocritical.
But seriously, how would you fix the issue elegently it without taking out the sub-constuctors? Can you provide examples?
Well, I won't pretend I can design a robust OO initialisation mechanism for a hypothetical language in a couple of minutes, but as a starting point: C++ provides the useful concept of initialiser lists in class constructors, which specify expression(s) to be used to initialise each individual data member or base class, and if you're going to invent the concept of a sub-constructor, can't such special functions mimic the initialiser list concept and define the initialiser expressions for a subset of the data members and/or base classes subobjects? Then you can have a constructor delegate some or all of the initialisation to any of these subconstructors without breaking your general initialisation semantics, and if you want, you can default-initialise anything before you enter the body of your main constructor if it hasn't been addressed explicitly already.
So are you really Walter, Mr AC, or just pretending to be?
In any case, you're right that programmers should have an open mind. You might start by opening yours to the possibility that I (and, I notice, several others posting in this discussion now) do actually have a clue about the real world requirements of numerical analysis, and that it is possible that a little extra precision really isn't that high a priority. Once again, remember that we're not saying it has no merit at all, nor that there aren't applications that don't benefit significantly from it, just that for most applications, it isn't that important in the grand scheme of things.
16bit is a huge amount more precisions. Until you start having 64bit precision problems you can't see the whole picture.
ROFLMAO. I have spent much of my working life dealing with those problems: devising ways around them, coping with awkward boundary cases, quantifying the loss of precision during algorithms, assessing whether that loss is within acceptable tolerances. And you know what? If I had an extra few bits to play with, I'd have exactly the same issues to deal with, for exactly the same reasons.
I'm not surprised. Few engineers understand the problems with accumulated roundoff error.
The arrogance of that statement defies belief!
Do you really believe that you understand the mathematical requirements of computer-aided design software better than the entire CAD industry?
I'm also really curious about how you, as a man who's spent the last several years writing compilers, knows more about state-of-the-art numerical analysis techniques than an office full of highly-qualified and experienced people who work in this field every day.
Not everyone who is a competent physicist, scientist, or engineer, is also a top expert in floating point.
Indeed, and the smart ones hire people like me to explain the necessary basics to them for a while, or to consult on the technical details of their software as necessary.
Oh, I agree entirely that parsability by machine is not the first priority for languages -- far from it, in fact.
However, I think there is a strong correlation between easily machine-parsable languages and languages that don't have special cases and traps for the unwary all over them, probably because simplifying the formal grammar tends to help both goals.
Consider Perl, for example: it's often criticised for being "write-only" on account of the complexity of its syntax, and often for having quirks and only a reference implementation to define it rather than a formal standard. It's also a nightmare for other tools to parse for exactly the same reasons, and consequently it has relatively poor support from tools other than those that come with it by default.
Consider C++: it's often been criticised in recent years for the cumbersome syntax of its templates, and to give credit where it's due, the D language does seem to do this rather more neatly. C and C++ are also often criticised for their frankly bizarre declaration syntax, particularly where pointers, arrays and functions are present in combination. The classic is the difference between
MyClass c;
which defines an object c of type MyClass and default-constructs it, and
MyClass c();
which defines a function c that takes no parameters and returns an object of type MyClass. This sort of nonsense is just as much a pain for the human reader as for the language tools that need to disambiguate.
Other languages have similar issues. Thus I don't see that simplifying the formal structure of language to make tool development easier is necessarily in conflict with making the language easier for humans to use. If anything, the opposite is true.
Re:Smoking bans: reducing freedom, or increasing i
on
2006's Bill of Wrongs
·
· Score: 1
I suppose we will have to agree to disagree. I am quite glad the government hasn't yet made that a crime as well.
1. The recent Intel 64 bit floating point support is all about speed.
In the past year, I've lost count of how many performance bugs we've had from our customers. Many of them have unrealistic expectations, but their focus on speed is clear. Can you guess how many of them said our algorithms weren't accurate enough? Hint: 0.
2. I'm well aware that greater precision isn't going to help with a 1000*1000 element matrix inversion, that what is needed is a better algorithm. Those better algorithms, however, are non-obvious, and great care and expertise has gone in to developing them. That doesn't help one whit, however, if you're doing a complex calculation that isn't a matrix inversion using a library built by an expert.
So your argument in favour of 80-bit is that incompetents who need high-accuracy calculations benefit from it? Well, that may be true, though it's clearly a false sense of security, and it's hardly a compelling argument for the importance of 80-bit calculation to the field of numerical analysis.
Please remember, I'm not arguing that, other things being equal, 80-bit isn't better than 64-bit. Of course more precision is helpful for some fields. I'm simply arguing that the extra 16 bits have a relatively low priority for many people working in the field, for whom 64-bit is already good enough.
3. Windows, Linux, and MacOS are on x86 boxes that have the 80 bit FPU available. Once again, if your customer has paid for an FPU with 80 bits, why should his (not your) results be dumbed down to the worst FPU you support?
Linux runs on lots of things, as do some versions of Windows.
Um, there's a lot more to aircraft part design than CAD drawings. Your comment shows you really don't know what's involved.
I gave a single illustration to show that even 8 decimal sig figs can be accurate enough for real applications, and you infer from this that I know nothing about anything but CAD? Interesting conclusion jump. Wrong, but interesting.
Portable wrong answers don't help one's design work.
And this is where your whole argument falls apart every time. Our answers are not wrong. They may be less accurate, but they are still correct to the accuracy specified by our customers, and typically rigorously proven to be so. No-one would use our stuff without such guarantees. More accuracy than that, at the expense of speed or portability, simply is not something our customers tell us they want.
Again, I have never disputed that, in some niches, some extra precision really will make a useful difference. Of course different projects have different priorities. But IME, working in a variety of high-precision industrial environments during my career from the aforementioned CAD stuff to metrology analysis software, there is usually a point beyond which further accuracy isn't worth a lot, and other features (such as being able to perform sufficiently accurate computations in real-time or close to it) are more important.
In this context, while using 80-bit floating point may be a mark in D's favour, it is clearly vastly less significant than many of the other categories (and indeed notable omissions) in the checklists linked from the original Slashdot story.
This would be a useful addition to help coders more accurately express correct behaviour, and whose infractions would be detected at the eariest time, i.e. compile time. But does the lack of this functionality condemn the D language?
It doesn't condemn D, but if you're going to put your product forward as a superior replacement to an established player, it's a good idea not to be qualitatively worse than that player...
However, if you are wondering how a constructor down the 'chain' can detect if a data member has already been initialized or not, then this issue is not restricted to D. How would such a sub-constructor know that, regardless of the language used, if there wasn't a concept of an 'uninitialized' value which is automatically set at run-time?
This isn't a problem if your language doesn't support sub-constructors in the first place. Again, it's not really fair to say that other languages would have the same problem in the same situation, when the situation is one of D's making.
Slashdot Mirror
Of course. And to do that you take his fingerprint and look for the lines crossing to make a big "T" in the middle, right? Seriously, what on earth makes you think you can reliably identify someone in this way, or that having done so, you will reliably be able to determine whether or not they have criminal intent?
So will biometric ID, not that it matters since the mismatch rates for most of the proposed technologies are so bad that they may well prove worse than useless in practice.
Indeed. The US is the only country I have actively declined to visit in recent years when I had a reasonable opportunity to do so. Would you like to guess why? (Hint: It has nothing to do with disliking the US in general or American citizens, and everyone to do with not trusting the US government and not wanting to subject myself to their draconian border controls.)
You haven't been keeping up with who's been committing the major acts of terrorism in recent years, have you? (Hint: Many of them were citizens of the nation they attacked, and carrying genuine ID, too.)
All of which is lovely, until someone makes a mistake.
And then your life is shattered if it's your fingerprint they mismatched.
Do you think your government would ever make such a mistake?
Fortunately for our way of life, trying is not the same as succeeding.
Seriously, the last proper poll we discussed here, by YouGov I think, had a small overall majority agreeing with some sort of ID card in general, but a heavy majority not believing in most of the claimed benefits of the actual scheme proposed by the government and agreeing that the scheme was dangerous in various ways. According to other polls there are easily enough people in my country who will actively refuse to be catalogued like this on principle that it will never fly. Combine that with a population very sceptical about the whole thing and attempting to force it through is going to become political suicide real soon now.
You can support this sort of thing with AJAX if you're clever enough, too. But the point is, most people don't, which means it isn't worth very much right now.
Perhaps some people will care because (a) they have the slightest grasp of economics, (b) they don't support breaking the law and not compensating someone fairly for their work, and/or (c) they're not so blinded by the letters DRM that they can't see it's the people who have paid good money for the e-books who are being screwed the most and not the person who supplied them?
Well, considering that AJAX is used on only a tiny proportion of web sites, and often not to particularly good effect, I'd say that's a bit of a silly claim. In any case, AJAX often suffers from the same flaws as pseudo-web technologies like Flash before it: lack of bookmarkability, breaking back buttons, etc. These are far more likely to doom it than any random security flaw.
Bruce made a great hero, but personally I'm betting on the other guys. :-)
Flawed alternative problem in case 2:
No technological solution exists for a social problem.
Actually, according to TFA it's only 60% (9 out of 15 correct), though he claims that three of the others may also come good in the immediate future.
Yes, and usually (but it depends on the market).
Of course, there are a lot of things that aren't excluded by those constraints. For example, software may be simple-but-effective or complicated-but-powerful, yet still "just work" for its desired target audience. It can lead new users clearly and effectively through the more complicated functionality, yet still provide a streamlined interface for experts who already know the software and don't need their hand holding. And most important of all, easy-to-use does not imply under-powered, and powerful does not necessarily mean you have to present everything in a convoluted and cluttered interface. Desirable traits are rarely mutually exclusive.
How do you figure that out?!
If I'm in danger of successfully suing one company, do you think the other companies in the same industry are going to line up with signs saying "Sue us too!"?
That's a very shortsighted view. We had defamation laws for a reason, and that reason is that while sticks and stones will break your bones, words most certainly can hurt you as well. I don't see why the actions of SORBS -- which sound like a pretty obvious protection racket looking at the comments in this thread -- wouldn't lead to a very fast court case with a very negative result for the operators of SORBS.
Yes, combination techniques are definitely the way to go. Any one RBL (or content test for that matter) can be fooled or make a mistake. Fooling many such tests or accidentally hitting all of them is much less likely.
Looking at the filtered headers for a system I admin, which catches nearly all incoming spam and very rarely (perhaps once in six months) gets any false positives, the vast majority of the real spam is picked up by several RBLs, and then fails several of the content tests as well.
There is simply no need to rely on any single point of failure in spam control, and given the notorious unreliability of several major RBLs, it would be insane to do so.
The problem with this argument is, as usual, collateral damage. While there may be a spammer using Wanadoo somewhere, there are also many legitimate users who will be caught in the blast radius.
Before anyone replies with the usual holier-than-thou "Well they should change their ISP then", please consider that this is not trivial for a lot of people. Moreover -- and here's the real kicker -- pretty much every ISP is "spam-friendly" because, as the recent spam wave has demonstrated all too clearly, pretty much every ISP has lots of compromised machines running on it, and those machines can be abused without the informed consent of either their owner or the ISP.
Funnily enough, that's pretty much my reaction to that sort of recruitment process as well. I don't care if you're $BIG_NAME_EMPLOYER. I'm good at what I do, and plenty of good places to work will hire me in any moderately employee-friendly market. I have better things to do than jump through apparently pointless hoops for extended periods of time because one particular company is incapable of making a reasonably quick decision about its interviewees.
Sounds like you'll be very good at hiring salesmen (or con artists) but pretty much trusting to luck as far as hiring technically good people goes.
You may choose to think that, but the interesting question is: how do you know?
Well then I considerify myself a dictation only in a hypertheatrical situification.
Love, George.
I think we're in pretty close agreement (even on the digression about new :-)).
In general, I tend to think that in practice, very uniform or punctuation-free languages actually become harder to read, just as those with too much clutter do. I also think the places you need punctuation differ depending on the programming style: a lot of functional programming languages don't use () in a mathematical way to denote function calls, for example, while it's common to do so in procedural languages.
Considering how often exactly that position is taken by adovcates of languages like Java and now D, at the expense of alternatives like C++, your position is rather hypocritical.
Well, I won't pretend I can design a robust OO initialisation mechanism for a hypothetical language in a couple of minutes, but as a starting point: C++ provides the useful concept of initialiser lists in class constructors, which specify expression(s) to be used to initialise each individual data member or base class, and if you're going to invent the concept of a sub-constructor, can't such special functions mimic the initialiser list concept and define the initialiser expressions for a subset of the data members and/or base classes subobjects? Then you can have a constructor delegate some or all of the initialisation to any of these subconstructors without breaking your general initialisation semantics, and if you want, you can default-initialise anything before you enter the body of your main constructor if it hasn't been addressed explicitly already.
So are you really Walter, Mr AC, or just pretending to be?
In any case, you're right that programmers should have an open mind. You might start by opening yours to the possibility that I (and, I notice, several others posting in this discussion now) do actually have a clue about the real world requirements of numerical analysis, and that it is possible that a little extra precision really isn't that high a priority. Once again, remember that we're not saying it has no merit at all, nor that there aren't applications that don't benefit significantly from it, just that for most applications, it isn't that important in the grand scheme of things.
ROFLMAO. I have spent much of my working life dealing with those problems: devising ways around them, coping with awkward boundary cases, quantifying the loss of precision during algorithms, assessing whether that loss is within acceptable tolerances. And you know what? If I had an extra few bits to play with, I'd have exactly the same issues to deal with, for exactly the same reasons.
The arrogance of that statement defies belief!
Do you really believe that you understand the mathematical requirements of computer-aided design software better than the entire CAD industry?
I'm also really curious about how you, as a man who's spent the last several years writing compilers, knows more about state-of-the-art numerical analysis techniques than an office full of highly-qualified and experienced people who work in this field every day.
Indeed, and the smart ones hire people like me to explain the necessary basics to them for a while, or to consult on the technical details of their software as necessary.
Oh, I agree entirely that parsability by machine is not the first priority for languages -- far from it, in fact.
However, I think there is a strong correlation between easily machine-parsable languages and languages that don't have special cases and traps for the unwary all over them, probably because simplifying the formal grammar tends to help both goals.
Consider Perl, for example: it's often criticised for being "write-only" on account of the complexity of its syntax, and often for having quirks and only a reference implementation to define it rather than a formal standard. It's also a nightmare for other tools to parse for exactly the same reasons, and consequently it has relatively poor support from tools other than those that come with it by default.
Consider C++: it's often been criticised in recent years for the cumbersome syntax of its templates, and to give credit where it's due, the D language does seem to do this rather more neatly. C and C++ are also often criticised for their frankly bizarre declaration syntax, particularly where pointers, arrays and functions are present in combination. The classic is the difference between
which defines an object c of type MyClass and default-constructs it, and
which defines a function c that takes no parameters and returns an object of type MyClass. This sort of nonsense is just as much a pain for the human reader as for the language tools that need to disambiguate.
Other languages have similar issues. Thus I don't see that simplifying the formal structure of language to make tool development easier is necessarily in conflict with making the language easier for humans to use. If anything, the opposite is true.
On that, at least, we can agree entirely. :-)
In the past year, I've lost count of how many performance bugs we've had from our customers. Many of them have unrealistic expectations, but their focus on speed is clear. Can you guess how many of them said our algorithms weren't accurate enough? Hint: 0.
So your argument in favour of 80-bit is that incompetents who need high-accuracy calculations benefit from it? Well, that may be true, though it's clearly a false sense of security, and it's hardly a compelling argument for the importance of 80-bit calculation to the field of numerical analysis.
Please remember, I'm not arguing that, other things being equal, 80-bit isn't better than 64-bit. Of course more precision is helpful for some fields. I'm simply arguing that the extra 16 bits have a relatively low priority for many people working in the field, for whom 64-bit is already good enough.
Linux runs on lots of things, as do some versions of Windows.
I gave a single illustration to show that even 8 decimal sig figs can be accurate enough for real applications, and you infer from this that I know nothing about anything but CAD? Interesting conclusion jump. Wrong, but interesting.
And this is where your whole argument falls apart every time. Our answers are not wrong. They may be less accurate, but they are still correct to the accuracy specified by our customers, and typically rigorously proven to be so. No-one would use our stuff without such guarantees. More accuracy than that, at the expense of speed or portability, simply is not something our customers tell us they want.
Again, I have never disputed that, in some niches, some extra precision really will make a useful difference. Of course different projects have different priorities. But IME, working in a variety of high-precision industrial environments during my career from the aforementioned CAD stuff to metrology analysis software, there is usually a point beyond which further accuracy isn't worth a lot, and other features (such as being able to perform sufficiently accurate computations in real-time or close to it) are more important.
In this context, while using 80-bit floating point may be a mark in D's favour, it is clearly vastly less significant than many of the other categories (and indeed notable omissions) in the checklists linked from the original Slashdot story.
It doesn't condemn D, but if you're going to put your product forward as a superior replacement to an established player, it's a good idea not to be qualitatively worse than that player...
This isn't a problem if your language doesn't support sub-constructors in the first place. Again, it's not really fair to say that other languages would have the same problem in the same situation, when the situation is one of D's making.