Don't let others do any threading at all. If you can't wrap all of the complexities in a library, it will be done wrong, yet still manage to "work" good enough that no one notices there's an issues until someone who knows what they're doing looks at the code.
In my experience, race conditions are on a bathtub curve. Either the software crashes all of the time and the race condition gets fixed, or the race condition is incredibly rare or naturally silent and people just assume computers do weird things from time to time.
Few software problems are so simple that they play well with a parallelized for-loop. If you really want to make software scale well with concurrency, you need to deeply understand what is going on at the CPU level and how the different synchronizations are implemented and how they interact with your current CPU architecture. If you don't understand what you're doing, Amdahl's law will backhand you to the 60s. And that's ignoring all of the race-conditions most people will miss.
The higher the frequency, the more "damaging" the EM radiation, except possibly in cases where there is a resonance. Every atom in our body emits IR radiation. Once you calculate for the surface area of a human's atomic surface area, you're sitting in the range of 15 gigawatts of IR at room temperature. If you think the radiation of a 1watt cellphone is going to compare to the 15 billion times of IR..... But, if you think the 1 watt of microwave radiation could cause localized heating, then I agree.
While our body deals with a wide range of temperatures, it's "not normal" to have a potentially sharp temperature gradient. As for the brain. Not sure. It has a lot of blood flow and should keep the temperature quite uniform. Not to mention the brain generates 20watts of waste heat. Assuming 100% of that 1 watt gets absorbed, you're talking about a 5% increase in waste heat. The deeper the microwave radiation penetrates, the more evenly distributed the heating will be.
It all comes down to heating and there are many things in our lives that cause much worse heating, by magnitudes. If you're concerned about resonance, don't worry, newer wifi tech is using more and more spread spectrum and wider and wider channels.
A quick google on the topic shows that the bacteria in question so happens to produce reactive Oxygen compounds that so happen to straddle the UV spectrum. High blue or violet visible light is just enough energy to trigger these compounds into reacting and oxidizing the insides of the bacteria.
This entire category of "attack vector" makes an organism sensitive to an EM radiation of a given frequency or higher. If we had this issue with microwave radiation, we'd also have the issue with IR radiation, instantly killing us.
I talked to my biology teacher about the whole powerline thing. He summed it up as an electric razor produces more EM of any frequency you care to look at, but high voltage powerlines are so high voltage that they can ionize nearby air and leak power to ground. It's not the EM, it's the ionized air.
If you touch a screen projector light bulb you get the same effect. As long as it's not ionizing, EM is EM, just a difference in penetration and how evenly you're warmed. The heat from my cellphone's battery is worse for me than the 0.2watts total of microwave EM it emits. If anything, being more penetrative reduces the concentration of the heating. The human brain generates about 25 watts of waste heat. It's going to take some pretty high wattage cellphone to make any difference.
Know what will quickly increase my brain's temperature? Working out.
I did read one research that showed a bias of cancer forming near where the phone is used BUT no increased risk of getting cancer. They assumed that localized warming may help cancer metastasize.
The Sun is the least of our worries. The amount of "high energy" infrared (compared to microwave) EM radiation that we've being bathed in at room temperature is nearly 3 magnitudes greater. The deep tissue heating caused by sleeping next to someone is going to freak these people out.
two people with high IQ will out-perform a single person of super high-IQ
Out-perform them in what? One of the biggest issues in programming is a group of programmers is only as smart as the least smart of the group, unless the rest of them just ignore the lesser. I've had it where about 5 of the most senior programmers in my company where stuck a problem for several days with code that they wrong. I just so happened to have walked by and overheard them discussing the issue and I solved the problem in less than a minute. It was a 100% custom built system, so I had zero knowledge or experience. This pretty much sums up every experience I've ever had.
Another example. My ISP was having a network issue. I was working with one of their senior engineers for nearly 6 months. I kept telling them what the problem was and where they need to look, but they couldn't figure it out. They eventually hired a 3rd-party firm that specialized in fixing complex network issues for large ISPs. Even they could not figure it out for several days. My ISP called me and asked me to talk to these people. I got on the phone with 3 "specialists", and I went over the data I sent them, explaining what I thought the issue was and the reasoning behind my thoughts. I got off the phone, 1 hour later, the problem was figured out.
My background in networking is I took an entry level class in college and I have a pfSense box at home, and I diagnosed an ISP level network issue with nearly zero experience.
Google and Facebook have stated that there is zero correlation between ability and experience past 6 months. If you had a collection of programmers, all with at least 6 months experience in whatever software field, the skill distribution would be nearly identical between those with less than 1 year and those with more than 5 years. Experience is a nearly worthless requirement.
Talent recognizes talent. Fake talent thinks it recognizes talent, but it's really recognizing other fake talent creating en echo-chamber. Turns out talent is incredibly difficult to measure objectively. How do we collectively decide who is talented without creating an echo-chamber of people who are only seemingly talented? There is also the issue that talented people tend to not be very social, making them outcasts.
Coding is orthogonal to programming. Just wait until AIs are doing the coding for the programmers. Coding is just the act of translating ideas into a language that computers understand. Or as "Uncle Bob" says, the code is just the exact detailed requirements. Programming is the act of creating those requirements.
As useful as paper can be, there are many situations where someone will print off 100+ pages just to throw them all in the bin a few hours later. The real question is how often does this happen will answer what the max savings of that maximum 1%.
The problem is the lack of "real" programming classes and the false sense of accomplishment a child can get from "doing well" in the fake programming class. You can balance on one leg?! You're going to be a great gymnast! The even bigger problem is the crazy high amount of Dunning–Kruger effect going on in the programming industry as a whole. Someone may not know they're bad at programming until it's too late.
Letting children try new things to see if it's not only something they like, but something they do well at is a great idea. The elephant in the room is the "doing well at" part. Even CS professors at ivy league Universities are pretty much all saying that 80% of their graduates should not do programming, but they can't fail them because they technically passed. And that 80% is already after the first 80% of failed to graduate. This means that about 96% of people who apply for programming can't or shouldn't. And that's after weeding out all of the other people by having high requirements just to apply.
Then you have the other elephant in the room. Dunning–Kruger effect is a side-effect of a lack of meta-cognition, which is intern a lack of fluid intelligence, which is required for abstract reasoning, deductive reasoning, and inductive reasoning. Of which all 3 are fundamental requirements for any good programmer. There are no known ways to increase fluid intelligence, only ways to get better at specific fluid-intelligence tests, but the benefits are non-transferable, aka don't actually help.
As far as we can tell, increasing fluid intelligence requires meta-cognition to recognize what you don't know and why you are failing, but at the same time, it takes high enough fluid intelligence to have the meta-cognition to do so. It's a catch-22 where people below a threshold have virtually zero ability and those above it are exponentially better for small improvements.
If we want children with better fluid intelligence, one possible way is we need to start them very young on being very introspective about their own thoughts and reasoning.
That only applies to many-to-many relations and overly-normalized is nearly as bad as under. Not including that if you have 2 tables with a 32bit int vs one table with a 64bit it, it's a wash. Even in these situations, if you're doing seeks of large many-to-many tables, the random access out-weighs the cost of the extra 4 bytes per field.
I recently was doing performance testing of a tight loop and was comparing 32bit vs 64bit on a 32bit CPU, and the performance was within 10% of each-other. Even when having to do two register loads and combining the registers to emulate 64bit arithmetic, the CPU was able to OoO+pipeline most of the cost. In the end, I have had more situations where using 32bit ints was slower than 64bit.
In before anyone points out about a "work around" for UUID clustered index fragmentation. And don't use sequential UUIDs, I will hate you. They are how you get collisions across systems or even in the same system if two tables have the same seed.
Indexing UUIDs on a large table is a management nightmare. Take about page fragmentation. Joining two large GUID based tables can cause horrible performance corner cases even when clustered. UUIDs should be limited to public data/APIs, but not actually used internally. I do love them for keeping my data sane, but the performance optimizations and management overhead means you need to really think about the issue before you index them. NEVER cluster index them.
Unless your table only has an index, doubling the size of the index is quite moot. IF you knew anything about data alignment, SQL data page layouts, or the slew of meta-data stored along with the data, you would realize it does not matter in nearly every case. It will matter if you're programming in a compile language that allows you to control structure layouts and you need to do a lot of CPU intensive work or need to work with SIMD, but outside of that, 64bit.
I had to look up "Primordial black holes", and that's an interesting theory. These blackholes could actually pass through the Earth on a semi-regular basis.
Nutshell: Blackholes that formed during the early Universe, allowing them to be much smaller because they did not have to form from a dying star. Think in the range of less than a Moon mass.
Certain types of skepticism is just irrationality. Your analogy is completely flawed. A better analogy would be taking a tank of compressed gas into space and finding it implodes instead of explodes, in a vacuum. Not only would it defy expectations, but it would defy all previously known theories in very fundamental ways. No analogy is perfect, but at least try to get the abstract concepts in the same ballpark.
Slashdot Mirror
Don't let others do any threading at all. If you can't wrap all of the complexities in a library, it will be done wrong, yet still manage to "work" good enough that no one notices there's an issues until someone who knows what they're doing looks at the code.
In my experience, race conditions are on a bathtub curve. Either the software crashes all of the time and the race condition gets fixed, or the race condition is incredibly rare or naturally silent and people just assume computers do weird things from time to time.
Few software problems are so simple that they play well with a parallelized for-loop. If you really want to make software scale well with concurrency, you need to deeply understand what is going on at the CPU level and how the different synchronizations are implemented and how they interact with your current CPU architecture. If you don't understand what you're doing, Amdahl's law will backhand you to the 60s. And that's ignoring all of the race-conditions most people will miss.
Why not use Lead pipes? They use Lead as a sweetener. Goes great on all kinds of food. It's like they had soda for water.
The higher the frequency, the more "damaging" the EM radiation, except possibly in cases where there is a resonance. Every atom in our body emits IR radiation. Once you calculate for the surface area of a human's atomic surface area, you're sitting in the range of 15 gigawatts of IR at room temperature. If you think the radiation of a 1watt cellphone is going to compare to the 15 billion times of IR..... But, if you think the 1 watt of microwave radiation could cause localized heating, then I agree.
While our body deals with a wide range of temperatures, it's "not normal" to have a potentially sharp temperature gradient. As for the brain. Not sure. It has a lot of blood flow and should keep the temperature quite uniform. Not to mention the brain generates 20watts of waste heat. Assuming 100% of that 1 watt gets absorbed, you're talking about a 5% increase in waste heat. The deeper the microwave radiation penetrates, the more evenly distributed the heating will be.
It all comes down to heating and there are many things in our lives that cause much worse heating, by magnitudes. If you're concerned about resonance, don't worry, newer wifi tech is using more and more spread spectrum and wider and wider channels.
A quick google on the topic shows that the bacteria in question so happens to produce reactive Oxygen compounds that so happen to straddle the UV spectrum. High blue or violet visible light is just enough energy to trigger these compounds into reacting and oxidizing the insides of the bacteria.
This entire category of "attack vector" makes an organism sensitive to an EM radiation of a given frequency or higher. If we had this issue with microwave radiation, we'd also have the issue with IR radiation, instantly killing us.
I talked to my biology teacher about the whole powerline thing. He summed it up as an electric razor produces more EM of any frequency you care to look at, but high voltage powerlines are so high voltage that they can ionize nearby air and leak power to ground. It's not the EM, it's the ionized air.
If you touch a screen projector light bulb you get the same effect. As long as it's not ionizing, EM is EM, just a difference in penetration and how evenly you're warmed. The heat from my cellphone's battery is worse for me than the 0.2watts total of microwave EM it emits. If anything, being more penetrative reduces the concentration of the heating. The human brain generates about 25 watts of waste heat. It's going to take some pretty high wattage cellphone to make any difference.
Know what will quickly increase my brain's temperature? Working out.
I did read one research that showed a bias of cancer forming near where the phone is used BUT no increased risk of getting cancer. They assumed that localized warming may help cancer metastasize.
The Sun is the least of our worries. The amount of "high energy" infrared (compared to microwave) EM radiation that we've being bathed in at room temperature is nearly 3 magnitudes greater. The deep tissue heating caused by sleeping next to someone is going to freak these people out.
two people with high IQ will out-perform a single person of super high-IQ
Out-perform them in what? One of the biggest issues in programming is a group of programmers is only as smart as the least smart of the group, unless the rest of them just ignore the lesser. I've had it where about 5 of the most senior programmers in my company where stuck a problem for several days with code that they wrong. I just so happened to have walked by and overheard them discussing the issue and I solved the problem in less than a minute. It was a 100% custom built system, so I had zero knowledge or experience. This pretty much sums up every experience I've ever had.
Another example. My ISP was having a network issue. I was working with one of their senior engineers for nearly 6 months. I kept telling them what the problem was and where they need to look, but they couldn't figure it out. They eventually hired a 3rd-party firm that specialized in fixing complex network issues for large ISPs. Even they could not figure it out for several days. My ISP called me and asked me to talk to these people. I got on the phone with 3 "specialists", and I went over the data I sent them, explaining what I thought the issue was and the reasoning behind my thoughts. I got off the phone, 1 hour later, the problem was figured out.
My background in networking is I took an entry level class in college and I have a pfSense box at home, and I diagnosed an ISP level network issue with nearly zero experience.
Programming is not math, it's pure logic. Math is a subset of logic.
Even better. Random has pathological edge cases.
Google and Facebook have stated that there is zero correlation between ability and experience past 6 months. If you had a collection of programmers, all with at least 6 months experience in whatever software field, the skill distribution would be nearly identical between those with less than 1 year and those with more than 5 years. Experience is a nearly worthless requirement.
Talent recognizes talent. Fake talent thinks it recognizes talent, but it's really recognizing other fake talent creating en echo-chamber. Turns out talent is incredibly difficult to measure objectively. How do we collectively decide who is talented without creating an echo-chamber of people who are only seemingly talented? There is also the issue that talented people tend to not be very social, making them outcasts.
Coding is orthogonal to programming. Just wait until AIs are doing the coding for the programmers. Coding is just the act of translating ideas into a language that computers understand. Or as "Uncle Bob" says, the code is just the exact detailed requirements. Programming is the act of creating those requirements.
As useful as paper can be, there are many situations where someone will print off 100+ pages just to throw them all in the bin a few hours later. The real question is how often does this happen will answer what the max savings of that maximum 1%.
The problem is the lack of "real" programming classes and the false sense of accomplishment a child can get from "doing well" in the fake programming class. You can balance on one leg?! You're going to be a great gymnast! The even bigger problem is the crazy high amount of Dunning–Kruger effect going on in the programming industry as a whole. Someone may not know they're bad at programming until it's too late.
Letting children try new things to see if it's not only something they like, but something they do well at is a great idea. The elephant in the room is the "doing well at" part. Even CS professors at ivy league Universities are pretty much all saying that 80% of their graduates should not do programming, but they can't fail them because they technically passed. And that 80% is already after the first 80% of failed to graduate. This means that about 96% of people who apply for programming can't or shouldn't. And that's after weeding out all of the other people by having high requirements just to apply.
Then you have the other elephant in the room. Dunning–Kruger effect is a side-effect of a lack of meta-cognition, which is intern a lack of fluid intelligence, which is required for abstract reasoning, deductive reasoning, and inductive reasoning. Of which all 3 are fundamental requirements for any good programmer. There are no known ways to increase fluid intelligence, only ways to get better at specific fluid-intelligence tests, but the benefits are non-transferable, aka don't actually help.
As far as we can tell, increasing fluid intelligence requires meta-cognition to recognize what you don't know and why you are failing, but at the same time, it takes high enough fluid intelligence to have the meta-cognition to do so. It's a catch-22 where people below a threshold have virtually zero ability and those above it are exponentially better for small improvements.
If we want children with better fluid intelligence, one possible way is we need to start them very young on being very introspective about their own thoughts and reasoning.
That only applies to many-to-many relations and overly-normalized is nearly as bad as under. Not including that if you have 2 tables with a 32bit int vs one table with a 64bit it, it's a wash. Even in these situations, if you're doing seeks of large many-to-many tables, the random access out-weighs the cost of the extra 4 bytes per field.
I recently was doing performance testing of a tight loop and was comparing 32bit vs 64bit on a 32bit CPU, and the performance was within 10% of each-other. Even when having to do two register loads and combining the registers to emulate 64bit arithmetic, the CPU was able to OoO+pipeline most of the cost. In the end, I have had more situations where using 32bit ints was slower than 64bit.
In before anyone points out about a "work around" for UUID clustered index fragmentation. And don't use sequential UUIDs, I will hate you. They are how you get collisions across systems or even in the same system if two tables have the same seed.
Indexing UUIDs on a large table is a management nightmare. Take about page fragmentation. Joining two large GUID based tables can cause horrible performance corner cases even when clustered. UUIDs should be limited to public data/APIs, but not actually used internally. I do love them for keeping my data sane, but the performance optimizations and management overhead means you need to really think about the issue before you index them. NEVER cluster index them.
Unless your table only has an index, doubling the size of the index is quite moot. IF you knew anything about data alignment, SQL data page layouts, or the slew of meta-data stored along with the data, you would realize it does not matter in nearly every case. It will matter if you're programming in a compile language that allows you to control structure layouts and you need to do a lot of CPU intensive work or need to work with SIMD, but outside of that, 64bit.
I still wonder how these simple edge cases make their way in
I had to look up "Primordial black holes", and that's an interesting theory. These blackholes could actually pass through the Earth on a semi-regular basis.
Nutshell: Blackholes that formed during the early Universe, allowing them to be much smaller because they did not have to form from a dying star. Think in the range of less than a Moon mass.
Too bad them explains it in ways that have been tested to be false.
Certain types of skepticism is just irrationality. Your analogy is completely flawed. A better analogy would be taking a tank of compressed gas into space and finding it implodes instead of explodes, in a vacuum. Not only would it defy expectations, but it would defy all previously known theories in very fundamental ways. No analogy is perfect, but at least try to get the abstract concepts in the same ballpark.