Is it expected that one should monitor the "mention" tab so you can talk with people you don't follow (even though people watching your timeline will only see your side of the conversation).
Almost all Twitter clients notify you in some way that you've been "mentioned" (that is, your @username is in a message someone posted). You don't really watch someone's timeline. You follow them and watch their stream of broadcasted messages, which does not include messages beginning with "@[someone who isn't you]".
If you include "@kstrauser", in a message, I'll see it. If your message starts like "@kstrauser Hi from Slashdot!", none of your followers will see it unless they also follow me or unless they're directly browsing your timeline (which isn't the common way of using Twitter).
I've tried to see the point in Twitter, but apart from making it easier to have group conversations by SMS I really can't work out what it is supposed to achieve.
To illustrate: I went to a convention a couple of weeks ago and started following quite a few interesting people. They didn't have to do anything to push their comments to me, so it that sense it's like they all run their own mailing lists or RSS feeds. Some of their comments led to conversations, and at that point the analogy stops.
The only other people who see those conversations are Twitter users who follow both that person and me. That is, the people who follow me for other reasons aren't dragged into chats I'm having with someone I met at a technical conference. The people who follow the person I'm chatting with don't have to listen to their friend discussing geek stuff with someone they don't know. However, people who follow both of us do get to listen in. This is handy because if they like both of us, chances are good they'll be interested in what we're talking about (and can jump into the conversation at any time).
The exception to the "not having to listen to irrelevant conversation" rule is when someone I'm following "re-tweets" another user, so that I see a message from someone I don't know but which one of my friends thought was worthwhile to pass along. If I like what they've said, with a click or two I can start following that new person.
It has the interactivity of mailing lists without the distractions of listening to a bunch of side chatter. It has the convenience of a centralized repository of millions of RSS feeds you can follow or unfollow with a single click or tap but without the inherent one-directional "broadcasting" feel. Add into that a common interface that's optimized for the task of handling all the incoming messages and managing relationships.
Twitter is - to me - one of those things that looks bad on paper, as though it couldn't possibly work. In practice, I find it a pretty nice and convenient platform for meeting and interacting with new people.
I think MS made a big mistake in not also recognizing this and building their UI and OS around this fact.
I'd wager that MS recognizes this perfectly well, but isn't big reminding users that there's a lot of stuff you can do in the world without desktop apps and their related infrastructure.
17 USC 101: "A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result."
I know you mean well, but MP3s aren't computer programs, even by that definition. MP3s are data without any decoding instructions. They are no more programs than is a phonebook.
the Australian Internet Industry Association. According to AIIA's Peter Coroneos, vendors need to intervene at the network level and provide security tools at multiple levels to help secure people from the variety of threats that are emerging."
[Industry] spokesman declares that life as we know it is about to end, and that only [industry] is in a position to protect us. Given the proper financial incentives, of course, and made mandatory by legislation "for our own good" if need be.
So, you think it's okay for jurors to, on their own, access information pertinent to the case, without giving the defense or prosecution an opportunity to examine that information and discuss it in court?
Kind of, yeah. I mean, I'm coming into the situation with a few decades of education and experience, and I don't think I should be expected to turn off my own knowledge just because the attorneys haven't had a chance to psychoanalyze and catalog me. What's the difference between something I learned last year versus something I learn next week, other than the square on the calendar in which I learned it?
These aren't new ideas. Said Buddha:
“Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it.”
Say I'm in a jury and there's a question of how long something takes to fall. The prosecutor's theory depends on his stated fact that if an object is dropped from twice as high, then it will take twice as long to hit the ground. Well, I personally know that's wrong. Not matter of opinion wrong, but statement of fact wrong. Am I expected to sit back and accept that critical flaw without examination because it was presented as evidence? I don't know; maybe the rules of being on a jury say exactly that. I'm not going to do it, though.
And at that point, what's the difference between me thinking "that's not what I learned in undergrad!" and "wait, that doesn't sound right. I'm going to Google it.", except that I walked into the courtroom with the former?
What I really think we need is a question-and-answer session at the end of a trial where jurors get to ask questions. "Hey, Prosecutor: that's not how acceleration works. How do your respond to that criticism?" How useful would scientific peer review be if the worth of your paper was decided by a show of hands vote without any opportunity for you to address any concerns, especially if the rules of publishing were such that you only get one chance ever in your life to submit a given paper? What if your peers knew that and were therefore likely to give you the benefit of the doubt on some of their (in their opinion at that moment) minor objections?
You think people should be convicted based on secret information their attorneys didn't even know about? Nice...
Or acquitted. Yes, yes, I do. Maybe the lawyers would prefer that I walked into the jury box with a blank slate of a mind that they can fill in with whatever statements of fact they see fit, but that's not what they're getting.
If your deployment environment is Linux, then get a Linux box to develop your code.
I couldn't disagree more. Almost all of my code is deployed on FreeBSD servers, but I'm using a Linux desktop. The advantage I see is that it keeps me from making assumptions about the underlying platform. Should we ever switch to Linux servers, the apps will still run correctly. When I'm working from home on a PPC Mac, the apps still run correctly. When I'm roaming about with my 32-bit Atom netbook, they still run correctly. When I released one program as open source, it was added to the FreeBSD (for IA64, even), Debian, and Ubuntu package repositories because it works as designed on all of those.
I do agree with your statement that expecting them to be the same is dumb. "Similar" is not "identical", and there are always surprising little differences that you have to account for. But I believe that identifying and accounting for those differences makes your code better and more robust, and those are good things.
No you wouldn't. If you truly became McAfee, you'd run around screaming "LINUX IS DANGEROUS WITHOUT ANTIVIRUS! WE SLOW YOUR COMPUTER SO YOU DON'T HAVE TO! I EAT PAINT!"
Which is still an improvement over what you'd do if you were Norton.
I wouldn't say that. Consider that in insert(), you'd have to update the list_size value. If you use (list_size==-1) as the "unknown size" flag, then you have to check for it before incrementing. Otherwise your first insert() after splice() would result in list_size==0, or empty. If you store "unknown size" as a separate bool, then you can tell insert() to always increment list_size. I couldn't even hazard a guess as to whether "conditionally increment" or "always increment" would be faster on modern hardware.
I don't know whether that's a DBAPI feature or a psycopg2 extension, but I tested that code (adapted for my own PostgreSQL table) and verified that it works exactly like you'd expect it to.
The second example was SQLAlchemy, my preferred way of never having to write another line of SQL. I know I can write complex, efficient queries if I want to. I also know that I'd rather let the computer figure it out for me.:-)
Voila. Those work, they're not hideous, and they prevent injection. To repeat the earlier idea: there's no need to write unsafe code. If you are, you're in the wrong line of work.
There's something to that, but that overhead would be sizeof(size_type)+sizeof(bool), which should add up to an insignificant overhead except in the case of a program that maintains millions of single-element lists.
Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.
If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.
Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".
I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.
I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that the flaw in my idea is that it only gives an improvement 99.9% of the time and falls back to the old behavior in the other 0.1% of cases. In every other software realm, you'd call that a successful optimization.
Unless you depend on size() being slow for some reason, in which case you're using the wrong language. But that's a different discussion.
It would be unpredictably awesome. Suppose you have a million splice() calls that insert one item each, followed by a million size() calls. If size() is O(1) and splice is O(n), that would require about a million list traversals and about 500 billion (sum([1..1,000,000])) visits to items in the list. If size() is O(n) and splice() is O(1), that would take a million list traversals and a trillion visits. In my algorithm, size would be O(n) once and O(1) every other time, for exactly one traversal and one million visits.
With my idea, splice() is always O(1). In the worst case, size() would take exactly as long as it does now, plus a single conditional to see if known_size is true or false. In the average case, size() would also be O(1). It would also conform to the C++ principal of not making you pay for what you don't use: unless you specifically call size() after splice(), both algorithms would be O(1). If you do call size() after splice(), it would be no worse than what we have today.
I'm loathe to discard simple algorithm optimizations just because they don't apply to every situation, particularly when their failure mode is just as good as the original.
Leaping into the middle of the conversation: why? It seems like you could implement caching logic like:
Initialize lists with size=0 and known_size=true.
When adding elements, if known_size=true, size+=1.
When size() is called, if known_size==true, return size. Else, set size=countedsize() and set known_size=true.
When splice() is called, set known_size=false.
Voila. size() is O(1) almost always, except immediately after a splice(). In the worst case, it'd be O(n) immediately after a splice(), but only the first time - and then it'd revert to O(1) behavior.
but only a little bit better in that they do 'projects together' which in my experience means that the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.
That's called "managing expectations", and is a wonderful introduction to their future careers for a lot of CS grads. Now go fetch me some coffee while this build finishes, would you? Thanks.
Before digital cameras, that was known as a "viewfinder": capture a still image while previewing the world through a tiny little window. Die in a fire, Kodak. You used to be great, but you've completely SCO'ed your reputation.
No, I don't believe there's such a thing as a tamper-proof odometer.
Then why should we use this instead of the car's pre-existing, Federally-mandated odometer? What is the advantage to drivers in collecting this information twice in separate devices, or to the government as related to their stated reason for wanting the information?
So you believe the correct answer is to install a second, hardened odometer that provides no benefits whatsoever to the owner. You work as a contractor, don't you?
Don't you think it's only fair if companies can't buy from companies using pirated software who sell at lower price because frankly they don't need to pay as much costs as lawful companies?
No, because the response is utterly out of proportion with the offense. Say a web guy at Foxconn brings in a pirated copy of Photoshop. Your logic would indicate that MS should be able to sue Apple for unfair competition, even though 1) Apple didn't do it, and 2) the act of piracy contributed absolutely nothing to Apple's product.
Basically, you're advocating the death penalty for a jaywalking ticket. Maybe that seems fair and just in your tiny little world, but it comes across as pretty damn insane for everyone living in reality.
Slashdot Mirror
Is it expected that one should monitor the "mention" tab so you can talk with people you don't follow (even though people watching your timeline will only see your side of the conversation).
Almost all Twitter clients notify you in some way that you've been "mentioned" (that is, your @username is in a message someone posted). You don't really watch someone's timeline. You follow them and watch their stream of broadcasted messages, which does not include messages beginning with "@[someone who isn't you]".
If you include "@kstrauser", in a message, I'll see it. If your message starts like "@kstrauser Hi from Slashdot!", none of your followers will see it unless they also follow me or unless they're directly browsing your timeline (which isn't the common way of using Twitter).
I've tried to see the point in Twitter, but apart from making it easier to have group conversations by SMS I really can't work out what it is supposed to achieve.
To illustrate: I went to a convention a couple of weeks ago and started following quite a few interesting people. They didn't have to do anything to push their comments to me, so it that sense it's like they all run their own mailing lists or RSS feeds. Some of their comments led to conversations, and at that point the analogy stops.
The only other people who see those conversations are Twitter users who follow both that person and me. That is, the people who follow me for other reasons aren't dragged into chats I'm having with someone I met at a technical conference. The people who follow the person I'm chatting with don't have to listen to their friend discussing geek stuff with someone they don't know. However, people who follow both of us do get to listen in. This is handy because if they like both of us, chances are good they'll be interested in what we're talking about (and can jump into the conversation at any time).
The exception to the "not having to listen to irrelevant conversation" rule is when someone I'm following "re-tweets" another user, so that I see a message from someone I don't know but which one of my friends thought was worthwhile to pass along. If I like what they've said, with a click or two I can start following that new person.
It has the interactivity of mailing lists without the distractions of listening to a bunch of side chatter. It has the convenience of a centralized repository of millions of RSS feeds you can follow or unfollow with a single click or tap but without the inherent one-directional "broadcasting" feel. Add into that a common interface that's optimized for the task of handling all the incoming messages and managing relationships.
Twitter is - to me - one of those things that looks bad on paper, as though it couldn't possibly work. In practice, I find it a pretty nice and convenient platform for meeting and interacting with new people.
I think MS made a big mistake in not also recognizing this and building their UI and OS around this fact.
I'd wager that MS recognizes this perfectly well, but isn't big reminding users that there's a lot of stuff you can do in the world without desktop apps and their related infrastructure.
17 USC 101: "A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result."
I know you mean well, but MP3s aren't computer programs, even by that definition. MP3s are data without any decoding instructions. They are no more programs than is a phonebook.
I get the feeling that my disabling all those update services that my HP and Toshiba laptops are bundled with can be justified better now.
You need a justification for configuring your own computer the way you like it?
the Australian Internet Industry Association. According to AIIA's Peter Coroneos, vendors need to intervene at the network level and provide security tools at multiple levels to help secure people from the variety of threats that are emerging."
[Industry] spokesman declares that life as we know it is about to end, and that only [industry] is in a position to protect us. Given the proper financial incentives, of course, and made mandatory by legislation "for our own good" if need be.
Color me shocked.
The U.S. has the highest incarceration rate in the world,
Garbage in, garbage out. Politicians make dumb laws that are prosecuted by ambitious DAs. That has no bearing on how good or bad the trial process is.
a massive problem with violent crime,
[Citation needed]
is one of only a handful of developed nations that executes its own citizens,
...in accordance with the laws passed by the legislative and executive branches.
and has a racist prison-industrial complex.
Even if that were true, what does that have to do with whether a specific defendant gets a fair trial?
Are you seriously suggesting that our legal system is "pretty good"?
Yes.
So, you think it's okay for jurors to, on their own, access information pertinent to the case, without giving the defense or prosecution an opportunity to examine that information and discuss it in court?
Kind of, yeah. I mean, I'm coming into the situation with a few decades of education and experience, and I don't think I should be expected to turn off my own knowledge just because the attorneys haven't had a chance to psychoanalyze and catalog me. What's the difference between something I learned last year versus something I learn next week, other than the square on the calendar in which I learned it?
These aren't new ideas. Said Buddha:
Say I'm in a jury and there's a question of how long something takes to fall. The prosecutor's theory depends on his stated fact that if an object is dropped from twice as high, then it will take twice as long to hit the ground. Well, I personally know that's wrong. Not matter of opinion wrong, but statement of fact wrong. Am I expected to sit back and accept that critical flaw without examination because it was presented as evidence? I don't know; maybe the rules of being on a jury say exactly that. I'm not going to do it, though.
And at that point, what's the difference between me thinking "that's not what I learned in undergrad!" and "wait, that doesn't sound right. I'm going to Google it.", except that I walked into the courtroom with the former?
What I really think we need is a question-and-answer session at the end of a trial where jurors get to ask questions. "Hey, Prosecutor: that's not how acceleration works. How do your respond to that criticism?" How useful would scientific peer review be if the worth of your paper was decided by a show of hands vote without any opportunity for you to address any concerns, especially if the rules of publishing were such that you only get one chance ever in your life to submit a given paper? What if your peers knew that and were therefore likely to give you the benefit of the doubt on some of their (in their opinion at that moment) minor objections?
You think people should be convicted based on secret information their attorneys didn't even know about? Nice...
Or acquitted. Yes, yes, I do. Maybe the lawyers would prefer that I walked into the jury box with a blank slate of a mind that they can fill in with whatever statements of fact they see fit, but that's not what they're getting.
If your deployment environment is Linux, then get a Linux box to develop your code.
I couldn't disagree more. Almost all of my code is deployed on FreeBSD servers, but I'm using a Linux desktop. The advantage I see is that it keeps me from making assumptions about the underlying platform. Should we ever switch to Linux servers, the apps will still run correctly. When I'm working from home on a PPC Mac, the apps still run correctly. When I'm roaming about with my 32-bit Atom netbook, they still run correctly. When I released one program as open source, it was added to the FreeBSD (for IA64, even), Debian, and Ubuntu package repositories because it works as designed on all of those.
I do agree with your statement that expecting them to be the same is dumb. "Similar" is not "identical", and there are always surprising little differences that you have to account for. But I believe that identifying and accounting for those differences makes your code better and more robust, and those are good things.
That's what I'd do if I were them...
No you wouldn't. If you truly became McAfee, you'd run around screaming "LINUX IS DANGEROUS WITHOUT ANTIVIRUS! WE SLOW YOUR COMPUTER SO YOU DON'T HAVE TO! I EAT PAINT!"
Which is still an improvement over what you'd do if you were Norton.
I wouldn't say that. Consider that in insert(), you'd have to update the list_size value. If you use (list_size==-1) as the "unknown size" flag, then you have to check for it before incrementing. Otherwise your first insert() after splice() would result in list_size==0, or empty. If you store "unknown size" as a separate bool, then you can tell insert() to always increment list_size. I couldn't even hazard a guess as to whether "conditionally increment" or "always increment" would be faster on modern hardware.
I don't know whether that's a DBAPI feature or a psycopg2 extension, but I tested that code (adapted for my own PostgreSQL table) and verified that it works exactly like you'd expect it to.
The second example was SQLAlchemy, my preferred way of never having to write another line of SQL. I know I can write complex, efficient queries if I want to. I also know that I'd rather let the computer figure it out for me. :-)
The fact that the company which produces and sells MySQL wasn't using SQL correctly is indeed ironic.
Actually, it's exactly what I would expect.
Sincerely,
Smug PostgreSQL bigot
My eyes, they bleed! Write that like:
Or even better:
Voila. Those work, they're not hideous, and they prevent injection. To repeat the earlier idea: there's no need to write unsafe code. If you are, you're in the wrong line of work.
There's something to that, but that overhead would be sizeof(size_type)+sizeof(bool), which should add up to an insignificant overhead except in the case of a program that maintains millions of single-element lists.
Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.
If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.
Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".
I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.
I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that the flaw in my idea is that it only gives an improvement 99.9% of the time and falls back to the old behavior in the other 0.1% of cases. In every other software realm, you'd call that a successful optimization.
Unless you depend on size() being slow for some reason, in which case you're using the wrong language. But that's a different discussion.
It would be unpredictably awesome. Suppose you have a million splice() calls that insert one item each, followed by a million size() calls. If size() is O(1) and splice is O(n), that would require about a million list traversals and about 500 billion (sum([1..1,000,000])) visits to items in the list. If size() is O(n) and splice() is O(1), that would take a million list traversals and a trillion visits. In my algorithm, size would be O(n) once and O(1) every other time, for exactly one traversal and one million visits.
With my idea, splice() is always O(1). In the worst case, size() would take exactly as long as it does now, plus a single conditional to see if known_size is true or false. In the average case, size() would also be O(1). It would also conform to the C++ principal of not making you pay for what you don't use: unless you specifically call size() after splice(), both algorithms would be O(1). If you do call size() after splice(), it would be no worse than what we have today.
I'm loathe to discard simple algorithm optimizations just because they don't apply to every situation, particularly when their failure mode is just as good as the original.
Leaping into the middle of the conversation: why? It seems like you could implement caching logic like:
Voila. size() is O(1) almost always, except immediately after a splice(). In the worst case, it'd be O(n) immediately after a splice(), but only the first time - and then it'd revert to O(1) behavior.
Why wouldn't that work?
but only a little bit better in that they do 'projects together' which in my experience means that the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.
That's called "managing expectations", and is a wonderful introduction to their future careers for a lot of CS grads. Now go fetch me some coffee while this build finishes, would you? Thanks.
Before digital cameras, that was known as a "viewfinder": capture a still image while previewing the world through a tiny little window. Die in a fire, Kodak. You used to be great, but you've completely SCO'ed your reputation.
No, I don't believe there's such a thing as a tamper-proof odometer.
Then why should we use this instead of the car's pre-existing, Federally-mandated odometer? What is the advantage to drivers in collecting this information twice in separate devices, or to the government as related to their stated reason for wanting the information?
...and they're completely tamper proof.
So you believe the correct answer is to install a second, hardened odometer that provides no benefits whatsoever to the owner. You work as a contractor, don't you?
You must be new here. Checks UID... Yup!
He still has a point, n00b.
Don't you think it's only fair if companies can't buy from companies using pirated software who sell at lower price because frankly they don't need to pay as much costs as lawful companies?
No, because the response is utterly out of proportion with the offense. Say a web guy at Foxconn brings in a pirated copy of Photoshop. Your logic would indicate that MS should be able to sue Apple for unfair competition, even though 1) Apple didn't do it, and 2) the act of piracy contributed absolutely nothing to Apple's product.
Basically, you're advocating the death penalty for a jaywalking ticket. Maybe that seems fair and just in your tiny little world, but it comes across as pretty damn insane for everyone living in reality.