Hash tables are the best solution for this problem. Using modern hash functions will give you almost constant time for insertion and search, with very good constants. Sure, the theoretical worst case is extreme, but you are not going to hit it in the remaining lifetime in this universe and that makes it pretty irrelevant.
If you have competent people locally, outsourcing coding is extremely expensive. Of course, if you fired all your coders or threat them so badly that all good ones have left, outsourcing may be the only option left.
That is decidedly the biggest fail in there. Even of the duplicates-removal was implemented efficiently (using a hash-table, people, anything else is insane!) you may end up pushing a lot of extra data over a slow interface. And you use a lot of additional memory. This is the job of the DB and nobody else.
Fail. This is Java. You use one of the nice, language supplied hash-tables. Also, since you seem to not have really ready what I wrote, SQL has a "DISTINCT" keyword and the DB will nicely and efficiently remove duplicates for you.
There are still people using quick-sort? The mind boggles. Using that utter atrocity should get you banned for life from writing code. Use merge-sort of bottom-up heap-sort for minimally worse constants, but assured performance.
That, and the problems it causes in case of ire and accidents will prevent the whole thing. A basic safety principle is "you must always be able to get out". Also, there is a lot of glass in a car. Ever thought abut thieves bringing a hammer?
This is a typical facts-ignorant hyper-theoretical fantasy scenario, like the ones with "who does the car chose to run over?". (The car does not. It goes for the maximum braking that will not destabilize the vehicle. Another general safety principle is "when in doubt, reduce system energy". And it will be driving slowly enough that this braking will make the real difference. It is, after all, not a reckless human driver that vastly overestimates his skills.)
Also take into account that this comment is mostly targeted at virtualized server loads, not desktop computing. While there are these scenarios of "JavaScript in the browser steals your keys", the actual threat is "VM1 steals the keys of VM2", for various reasons. My prediction is that SMT will basically be dropped by CPU manufacturers. AMD was never very keen on it and Intel is currently reversing their propaganda on how great it is.
I agree. But Linus is the big-picture guy here, so I can accept that he has overriding concerns. Personally, I do not even have a CPU that does SMT, as it is a pretty bad technology anyways.
Car thieves will just adapt and find a way around this. Police powers have never done anything to reduce crime. The primary purpose of the police is to keep the population under control, in the west mostly by occasionally demonstrating that those on power have the big stick ready when needed. Also nicely explains why they are so ineffective against crime.
Sure, any kid from Cairo can "teach himself to code" by watching Youtube videos. But that doesn't mean they'll produce anything of quality that's actually maintainable. I've seen the quality that comes out of India, and it's atrocious.
Oh, yes. I reviewed some Java code from Indian "quality outsourcing" a few years back for security. This was so bad it was absolutely incredible. A lot of layers, basically all they did was rename all parameters and exceptions and pass them downwards (upwards). They had parameter names longer than 80 chars, differing in 3 chars, for example and these were not the same renamed parameters, but different ones. But the best thing I found was this: While scrolling over the code, I saw a nested loop (immediate red flag in glue code). And get this: It was a hand-coded bubble sort (probably the worst performer possible that is still n^2) used to remove duplicates (Java has hash-tables for that) from the result of a database query (you can tell the DB to remove the duplicates before it returns the result) that could possible include the whole customer base of a few million entries. I don't think it is possible to do this any worse so that it still technically works. I don't think I ever have seen technically working code that shows such a massive non-understanding of the technologies used. Needless to say the project was scrapped a while later, because they could not get it to work fast enough even with the medium-sized test data set.
My take is that the only economically sensible way to produce business-critical code (and a lot is that) is to get the absolute best coders you can, pay them wathever they ask and you will still come out massively ahead on the code TCO compared to the utter trash that usually gets deployed.
Or for that pay. At the very most you are getting mediocre people. If you sell their labor at a steep profit, that will still make you rich, but your customers are getting screwed.
It is probably just "we have failed spectacularly at our job and inconvenienced and assaulted (children being groped, for example) a lot of people, but we now have this one great idea, so please let us continue for a while".
If you remember that Edison patented the light bulb way before it was ready, this approach has a long tradition. Anyways, even if they are just close, they have beaten the rest of the world in a very important research area.
Some have standards, but as usual most do not and will do anything for money. All the more well known certainly will do most things if the pay is right.
Indeed. I do agree on your options as well. The last one unfortunately seems to be the least likely one. Might be in 10 years, might be in 30 years, but will certainly come pretty soon.
Slashdot Mirror
Hash tables are the best solution for this problem. Using modern hash functions will give you almost constant time for insertion and search, with very good constants. Sure, the theoretical worst case is extreme, but you are not going to hit it in the remaining lifetime in this universe and that makes it pretty irrelevant.
Thanks ;-)
If you have competent people locally, outsourcing coding is extremely expensive. Of course, if you fired all your coders or threat them so badly that all good ones have left, outsourcing may be the only option left.
That is decidedly the biggest fail in there. Even of the duplicates-removal was implemented efficiently (using a hash-table, people, anything else is insane!) you may end up pushing a lot of extra data over a slow interface. And you use a lot of additional memory. This is the job of the DB and nobody else.
Fail. This is Java. You use one of the nice, language supplied hash-tables. Also, since you seem to not have really ready what I wrote, SQL has a "DISTINCT" keyword and the DB will nicely and efficiently remove duplicates for you.
There are still people using quick-sort? The mind boggles. Using that utter atrocity should get you banned for life from writing code. Use merge-sort of bottom-up heap-sort for minimally worse constants, but assured performance.
In the scenario at hand, the input was basically randomized.
That as well.
That, and the problems it causes in case of ire and accidents will prevent the whole thing. A basic safety principle is "you must always be able to get out". Also, there is a lot of glass in a car. Ever thought abut thieves bringing a hammer?
This is a typical facts-ignorant hyper-theoretical fantasy scenario, like the ones with "who does the car chose to run over?". (The car does not. It goes for the maximum braking that will not destabilize the vehicle. Another general safety principle is "when in doubt, reduce system energy". And it will be driving slowly enough that this braking will make the real difference. It is, after all, not a reckless human driver that vastly overestimates his skills.)
Also take into account that this comment is mostly targeted at virtualized server loads, not desktop computing. While there are these scenarios of "JavaScript in the browser steals your keys", the actual threat is "VM1 steals the keys of VM2", for various reasons. My prediction is that SMT will basically be dropped by CPU manufacturers. AMD was never very keen on it and Intel is currently reversing their propaganda on how great it is.
I agree. But Linus is the big-picture guy here, so I can accept that he has overriding concerns. Personally, I do not even have a CPU that does SMT, as it is a pretty bad technology anyways.
Indeed. And eventually even those single digit improvements will go away. Maybe we can start writing better software now?
Car thieves will just adapt and find a way around this. Police powers have never done anything to reduce crime. The primary purpose of the police is to keep the population under control, in the west mostly by occasionally demonstrating that those on power have the big stick ready when needed. Also nicely explains why they are so ineffective against crime.
Sure, any kid from Cairo can "teach himself to code" by watching Youtube videos. But that doesn't mean they'll produce anything of quality that's actually maintainable. I've seen the quality that comes out of India, and it's atrocious.
Oh, yes. I reviewed some Java code from Indian "quality outsourcing" a few years back for security. This was so bad it was absolutely incredible. A lot of layers, basically all they did was rename all parameters and exceptions and pass them downwards (upwards). They had parameter names longer than 80 chars, differing in 3 chars, for example and these were not the same renamed parameters, but different ones. But the best thing I found was this: While scrolling over the code, I saw a nested loop (immediate red flag in glue code). And get this: It was a hand-coded bubble sort (probably the worst performer possible that is still n^2) used to remove duplicates (Java has hash-tables for that) from the result of a database query (you can tell the DB to remove the duplicates before it returns the result) that could possible include the whole customer base of a few million entries. I don't think it is possible to do this any worse so that it still technically works. I don't think I ever have seen technically working code that shows such a massive non-understanding of the technologies used. Needless to say the project was scrapped a while later, because they could not get it to work fast enough even with the medium-sized test data set.
My take is that the only economically sensible way to produce business-critical code (and a lot is that) is to get the absolute best coders you can, pay them wathever they ask and you will still come out massively ahead on the code TCO compared to the utter trash that usually gets deployed.
Indeed. Great coders actually spend a lot of time thinking, and little time coding. That does not fit this slave-labor model at all though.
This is an impressive quote, used in an impressive way!
Or for that pay. At the very most you are getting mediocre people. If you sell their labor at a steep profit, that will still make you rich, but your customers are getting screwed.
It is probably just "we have failed spectacularly at our job and inconvenienced and assaulted (children being groped, for example) a lot of people, but we now have this one great idea, so please let us continue for a while".
If you remember that Edison patented the light bulb way before it was ready, this approach has a long tradition. Anyways, even if they are just close, they have beaten the rest of the world in a very important research area.
I doubt it has much to do with education. People are just generally stupid and still have a tribal mind-set.
"Diet Cherry Pepsi"? Urgh. At least have some minimal standards!
Some have standards, but as usual most do not and will do anything for money. All the more well known certainly will do most things if the pay is right.
Also sounds pretty much like a scam. Making the victim afraid is part of that.
Indeed. I do agree on your options as well. The last one unfortunately seems to be the least likely one. Might be in 10 years, might be in 30 years, but will certainly come pretty soon.
I don't think "with them or against them" is rational. I certainly do not stand with anybody that makes me chose...