Thank you for competing. Better luck next time!!!
As your consolation prize, you'll take home this nearly new 3000-pound ATM switch and a lifetime supply of MiniDisc blanks.
Sounds great, but it solves a different problem. Specifically, it only really works if you know the phone numbers of the people you want to talk to (or block). Doesn't help for people calling from arbitrary numbers, which is the problem the "magic number" technique is appropriate for.
I'm not sure blocking on the phone will help much, since you're probably getting these calls from an assortment of differing numbers that you can't predict.
What you really need is a "magic number" (a simple password, basically) that callers have to enter to get access to your line, after they've reached you. This would block out everyone except the people you want to talk to (who you've told your magic number). A little unfriendly maybe, but not much different than having an extension that people need to remember.
Coincidentally, I used to work on the email-to-phone interface for a major cell carrier. Since their numbers were assigned in blocks, the system was trivial to spam. This wasn't considered to be a problem until the executives of the company started receiving it.;-). Anyway, I suggested a magic word solution similar to the above for that case. Instead they spent megabucks on some antispam solution. No idea if it works--I have text messaging for my phone permanently disabled...
I think you lack imagination. Some of us (me, for example) can bicycle most of the places we need to go. Grandma, with her oxygen, tank cannot. A huge proportion of our infrastructure has been built on the assumption that cheap oil will be available.
Think of Katrina. Yes, the markets there "cleared"--it just so happened that at the clearing point a lot of people died.
Your question is moot, because the business world doesn't work that way:
Hmm, we can save $2000 per year by putting Jones in a tiny cubicle instead of an expensive office. (then) Hmm, why are we paying some loser who doesn't even have his own office $70K per year? (then) Hmm, we can save $3000 per year by having Jones sit in that little vacant booth in the parking lot. (then) Hmm, we're paying that guy in the booth $38K per year--the least he can do is a wear a bowtie and a little vest. (then) Etc.
No, I hadn't seen this page (I pretty much gave up on Java several years ago). I think you're talking about, for example, ConcurrentHashMap. Yes, it looks very nice, and I'd sure rather use this than the usual lock/monitor type thing.
Fundamentally, though, as far as I can see, having threads introduces a whole new dimension of nondeterminism. This makes correctness and debugging more difficult. Much more, IMO.
As processors move to 8-way cores, 64-way cores, etc. (which will presumably eventually become available even for desktops), I might end up changing my mind about this. But right now it seems like hardware is cheap, developer time is expensive, and anything that lets me trade "less hardware" for "more developer time" doesn't seem very attractive.
Funny, I've never noticed this, and I've been using threads succesfully for decades to handle applications which need to serve concurrent users while sharing data. Perhaps I've just been lucky? What do you think?
Maybe so, and if so, you may count yourself lucky. If you've done a lot of non-threaded stuff and a lot of threaded stuff and the threading didn't cause you noticeably more grief, then you may definitely count yourself lucky.
If you don't use threading, how do you get concurrent service processes to share native object data on 4 to 32-way multiprocessor machines? Surely you must have some programs which serve more than one person at a time and surely some of your apps really need to take advantage of the native performance features of the hardware they are running on?
Actually, no, "taking advantage of native performance features" has never been in a list of requirements for anything I've worked on. Generally the requirements center on getting things implemented quickly, correctly and maintainably, aspects for which threading is a minus.
I can certainly imagine cases for which threading would be crucial, just as I can imagine cases for which assembly language is crucial, but no, it's never come up for me. As I said, I think it's just a really tiny niche.
Using multiple processes generally fits the bill and is much less complex. When I do do use threading, it tends to be part of some other piece of stable software like Apache or a database engine, so that I mostly don't have to pay its price.
Does your company ever create multithreaded programs?
This is a concern, for the 0.01% of programs for which multithreading is actually a wise design decision. And, although there are some options for Python, if your program truly falls into that category, perhaps you should use another language.
In my experience, though, most choices to multithread programs are ill-advised, and seem to be made because that's the decider's familiar hammer. The costs associated with multithreading are huge, and should not be chosen without long contemplation.
Good God didn't you just make the program take twice as long to create?
No, because most of the work involved in writing the Python version is design work and problem solving that you'd have to do in any case. Plus, the Python version usually only takes 10-25% as long to write. Try it, you'll like it!
[Y]ou are assuming that a language like Python translates line-by-line into C++. Does it?
I've been following this methodology (Python first, then C++ as/where needed) for a number of years. In all of that time, I've only had one application where I ended up needing to drop into C++ at all. In that case, a couple of pages of Python did translate into a couple of pages of C++, virtually line for line. Heavy use of STL allowed this, as there are a lot of data structures and algorithms there that map more-or-less directly to Python. The main problem was that the STL tended to be either buggy or to have razor-sharp edges upon which to cut oneself.
Python is generally a win because (1) you can write the same working functionality much faster than in C++, and (2) the specifications for apps tend to vary wildly over time, so a high-level language lets you go with the flow.
I've been in a lot of situations like this. Sometimes I've tried to fix things through extraordinary effort. This has never, ever worked for me, though, and as I've gotten older, I've become much less interested in "rocking the boat". Why knock yourself out to help an organization that will only curse you for it? If your project is stalled because the idiots in IT are holding you up, well, there's your chance to learn a new language, tool, musical instrument or whatever will be useful when you move to your next job.
once you get out of the major US cities with public transportation, how is a 16 year old, or for that matter a legally adult 18 year old, supposed to get around?
We could make a hardship exception for those who need to travel more than (say) four miles to work. Or we could require a mechanically enforced limit of 25mph for young drivers.
Not to mention it gives you 2 years to do something stupid in the car without the full force of the law bearing down on you.
I don't think we should give anyone a "free bite", nor would it really help anyone with a conscience, anyway.
Err, read the article again. These were two eighteen year olds, not sixteen. 18, by definition, is an adult.
When I said 16, I was referring to the age (in the US) at which kids are allowed to drive. And as I said, I think 18 is too young, too.
As for the definition, it's just law and custom. We can change it any time we want, as with the drinking age. Probably immaturity-plus-driving causes a lot more deaths than immaturity-plus-alcohol.
I agree that experience really matters. But I don't think it needs to be experience behind the wheel. Rather, I think the experience that counts is seeing one's friends and acquaintances suffering the consequences of bad driving decisions.
It's all moot, anyway. Here in the US, the driving age will, if anything, continue to decline.
It's easy to look at this from a "here come the idiots to steal our fun" slant, but the Toronto Police quote in the parent seems pretty reasonable to me.
As for the video game, I don't think that it's really the problem here. Yes, the kids probably did play it, and it probably put stupid ideas in their heads. But the real problem is that they were not yet mature enough to have the good judgement not to race their cars on public streets.
Rather than blame video games, we should simply prohibit kids from driving. Sixteen is simply way too young. Twenty-one would be more like it, though maybe yet still too young...
About six or seven years ago I was the technical lead working on a million-dollar contract for a major telecom company. I made a point to ask each company whether they would make their source code available to us, or at least allow us to look at it--not exactly Open Source, but as much as I could do at the time. Most of the companies acted as if I'd ask them to suck a turd through a straw.
One company did say "yes". They won the contract, probably for a lot of other reasons, as they were ahead of the curve in a lot of ways.
Basically this is correct. This is not a problem that you can solve, and it's not something you should worry about, aside from notifying your superiors that it's a major problem for you.
*IF* the article discussed governments planning to RFID tag humans behind the left ear, then, perhaps, we would have a major issue.
Actually, such an embedded tag would be less informative for spying/tracking purposes than the current future scenario, which is that we will all be carrying around a virtual blizzard of tags in our everyday items. One embedded tag would be easy to spoof/kill/fake/etc., whereas the blizzard is a mark practically impossible to alter.
Whether this is a major issue is for you to decide, but don't kid yourself--as this becomes more ubiquitous, you'll be lit up like a Christmas tree, 24x7x365...
Because as a non-renewable resource becomes scarcer, the price rises. This reduces demand and allows the remaining supplies to last longer.
This is a distinction ("noneconomical" vs "exhausted") without a difference. Sort of like the difference between having a mediocre medical system that everyone can participate in, versus an excellent one that half of society can't access due to its cost.
Slashdot Mirror
Thank you for competing. Better luck next time!!! As your consolation prize, you'll take home this nearly new 3000-pound ATM switch and a lifetime supply of MiniDisc blanks.
Living in California is being stupid with your money...
Sounds great, but it solves a different problem. Specifically, it only really works if you know the phone numbers of the people you want to talk to (or block). Doesn't help for people calling from arbitrary numbers, which is the problem the "magic number" technique is appropriate for.
What you really need is a "magic number" (a simple password, basically) that callers have to enter to get access to your line, after they've reached you. This would block out everyone except the people you want to talk to (who you've told your magic number). A little unfriendly maybe, but not much different than having an extension that people need to remember.
Coincidentally, I used to work on the email-to-phone interface for a major cell carrier. Since their numbers were assigned in blocks, the system was trivial to spam. This wasn't considered to be a problem until the executives of the company started receiving it. ;-). Anyway, I suggested a magic word solution similar to the above for that case. Instead they spent megabucks on some antispam solution. No idea if it works--I have text messaging for my phone permanently disabled...
Personally, I'm waiting a few more years before they work the bugs out of these new-fangled capac-i-tors...
This would be nice, I agree. But we live in a capitalist society. Goods go to those who can pay, not necessarily to those who need them.
Non sequitur. It wasn't expensive gas that caused those deaths.
It's called an analogy. Check into them--they're all the rage!
I think you lack imagination. Some of us (me, for example) can bicycle most of the places we need to go. Grandma, with her oxygen, tank cannot. A huge proportion of our infrastructure has been built on the assumption that cheap oil will be available.
Think of Katrina. Yes, the markets there "cleared"--it just so happened that at the clearing point a lot of people died.
Fundamentally, though, as far as I can see, having threads introduces a whole new dimension of nondeterminism. This makes correctness and debugging more difficult. Much more, IMO.
As processors move to 8-way cores, 64-way cores, etc. (which will presumably eventually become available even for desktops), I might end up changing my mind about this. But right now it seems like hardware is cheap, developer time is expensive, and anything that lets me trade "less hardware" for "more developer time" doesn't seem very attractive.
Maybe so, and if so, you may count yourself lucky. If you've done a lot of non-threaded stuff and a lot of threaded stuff and the threading didn't cause you noticeably more grief, then you may definitely count yourself lucky.
If you don't use threading, how do you get concurrent service processes to share native object data on 4 to 32-way multiprocessor machines? Surely you must have some programs which serve more than one person at a time and surely some of your apps really need to take advantage of the native performance features of the hardware they are running on?
Actually, no, "taking advantage of native performance features" has never been in a list of requirements for anything I've worked on. Generally the requirements center on getting things implemented quickly, correctly and maintainably, aspects for which threading is a minus.
I can certainly imagine cases for which threading would be crucial, just as I can imagine cases for which assembly language is crucial, but no, it's never come up for me. As I said, I think it's just a really tiny niche.
Using multiple processes generally fits the bill and is much less complex. When I do do use threading, it tends to be part of some other piece of stable software like Apache or a database engine, so that I mostly don't have to pay its price.
This is a concern, for the 0.01% of programs for which multithreading is actually a wise design decision. And, although there are some options for Python, if your program truly falls into that category, perhaps you should use another language.
In my experience, though, most choices to multithread programs are ill-advised, and seem to be made because that's the decider's familiar hammer. The costs associated with multithreading are huge, and should not be chosen without long contemplation.
No, because most of the work involved in writing the Python version is design work and problem solving that you'd have to do in any case. Plus, the Python version usually only takes 10-25% as long to write. Try it, you'll like it!
I've been following this methodology (Python first, then C++ as/where needed) for a number of years. In all of that time, I've only had one application where I ended up needing to drop into C++ at all. In that case, a couple of pages of Python did translate into a couple of pages of C++, virtually line for line. Heavy use of STL allowed this, as there are a lot of data structures and algorithms there that map more-or-less directly to Python. The main problem was that the STL tended to be either buggy or to have razor-sharp edges upon which to cut oneself.
Python is generally a win because (1) you can write the same working functionality much faster than in C++, and (2) the specifications for apps tend to vary wildly over time, so a high-level language lets you go with the flow.
...Could it be because there is no competition in broadband?
I've been in a lot of situations like this. Sometimes I've tried to fix things through extraordinary effort. This has never, ever worked for me, though, and as I've gotten older, I've become much less interested in "rocking the boat". Why knock yourself out to help an organization that will only curse you for it? If your project is stalled because the idiots in IT are holding you up, well, there's your chance to learn a new language, tool, musical instrument or whatever will be useful when you move to your next job.
http://www.mathdogs.com/people/mkc/perl-puzzles.ht ml
You didn't happen to vote for Bush twice, did you?
We could make a hardship exception for those who need to travel more than (say) four miles to work. Or we could require a mechanically enforced limit of 25mph for young drivers.
Not to mention it gives you 2 years to do something stupid in the car without the full force of the law bearing down on you.
I don't think we should give anyone a "free bite", nor would it really help anyone with a conscience, anyway.
When I said 16, I was referring to the age (in the US) at which kids are allowed to drive. And as I said, I think 18 is too young, too.
As for the definition, it's just law and custom. We can change it any time we want, as with the drinking age. Probably immaturity-plus-driving causes a lot more deaths than immaturity-plus-alcohol.
It's all moot, anyway. Here in the US, the driving age will, if anything, continue to decline.
As for the video game, I don't think that it's really the problem here. Yes, the kids probably did play it, and it probably put stupid ideas in their heads. But the real problem is that they were not yet mature enough to have the good judgement not to race their cars on public streets.
Rather than blame video games, we should simply prohibit kids from driving. Sixteen is simply way too young. Twenty-one would be more like it, though maybe yet still too young...
One company did say "yes". They won the contract, probably for a lot of other reasons, as they were ahead of the curve in a lot of ways.
Basically this is correct. This is not a problem that you can solve, and it's not something you should worry about, aside from notifying your superiors that it's a major problem for you.
Whether this is a major issue is for you to decide, but don't kid yourself--as this becomes more ubiquitous, you'll be lit up like a Christmas tree, 24x7x365...