If blacks commit 2x as many crimes, then they should be arrested 2x as much
There can also be self-reinforcing statistics. Just for argument's sake, lets assume blacks constitute 2x of the arrests. That does not mean they're committing crimes 2x more often, just that they're being caught 2x more often. It is possible for blacks to get more closely scrutinized than whites, possibly resulting in more white criminals not being caught.
You need to be very careful when interpreting what a number means. And like all facts, interpretations are subjective.
Whoosh? Statistics can tell you what the group does, but not what the individual does.Statistics can give fun paradoxes like men are both smarter and dumber than women, because of the squashed bell-curve. Numbers do not represent concrete things, only concepts(abstractions). You need to get better an interpreting what numbers mean.
You don't need QoS, you just need fair queuing, which is protocol agnostic. My ISP has zero QoS for any non-management traffic. They have a fully guaranteed bandwidth through the entire network from customer to the trunk. Even on my connection, they have some fair queuing AQM that allows me to saturate my connection both up and down at the same time with P2P traffic, and still get zero loss, zero jitter, and idle level latency.
It does not matter what traffic I use, fairness is effectively maintained per flow. A greedy stream can only affect its own latency, loss, and jitter. Not only does this statistically isolate streams from each other statelessly, important for scaling to many streams. But it also helps stabilize greedy flows. Loss is minimized, jitter is minimized, latency is minimized, utilization can remain at a steady 99.9%, no TCP saw-tooth action. This almost completely eliminates bursted loss caused by dumb fixed FIFO queues. With my current AQM, TCP almost never enters exponential backoff.
This also has a positive effect on DOS attacks. A simulated DDOS attack still negatively affects packetloss and bandwidth because the too many source IPs overwhelm the statistical flow isolation, but a relatively few source IPs attempted to do a volumetric DOS has little affect on anything but bandwidth. Because the flows are isolated for latency and loss, the only thing affected is bandwidth, and even that is fairly distributed across flows.
These modern AQMs make the internet feel much faster by minimizing buffer bloat and keeping the TCP window near optimal to keep latency nearly unaffected while allowing bandwidth to be maximized and stabilizes the bandwidth. It also keeps TCP global synchronization from occurring.
This same kind of feature seems to be applied at all levels. The ISP's trunk seems to have this. During a DDOS against the entire ISP, latency was about 20ms higher than normal and bandwidth was about 30% of my provisioned, but virtually zero loss or jitter. I could still play games just fine. Another time the transit provider was under attack. Similar characteristics but 2 hops further upstream. A few 10s of ms increased base latency, still almost no loss or jitter, but reduced bandwidth.
There is no reason for congestion to affect loss, jitter, or latency by any detrimental amount. Look into Codel, PIE, and their fair queuing versions, like fq_codel. Freaking magic.
I have three cats. If I say one of their names, the other two may move their ears or not, but the one who's name I called almost always sits up and looks at me with focus. We've had a few cats over the years and it always seems like one cat at any given time has separation anxiety.
It's not missing mass. We think it's missing matter because it's the only thing not moving at the speed of light that could explain the observed mass which has no corresponding matter.
Theories pointing to something missing is much less interesting than observations objectively showing that something is missing, which is what the Dark Matter phenomena is.
People learn new skills, but those skills devalue about as fast as they learn them. People in senior roles are constantly having to herd sheep. Left to their own devices, most programmers have a hammer and treat everything as a nail. They learn new skills, but they keep making the same type of mistakes, even if technically a different mistake.
I'm not saying that these people are "bad", but they're not self-correcting. Their errors amplify over time if someone isn't there to constantly compensate for them.
It is a fact that nearly everyone reaches peak abstract reasoning in their mid-teens and have a huge drop in their early 30s. Beyond a certain point, abstract reasoning is inversely proportional to knowledge. Learning abstract concepts do not count as "knowledge" and does not negatively affect one's abstract reasoning. A tiny portion of the population can maintain their abstract reasoning for a long time. This skill is an absolute requirement for programming. This probably why most programmers get "behind the times" in their old age. They have all of this knowledge, but their reasoning is now shit. And not to conflate reasoning with wisdom. Abstract reasoning is also needed to learn new skills.
It seems to be a constant factor that people who maintain their abstract reasoning into old age have learned the art of forgetting details. Not a joke about old age. Rote memorization is literally the enemy of reasoning.
In my very limited experience over the past 10 years, junior positions are almost always of negative immediate value and primarily used to discover or attract young talent. Even normal positions are of about break-even value. It's only once you get to people of a senior role, even if not an official job title, that you get people where they can take a 6 month team project and solo it in 1 month or fix a bug that someone has been working on for several months, in a matter of days. And not to say that the senior person is working any more hours.
In general, for our roles, the break even time before an engineer produces the same value as we pay them is about 6 months to a year. The point where they regularly provide more value than they cost is about 2-3 years.
We tend to see two types of software developers. The kind that like to be told what to do and the kind that find ways to improve existing processes. The later have poor personal productivity but bring very high team/group productivity. The 80/20 rule seems to apply. About 20% of the programmers come up with 80% of the useful process or system improvements.
You would think the other 80% of programmers would get automated out of a job, but in our area, the better we make our processes, the smoother and higher quality our product is. This causes an increase in demand. On the whole, we need to periodically hire more engineers because we can't improve our systems faster than demand increases. About 20-40% yoy increase in demand for the past 15 years. It's nearly impossible to automate away people's jobs with that demand. CPO(Chief Product Officer) is biting at the bit to open the flood gates for our services.
The most important requirement to keeping up is thinking ahead. Our idea creators are coming up ideas for improvements several years ahead of needing those improvements. That gives us some time to start preparing. We keep surviving only by the skin of our teeth, and that isn't luck, it's preparedness. At any given time, we have about a 2-3 year backlog of improvements. That's 2-3 years of work if that's all we worked on. And virtually none of the ideas get dropped and nearly all of the ideas have eventually been implemented after some time. Only a few keep getting pushed. Not because they aren't useful, but because there's always something deemed more pressing.
lol, you think unions protect their member. I've worked at a couple factory places with unions and almost everyone hates them. It's like a bureaucracy with power over both the employer and employee. They do the absolute minimum, but at the same time if anything threatens their power, they will fight it full on. Even the long term employees complain how unfair the union is to the employer and how it reduces the quality of life at work.
I forgot to mention that the performance changes that I made were almost all changes that they say to "never" do because you'll make it slower. Funny how thing that should "never" be done because of some objectively measurable negative behavior can create a objective measurable positive result in the same behavior in some extreme corner cases. "Never" just means "you" will probably do it wrong. Simple solution, don't do it wrong.
Such a blind rage of ignorance. It's like you think all work loads could be restructured to work well on a GPU.
Imagine a language with all immutable data and no side effects. It would be the purest of all languages and completely useless. You can minimize the amount of things that need to be shared, but you can never get rid of them all. I am in no way trying to have shared data.
Concurrency is not difficult, in user space. I make no claims about kernel space. I have always found all things concurrency to be intuitively solved. ARM CPUs require a different strategy for optimizations. What is a low latency atomic CAS on x86 that has never been a source of contention for me is some horribly slow operation on ARM that Amdahl's Law strikes you down with. You can change your design, but in some cases it's a re-architecture, depending on how performance sensitive and specialized the system is. This can make it expensive to transition to ARM. Even once you're on ARM, it's bad for any situations where the mutable data wasn't a point of contention on x86.
You have to understand where I am coming from. I am known in my company to be great at optimizations. I can generally make someone else's code 10x-100x faster without concurrency. Even when I'm complaining about something being 1/2 as fast as it could be, it's still a magnitude faster than what my peers are making.
What really put me on the map is when our DBA, who is very active in the SQL community and considered a senior member in some circles, and programmer had been working on a process that was taking 30 hours to run and the customer was complaining. I read over the several pages of code in 15 minutes and gave some recommendations before they started. After a month or tracing and testing, they were able to get it down to around 15 hours. I looked over the changes and noticed they did not make a single one that I recommended. At the time 15 hours was "good enough". Fast forward a year later, and the amount of data doubled, causing the run time to double. Back up to 30 hours. I just opened up the project, made all of the changes that I recommended in a matter of 1-2 hours, kicked off the job to test it, and it finished in 1 hour with the exact same results. That was the only test I did, and it passed the first time, and was 30x faster.
I do the same kind of crap with concurrency. All intuition.
I'm doing the same job. To "do all the things". I've gotten better at doing all things and I can do more things than others, but it's the same job with the same responsibilities. But pretty much everyone here gets at least a 2.5% increase every year.
ONLY true when the ARM's performance is significantly less than Intel/AMD as well. Beef an ARM up to i9 specs, and it's going to burn as much power and throw off as much total heat AS an i9 with identical raw performance.
It's actually worse. You can't really have high performance and low power usage at the same time, it's a trade off. CPUs have gotten better, but the transistors themselves become more leaky when you design for higher performance, among other architectural trade offs made to increase performance. And pushing transistors optimized for low power to be faster will consume more power than transistors optimized for high performance. The gap is shrinking (pun), but it's still a practical difference.
It can only be scaled so well because it trades throughput for latency when it comes to cross-core communications. This makes any concurrent workload where there is lots of shared mutable data very slow or requires a completely different design. Message passing could be done, but it does use more memory, which means more cache is used and more memory bandwidth is used. Every design has its pro and cons.
Trains are dying out because of cars. But as long as there's a heavy load to move, trains will exist. FreeBSD is primarily used in infrastructure roles. Plenty of anecdotes of system admins for large datacenters where they switched to FreeBSD because Linux kept crashing under high loads. FreeBSD also holds a near monopoly on publicly funded research and RFCs, both of which need to be open for all uses, which the GPL does not allow.
Linux is great, but it does have its short-comings when you focus on sys-admin friendliness and engineered designs.
Intel/AMD use less power than ARM when it comes to compute loads. ARM is great for high idle and they're claiming IO loads. I wouldn't mind a many core ARM file server or router, but not an app server where the server is under high load.
Most normal people don't hyperfocus. They may focus for a long time, but that's not hyper-focusing. Generally, only people with learning "disabilities", aka learning differently, can hyperfocus in certain situations. Hyperfocusing is not a conscious effort and you rarely realize when you're doing it. It's only after the fact that you think it's been 30 minutes but your stomach is grumbling and it's actually been several hours.
I have ADD and used to hyperfocus more often when I was younger, but as I got older, I've gotten better at some things and find that I can now "burst" intense thought much faster. If I am working on an intensely hard problem, instead of hyper-focusing for several hours, I can now burn through an entire day's worth of mental energy before the hyperfocusing has time to set in. This may sound like a negative thing, but it's not. Some problems are not about how many little problems need to be solved, but instead is about solving a huge single problem.
Hyperfocusing is about reaching maximum concentration and maintaining that for abnormally long periods of time, but it doesn't really help you solve a more difficult problem, it just means increased efficiency of the focused problem. Some problems are not problems of determination, but hurdles that must be overcome in a single bound. In these cases, there is no "I kind of understand". Either you completely understand or you don't at all. There is no progress until you're done. What you need is power density, not energy density, to use an energy analogy.
The difference between 30fps, 60fps, and 120fps is when an object is moving quickly, it's the difference between 2 frames, 4 frames, or 8 frames. Easier to predict motion with 8 frames of information.
The brain doesn't see in frames, but a continuous integration. Frames mess with the visual system's ability to motion track. When playing World of Warcraft and there's lots of FX going on, if the FPS dips below 50, it gets hard to track players. This negatively affects my ability to properly position myself.
Back when I played FPS games on my CRT, I had a 75hz CRT and my friend had 85hz. His video card could maintain a stable at least 85fps. At first I was playing and it felt "smoother". Then he changed games. When playing the other game, I told him it felt "choppy". Went into the graphics settings and the game was set to 75hz. Set to 85hz and it felt smoother again.
"Low" FPS with high paced action results in a strobe effect where objects teleport across the screen. Visual tracking system is not meant for this.
Compared to? Netflix has 61mil subscribers in the USA alone, with an average of 10 hours per week. Most forms of entertainment are less mentally engaging than video games.
I used to play 8-16 hours a day from 12 to 30. 5 hours doesn't sound like much, even if a single day. Even for a normal person, 5 hours of any form of entertainment per week, even on a single day, is the norm.
All the technical expertise you ever need to know was made back in the 60s and 70s. You don't need to keep up to date with the latest variant implementation of some 60 year old concept. The fundamentals of computing have not changed since the 1600s when the first programmers became. A few centuries later, there was finally some machines to automatically run their code.
Slashdot Mirror
If blacks commit 2x as many crimes, then they should be arrested 2x as much
There can also be self-reinforcing statistics. Just for argument's sake, lets assume blacks constitute 2x of the arrests. That does not mean they're committing crimes 2x more often, just that they're being caught 2x more often. It is possible for blacks to get more closely scrutinized than whites, possibly resulting in more white criminals not being caught.
You need to be very careful when interpreting what a number means. And like all facts, interpretations are subjective.
Whoosh? Statistics can tell you what the group does, but not what the individual does.Statistics can give fun paradoxes like men are both smarter and dumber than women, because of the squashed bell-curve. Numbers do not represent concrete things, only concepts(abstractions). You need to get better an interpreting what numbers mean.
If it's not true random, it has a bias. They really need to define which biases.
You don't need QoS, you just need fair queuing, which is protocol agnostic. My ISP has zero QoS for any non-management traffic. They have a fully guaranteed bandwidth through the entire network from customer to the trunk. Even on my connection, they have some fair queuing AQM that allows me to saturate my connection both up and down at the same time with P2P traffic, and still get zero loss, zero jitter, and idle level latency.
It does not matter what traffic I use, fairness is effectively maintained per flow. A greedy stream can only affect its own latency, loss, and jitter. Not only does this statistically isolate streams from each other statelessly, important for scaling to many streams. But it also helps stabilize greedy flows. Loss is minimized, jitter is minimized, latency is minimized, utilization can remain at a steady 99.9%, no TCP saw-tooth action. This almost completely eliminates bursted loss caused by dumb fixed FIFO queues. With my current AQM, TCP almost never enters exponential backoff.
This also has a positive effect on DOS attacks. A simulated DDOS attack still negatively affects packetloss and bandwidth because the too many source IPs overwhelm the statistical flow isolation, but a relatively few source IPs attempted to do a volumetric DOS has little affect on anything but bandwidth. Because the flows are isolated for latency and loss, the only thing affected is bandwidth, and even that is fairly distributed across flows.
These modern AQMs make the internet feel much faster by minimizing buffer bloat and keeping the TCP window near optimal to keep latency nearly unaffected while allowing bandwidth to be maximized and stabilizes the bandwidth. It also keeps TCP global synchronization from occurring.
This same kind of feature seems to be applied at all levels. The ISP's trunk seems to have this. During a DDOS against the entire ISP, latency was about 20ms higher than normal and bandwidth was about 30% of my provisioned, but virtually zero loss or jitter. I could still play games just fine. Another time the transit provider was under attack. Similar characteristics but 2 hops further upstream. A few 10s of ms increased base latency, still almost no loss or jitter, but reduced bandwidth.
There is no reason for congestion to affect loss, jitter, or latency by any detrimental amount. Look into Codel, PIE, and their fair queuing versions, like fq_codel. Freaking magic.
I have three cats. If I say one of their names, the other two may move their ears or not, but the one who's name I called almost always sits up and looks at me with focus. We've had a few cats over the years and it always seems like one cat at any given time has separation anxiety.
It's not missing mass. We think it's missing matter because it's the only thing not moving at the speed of light that could explain the observed mass which has no corresponding matter.
Theories pointing to something missing is much less interesting than observations objectively showing that something is missing, which is what the Dark Matter phenomena is.
People learn new skills, but those skills devalue about as fast as they learn them. People in senior roles are constantly having to herd sheep. Left to their own devices, most programmers have a hammer and treat everything as a nail. They learn new skills, but they keep making the same type of mistakes, even if technically a different mistake.
I'm not saying that these people are "bad", but they're not self-correcting. Their errors amplify over time if someone isn't there to constantly compensate for them.
It is a fact that nearly everyone reaches peak abstract reasoning in their mid-teens and have a huge drop in their early 30s. Beyond a certain point, abstract reasoning is inversely proportional to knowledge. Learning abstract concepts do not count as "knowledge" and does not negatively affect one's abstract reasoning. A tiny portion of the population can maintain their abstract reasoning for a long time. This skill is an absolute requirement for programming. This probably why most programmers get "behind the times" in their old age. They have all of this knowledge, but their reasoning is now shit. And not to conflate reasoning with wisdom. Abstract reasoning is also needed to learn new skills.
It seems to be a constant factor that people who maintain their abstract reasoning into old age have learned the art of forgetting details. Not a joke about old age. Rote memorization is literally the enemy of reasoning.
In my very limited experience over the past 10 years, junior positions are almost always of negative immediate value and primarily used to discover or attract young talent. Even normal positions are of about break-even value. It's only once you get to people of a senior role, even if not an official job title, that you get people where they can take a 6 month team project and solo it in 1 month or fix a bug that someone has been working on for several months, in a matter of days. And not to say that the senior person is working any more hours.
In general, for our roles, the break even time before an engineer produces the same value as we pay them is about 6 months to a year. The point where they regularly provide more value than they cost is about 2-3 years.
We tend to see two types of software developers. The kind that like to be told what to do and the kind that find ways to improve existing processes. The later have poor personal productivity but bring very high team/group productivity. The 80/20 rule seems to apply. About 20% of the programmers come up with 80% of the useful process or system improvements.
You would think the other 80% of programmers would get automated out of a job, but in our area, the better we make our processes, the smoother and higher quality our product is. This causes an increase in demand. On the whole, we need to periodically hire more engineers because we can't improve our systems faster than demand increases. About 20-40% yoy increase in demand for the past 15 years. It's nearly impossible to automate away people's jobs with that demand. CPO(Chief Product Officer) is biting at the bit to open the flood gates for our services.
The most important requirement to keeping up is thinking ahead. Our idea creators are coming up ideas for improvements several years ahead of needing those improvements. That gives us some time to start preparing. We keep surviving only by the skin of our teeth, and that isn't luck, it's preparedness. At any given time, we have about a 2-3 year backlog of improvements. That's 2-3 years of work if that's all we worked on. And virtually none of the ideas get dropped and nearly all of the ideas have eventually been implemented after some time. Only a few keep getting pushed. Not because they aren't useful, but because there's always something deemed more pressing.
lol, you think unions protect their member. I've worked at a couple factory places with unions and almost everyone hates them. It's like a bureaucracy with power over both the employer and employee. They do the absolute minimum, but at the same time if anything threatens their power, they will fight it full on. Even the long term employees complain how unfair the union is to the employer and how it reduces the quality of life at work.
I forgot to mention that the performance changes that I made were almost all changes that they say to "never" do because you'll make it slower. Funny how thing that should "never" be done because of some objectively measurable negative behavior can create a objective measurable positive result in the same behavior in some extreme corner cases. "Never" just means "you" will probably do it wrong. Simple solution, don't do it wrong.
Such a blind rage of ignorance. It's like you think all work loads could be restructured to work well on a GPU.
Imagine a language with all immutable data and no side effects. It would be the purest of all languages and completely useless. You can minimize the amount of things that need to be shared, but you can never get rid of them all. I am in no way trying to have shared data.
Concurrency is not difficult, in user space. I make no claims about kernel space. I have always found all things concurrency to be intuitively solved. ARM CPUs require a different strategy for optimizations. What is a low latency atomic CAS on x86 that has never been a source of contention for me is some horribly slow operation on ARM that Amdahl's Law strikes you down with. You can change your design, but in some cases it's a re-architecture, depending on how performance sensitive and specialized the system is. This can make it expensive to transition to ARM. Even once you're on ARM, it's bad for any situations where the mutable data wasn't a point of contention on x86.
You have to understand where I am coming from. I am known in my company to be great at optimizations. I can generally make someone else's code 10x-100x faster without concurrency. Even when I'm complaining about something being 1/2 as fast as it could be, it's still a magnitude faster than what my peers are making.
What really put me on the map is when our DBA, who is very active in the SQL community and considered a senior member in some circles, and programmer had been working on a process that was taking 30 hours to run and the customer was complaining. I read over the several pages of code in 15 minutes and gave some recommendations before they started. After a month or tracing and testing, they were able to get it down to around 15 hours. I looked over the changes and noticed they did not make a single one that I recommended. At the time 15 hours was "good enough". Fast forward a year later, and the amount of data doubled, causing the run time to double. Back up to 30 hours. I just opened up the project, made all of the changes that I recommended in a matter of 1-2 hours, kicked off the job to test it, and it finished in 1 hour with the exact same results. That was the only test I did, and it passed the first time, and was 30x faster.
I do the same kind of crap with concurrency. All intuition.
I'm doing the same job. To "do all the things". I've gotten better at doing all things and I can do more things than others, but it's the same job with the same responsibilities. But pretty much everyone here gets at least a 2.5% increase every year.
ONLY true when the ARM's performance is significantly less than Intel/AMD as well. Beef an ARM up to i9 specs, and it's going to burn as much power and throw off as much total heat AS an i9 with identical raw performance.
It's actually worse. You can't really have high performance and low power usage at the same time, it's a trade off. CPUs have gotten better, but the transistors themselves become more leaky when you design for higher performance, among other architectural trade offs made to increase performance. And pushing transistors optimized for low power to be faster will consume more power than transistors optimized for high performance. The gap is shrinking (pun), but it's still a practical difference.
It can only be scaled so well because it trades throughput for latency when it comes to cross-core communications. This makes any concurrent workload where there is lots of shared mutable data very slow or requires a completely different design. Message passing could be done, but it does use more memory, which means more cache is used and more memory bandwidth is used. Every design has its pro and cons.
Trains are dying out because of cars. But as long as there's a heavy load to move, trains will exist. FreeBSD is primarily used in infrastructure roles. Plenty of anecdotes of system admins for large datacenters where they switched to FreeBSD because Linux kept crashing under high loads. FreeBSD also holds a near monopoly on publicly funded research and RFCs, both of which need to be open for all uses, which the GPL does not allow.
Linux is great, but it does have its short-comings when you focus on sys-admin friendliness and engineered designs.
Intel/AMD use less power than ARM when it comes to compute loads. ARM is great for high idle and they're claiming IO loads. I wouldn't mind a many core ARM file server or router, but not an app server where the server is under high load.
Would you say that it's irrational to do so?
I have 20/15 vision and can read incredibly close to my face. I need glasses to reduce fatigue from too much reading and office light exposure.
Most normal people don't hyperfocus. They may focus for a long time, but that's not hyper-focusing. Generally, only people with learning "disabilities", aka learning differently, can hyperfocus in certain situations. Hyperfocusing is not a conscious effort and you rarely realize when you're doing it. It's only after the fact that you think it's been 30 minutes but your stomach is grumbling and it's actually been several hours.
I have ADD and used to hyperfocus more often when I was younger, but as I got older, I've gotten better at some things and find that I can now "burst" intense thought much faster. If I am working on an intensely hard problem, instead of hyper-focusing for several hours, I can now burn through an entire day's worth of mental energy before the hyperfocusing has time to set in. This may sound like a negative thing, but it's not. Some problems are not about how many little problems need to be solved, but instead is about solving a huge single problem.
Hyperfocusing is about reaching maximum concentration and maintaining that for abnormally long periods of time, but it doesn't really help you solve a more difficult problem, it just means increased efficiency of the focused problem. Some problems are not problems of determination, but hurdles that must be overcome in a single bound. In these cases, there is no "I kind of understand". Either you completely understand or you don't at all. There is no progress until you're done. What you need is power density, not energy density, to use an energy analogy.
The difference between 30fps, 60fps, and 120fps is when an object is moving quickly, it's the difference between 2 frames, 4 frames, or 8 frames. Easier to predict motion with 8 frames of information.
The brain doesn't see in frames, but a continuous integration. Frames mess with the visual system's ability to motion track. When playing World of Warcraft and there's lots of FX going on, if the FPS dips below 50, it gets hard to track players. This negatively affects my ability to properly position myself.
Back when I played FPS games on my CRT, I had a 75hz CRT and my friend had 85hz. His video card could maintain a stable at least 85fps. At first I was playing and it felt "smoother". Then he changed games. When playing the other game, I told him it felt "choppy". Went into the graphics settings and the game was set to 75hz. Set to 85hz and it felt smoother again.
"Low" FPS with high paced action results in a strobe effect where objects teleport across the screen. Visual tracking system is not meant for this.
Compared to? Netflix has 61mil subscribers in the USA alone, with an average of 10 hours per week. Most forms of entertainment are less mentally engaging than video games.
I used to play 8-16 hours a day from 12 to 30. 5 hours doesn't sound like much, even if a single day. Even for a normal person, 5 hours of any form of entertainment per week, even on a single day, is the norm.
All the technical expertise you ever need to know was made back in the 60s and 70s. You don't need to keep up to date with the latest variant implementation of some 60 year old concept. The fundamentals of computing have not changed since the 1600s when the first programmers became. A few centuries later, there was finally some machines to automatically run their code.