You don't need to write ASM to get large performance increases. I help optimize C# applications all of the time and I can regularly gain 10%-30% performance from simple refactoring that does not affect code readability and without changing the algorithm. Most of what I do is think of how the.Net code will be converted into ASM and how the Garbage Collector will be involved. While GC optimizations gain the most, re-ordering calculations can also give good returns.
Very possible those are some of the issues, but many of the people I am having issues with are some of the best in the industry, skill wise. They came with great recommendations and have many years of experience. They are skilled, but not talented.
Logic is Universal. It does not mean you will come to the same conclusions because of many factors including knowledge, experience, and personal preferences. The logic used to reach the conclusion should be easy to understand for other logical people.
A tip off that you're not thinking logically is if you need to constantly change your mental model. There has been research where a logic test is given to students entering a Computer Science major. They used a pseudo-code language with no rules given and told the students to interpret it. Several examples of input and output for the language were supplied, then a question was asked about a different input, what was the expected output. They gave this test several times throughout the student's carriers. consistency was key. Students who came to the same conclusion, even if they were "wrong", were typically the best programmers. They even tried this test out on students with zero programming background and in other majors, and they got similar results.
Regardless of knowledge or experiencing gained, if you can't come to the same conclusion for a logic test, it's because you're not being logical.
Empirical evidence lies. I have seen O(1) algorithms that run faster on large datasets than O(log n) for micro-benchmarks, but once you put the algorithm into prod, the random memory access was trashing the cache and made it slower while increasing jitter in the system. I told them they were wrong well before they even started performance testing because I thought about the issue for a minute or two.
Metrics are only as good as the person interpreting them.
It is often said that a software architect is your best programmer. The architecture is highly dependent on the implementation and the implementation is highly dependent on the architecture. If the architect is not good at implementation, you get an ivory tower issue.
It is actually part of the architect's responsibility that they make sure the system is implemented the way they envisioned. Leaving the implementation details up to the developer or programmer is just asking for trouble. The responsibility of the architect does not stop at the software. They are also responsible for the hardware and network.
The architect is supposed to take a holistic approach and understand EVERYTHING from security to hardware to optimizations. Ideally, you have exactly one architect and everything is made to fit their vision. In practice, people leave companies, take vacations, and other thing happen. You might have one or two co-architects. It doesn't matter the size of the project, one person to rule them all. If you have more than one person, you will not get seamless integration among the many systems. The end goal is you have one unified vision, and you can't have that with more than one leader.
I should have mentioned, the teams are free to choose their own coding styles for their projects. Only the public APIs adhere to a mostly company style. I would rather read messy logical code than clean illogical code. I've seen the extremes.
You might be mistaking your own way of thinking for universal logic. Without specifics it's hard to know.
I really wrote that horribly. I didn't mean "just like me", it was more of an abstract concept. Here is one example of what I am getting at. I regularly get hit from other programmers to help them and they will say something like "I am getting this result, but if I change this, I get a different result, which result is correct?". Really, this is a WTF moment to me. I really want to say something along the lines of "do you even understand what what your code is doing?!" This happens allllll of the time from so many different programmers. Sometimes they'll be stuck for days and I'll see a group of them gathering, I'll wander over, asked a few questions and the problem will be solved. Sometimes explaining the issue causes their eyes to glaze over.
I have had to work with other programmer's code where they had completely differing ideas about how to solve a problem and they have completely different coding styles, but their logic was consistent. I was able to easily read their code. Same thing for them reading my code. I guess that what I was getting at all along, "programmers like me". My problem is most of us that think alike get stuck on solo projects and rarely get to interact with the team, and our code typically just works well because we think of the corner cases ahead of time, so no one else gets to look at our code. It really sucks. I really love peer programming because I get to learn other ways to think about problems.
The code I typically get to see from other programmers usually makes me want to claw my eyes out. Following best practice and what-not, but the logic behind it is fubar. Somehow most other programmers see this code as great code, but that's why they all group together stumped on problems they can't figure out.
If that's true, that's real problem. I can usually read my own code just fine because I know how I think and have a certain code-writing pattern that is logical TO ME. But other coders often don't agree. I try to figure out why by asking a lot of questions, but it seems to come down to a personal preferences in the end.
Exactly this case, not the later. I work with a lot of complicated problems, like integrating hundreds of different systems from 3rd parties where you need to transform the data in a way the other systems will understand, but at the same time, almost none of the systems follow their own standards very well, so you need to read between the lines and infer what is actually meant by the data. This is a very hard problem, hard enough that Microsoft and Google have come to us for professional consultation because they heard we're the best.
Reading books to gain technical knowledge is a wasted effort. Knowledge can be trivially gained by simply searching the Internet. I read books to gain wisdom. I want to change how I think about programming.
Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.
Then the compiler pads your 1 byte memory location to 8 byte alignment. Unless you have a lot of 1 byte values next to each other. I've seen situations where using smaller data types caused slower performance because of alignment. You may have gained memory at the expense of CPU. At one point, 16 bit ints were actually processed using 32bit logic, which meant that the 16bit values had to be shifted 16bits in order to read into a register. 32bit was faster.
Programming is made to be complex. Unlike surgery and aerospace engineering, you make up your own rules with programming. It's like you can make a virtual world with all kinds of useful laws of physics. Of course, the more complex you make these laws, the more difficult it becomes. Most programmers, given enough time, will turn any project into a ball of mud.
Not necessarily. For one, you should make the code readable by a typical developer, not an ideal developer. You cannot control all future staff.
I work on problems that require an ideal developer just to understand. A problem cannot be simpler than it requires. To simplify it any further would mean you're not solving the problem anymore.
Ironically, sub-ideal programmers are illogical. You are effectively saying one should write illogical code. I have only met two kinds of programmers. Ones that get lost in their own code and need me to help them debug their problems, or programmers who can debug their own code and think very similarly to me. I see programmers who follow every best practice, use the best pattern nearly every time, and write beautiful code, but their code is still shit. It's brittle, it is difficult to debug, it benchmarks fast but is slow a molasses when hammered in prod.
For some reason people chalk this up to "programming is hard and systems are complex". It's really just "problem made harder than it needs to be". It's like looking at a fractal and saying it's complex, when it's really just a simple algorithm.
I forget which "worshiped" programmer said it, but they said they would rather work with a programmer who used every anti-pattern but was intuitively good at programming than a cargo-cult programmer who perfectly used every pattern and best practice. The former will always produce a better product.
I have to disagree, programming is easy. The only time programming is difficult is when someone makes it more difficult than it needs to be. I will agree that nearly all of the yak-shaving has been removed making "programming" easier, but it goes back to my first assertion.
Real programming happens in your head or on a white-board with pseudo-code. Pseudo-code writes exactly the same today as it did 100 years ago, one logical step at a time. If Knuth has made pseudo-code easier to write, then I will agree with you, that he made programming easier.
Step deeper into the world and you'll be truly amazed at how deep it is... and likely staggered that it works as well as it does.
You make it sound like some mystical complex thing. I do think that it is amazing how far computer have come, but I refuse to believe that logic, the cornerstone of programming, is some " deep and mystical" thing. The only thing I am surprised at is how difficult logic is for most programmers and how the state of programming isn't worse than it is.
Don't worry, there is a good chance that we will have to become a Socialist civilization in order to reach a Type 1 or 2 civilization. Once nearly everything is in infinite supply, everything will be free. Let me know how your capitalist society will function in a free economy. But you make a good point, we should not force Socialism, only be aware of it and not fear it. We'll probably need some hybrid to transition.
Humans want to succeed and have a successful lineage, they want to build things, they want to tinker with things, they want to learn things
Those are some rose-tinted glasses you have on. History shows that all of humanity has that potential and the best of us actually aspire to make the world a better place, but the majority of people are fk'n lazy and the only reason they act like they want to work is they want other people to think that they are important.
Don't confuse people wanting to be important and feeling important.
"No better than" assumes there is some universal standard to measure the worth of a person. There is no such thing as good or bad, just what makes the majority of people happier or sadder. Of course I a technologist, so I don't focus only on averages, but also percentiles. I don't just want average happiness to go up, but the 99th percentile as well.
Experience counts for naught. Most developers with 10 years of experience just experience the first year ten times over. Many big tech companies confirm this with their talent search issues. Statistically there is virtually zero difference in skill between someone who has 6 months experience or 20 years. Most people quickly reach their limits.
In my many dealings with world grade technology consulting firms, they are horrible at consulting, but they do make for great human interfacable reference books. Most of the time I spend about 5 minutes reading a Wiki article about a given technology before jumping into a meeting with a specialist, then I poke holes in their logic until their ego is bruised enough to get them to be quiet, then I start asking my questions and finally get somewhere. Their logic and understanding is almost always horribly flawed, but they do know a lot. Their opinions are pretty much useless.
They may know more facts than I do and have dealt with more issues that I have, but I will have vastly more understanding of the domain than they will ever have. Cargo-cult, that is all.
One of my co-workers prototypes all the time. He likes empirical evidence. I am the polar opposite. Not that I hate empirical evidence, but empirical evidence lies too much for me. I mostly just prototype in my head, but I seem to have very accurate mental models.
Empirical evidence will find local minimums, but not global.
TDD stands for Test Driven Development, not Test Driven Design. Architecture and design happens before development. Don't start writing code until you know WTF you're doing. Build some prototypes, but just throw them away once you understand the problem. Same thing with agile. It is not an architecture or design methodology, it is a development methodology.
I've had the opposite experience. Projects that have been going on for years where the code was such a mess that bugs took months to fix, I would re-write from scratch in a month or two and never have another reported bug. Messy code is unmanageable and does not scale. It works for only the simplest of projects. And many times these projects turn into full time jobs because they are important enough to keep working, but messy enough that anything short of a re-write will stop people from complaining.
I love using atomics, but the biggest issue I have with them is the assumptions I make are based on x86 or x64 memory ordering guarantees. Please don't use my code on ARM.
The reason I like using my own atomic thread sync code is I like to write my threaded code to not require exact ordering where possible, as long as the result is the same. Sometimes this results in duplicate work being performed and one of the results effectively discarded, but the reduction in locking overhead is a huge win for scalability.
I've only had an issue with a race-condition once, and that was when I only had a few weeks experience programming. Write you code in a way that guarantees that race conditions can only occur in certain locations and that problem is easy. I have not had to use a debugger to fix a race condition in years now.
My most recent project was extremely async and parallel for highly scalable IO. I told my manager it would take me at least 1 month to write it, I was given a week. I slapped that thing together, stuck it in prod and hoped for the best. Now, 6 months later, Someone had an odd difficult to reproduce issue. I looked at the stack-trace, got a bit perplexed for a few minutes, then realized the problem. Five minutes later I had it fixed. This pretty much describes every race condition I have ever had. Only a few times have I had to use a debugger, and that's because the issue actually existed in someone else's code, to which I did not have access.
My co-workers describe me as having a super-human intuition for debugging code. I seem to have a knack for being able to debug non-reproducible errors in system to which I have never seen the code, nor know the architecture. Based solely on the characteristics of the issue, I can infer the architecture and the nature of the problem. I've never understood other people inability to debug these issues. I just think of many mental models to solutions for the system, then pick a mental model that would have the same symptoms as being described. Nearly every time, the mental model I choose very closely matches the design of the system. People just need to get better at creating viable mental models.
Because there is no such thing as a buffer really, it's an abstraction on memory
And there's no such thing as color, it's just an abstraction of the relation among different optical inputs
And there's not such thing as thought, it's just a complex interaction of chemical reactions
And there's not such thing as random, the Universe is deterministic
And there's not such thing as life, just atoms moving around
Everything we know of in this world is just a collection of characteristics that describe an abstract idea.
Async isn't meant to help cpu intensive work loads. Generally, most computers have too much CPU power and not enough IO or scaling. If you're getting "synchronous freezing" from "cpu intensive" work that needs to be done prior to your IO, you have an easy problem on your hands. Get more cores. If modern CPUs are not enough for your workload, it's probably because you're horrible at coding.
Slashdot Mirror
You don't need to write ASM to get large performance increases. I help optimize C# applications all of the time and I can regularly gain 10%-30% performance from simple refactoring that does not affect code readability and without changing the algorithm. Most of what I do is think of how the .Net code will be converted into ASM and how the Garbage Collector will be involved. While GC optimizations gain the most, re-ordering calculations can also give good returns.
Very possible those are some of the issues, but many of the people I am having issues with are some of the best in the industry, skill wise. They came with great recommendations and have many years of experience. They are skilled, but not talented.
Logic is Universal. It does not mean you will come to the same conclusions because of many factors including knowledge, experience, and personal preferences. The logic used to reach the conclusion should be easy to understand for other logical people.
A tip off that you're not thinking logically is if you need to constantly change your mental model. There has been research where a logic test is given to students entering a Computer Science major. They used a pseudo-code language with no rules given and told the students to interpret it. Several examples of input and output for the language were supplied, then a question was asked about a different input, what was the expected output. They gave this test several times throughout the student's carriers. consistency was key. Students who came to the same conclusion, even if they were "wrong", were typically the best programmers. They even tried this test out on students with zero programming background and in other majors, and they got similar results.
Regardless of knowledge or experiencing gained, if you can't come to the same conclusion for a logic test, it's because you're not being logical.
Empirical evidence lies. I have seen O(1) algorithms that run faster on large datasets than O(log n) for micro-benchmarks, but once you put the algorithm into prod, the random memory access was trashing the cache and made it slower while increasing jitter in the system. I told them they were wrong well before they even started performance testing because I thought about the issue for a minute or two.
Metrics are only as good as the person interpreting them.
It is often said that a software architect is your best programmer. The architecture is highly dependent on the implementation and the implementation is highly dependent on the architecture. If the architect is not good at implementation, you get an ivory tower issue.
It is actually part of the architect's responsibility that they make sure the system is implemented the way they envisioned. Leaving the implementation details up to the developer or programmer is just asking for trouble. The responsibility of the architect does not stop at the software. They are also responsible for the hardware and network.
The architect is supposed to take a holistic approach and understand EVERYTHING from security to hardware to optimizations. Ideally, you have exactly one architect and everything is made to fit their vision. In practice, people leave companies, take vacations, and other thing happen. You might have one or two co-architects. It doesn't matter the size of the project, one person to rule them all. If you have more than one person, you will not get seamless integration among the many systems. The end goal is you have one unified vision, and you can't have that with more than one leader.
I should have mentioned, the teams are free to choose their own coding styles for their projects. Only the public APIs adhere to a mostly company style. I would rather read messy logical code than clean illogical code. I've seen the extremes.
You might be mistaking your own way of thinking for universal logic. Without specifics it's hard to know.
I really wrote that horribly. I didn't mean "just like me", it was more of an abstract concept. Here is one example of what I am getting at. I regularly get hit from other programmers to help them and they will say something like "I am getting this result, but if I change this, I get a different result, which result is correct?". Really, this is a WTF moment to me. I really want to say something along the lines of "do you even understand what what your code is doing?!" This happens allllll of the time from so many different programmers. Sometimes they'll be stuck for days and I'll see a group of them gathering, I'll wander over, asked a few questions and the problem will be solved. Sometimes explaining the issue causes their eyes to glaze over.
I have had to work with other programmer's code where they had completely differing ideas about how to solve a problem and they have completely different coding styles, but their logic was consistent. I was able to easily read their code. Same thing for them reading my code. I guess that what I was getting at all along, "programmers like me". My problem is most of us that think alike get stuck on solo projects and rarely get to interact with the team, and our code typically just works well because we think of the corner cases ahead of time, so no one else gets to look at our code. It really sucks. I really love peer programming because I get to learn other ways to think about problems.
The code I typically get to see from other programmers usually makes me want to claw my eyes out. Following best practice and what-not, but the logic behind it is fubar. Somehow most other programmers see this code as great code, but that's why they all group together stumped on problems they can't figure out.
If that's true, that's real problem. I can usually read my own code just fine because I know how I think and have a certain code-writing pattern that is logical TO ME. But other coders often don't agree. I try to figure out why by asking a lot of questions, but it seems to come down to a personal preferences in the end.
Exactly this case, not the later. I work with a lot of complicated problems, like integrating hundreds of different systems from 3rd parties where you need to transform the data in a way the other systems will understand, but at the same time, almost none of the systems follow their own standards very well, so you need to read between the lines and infer what is actually meant by the data. This is a very hard problem, hard enough that Microsoft and Google have come to us for professional consultation because they heard we're the best.
Reading books to gain technical knowledge is a wasted effort. Knowledge can be trivially gained by simply searching the Internet. I read books to gain wisdom. I want to change how I think about programming.
Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.
Then the compiler pads your 1 byte memory location to 8 byte alignment. Unless you have a lot of 1 byte values next to each other. I've seen situations where using smaller data types caused slower performance because of alignment. You may have gained memory at the expense of CPU. At one point, 16 bit ints were actually processed using 32bit logic, which meant that the 16bit values had to be shifted 16bits in order to read into a register. 32bit was faster.
Programming is made to be complex. Unlike surgery and aerospace engineering, you make up your own rules with programming. It's like you can make a virtual world with all kinds of useful laws of physics. Of course, the more complex you make these laws, the more difficult it becomes. Most programmers, given enough time, will turn any project into a ball of mud.
PHP has many many idiosyncrasies that violate the principle of least astonishment.
Not necessarily. For one, you should make the code readable by a typical developer, not an ideal developer. You cannot control all future staff.
I work on problems that require an ideal developer just to understand. A problem cannot be simpler than it requires. To simplify it any further would mean you're not solving the problem anymore.
Ironically, sub-ideal programmers are illogical. You are effectively saying one should write illogical code. I have only met two kinds of programmers. Ones that get lost in their own code and need me to help them debug their problems, or programmers who can debug their own code and think very similarly to me. I see programmers who follow every best practice, use the best pattern nearly every time, and write beautiful code, but their code is still shit. It's brittle, it is difficult to debug, it benchmarks fast but is slow a molasses when hammered in prod.
For some reason people chalk this up to "programming is hard and systems are complex". It's really just "problem made harder than it needs to be". It's like looking at a fractal and saying it's complex, when it's really just a simple algorithm.
I forget which "worshiped" programmer said it, but they said they would rather work with a programmer who used every anti-pattern but was intuitively good at programming than a cargo-cult programmer who perfectly used every pattern and best practice. The former will always produce a better product.
Real programming happens in your head or on a white-board with pseudo-code. Pseudo-code writes exactly the same today as it did 100 years ago, one logical step at a time. If Knuth has made pseudo-code easier to write, then I will agree with you, that he made programming easier.
Step deeper into the world and you'll be truly amazed at how deep it is ... and likely staggered that it works as well as it does.
You make it sound like some mystical complex thing. I do think that it is amazing how far computer have come, but I refuse to believe that logic, the cornerstone of programming, is some " deep and mystical" thing. The only thing I am surprised at is how difficult logic is for most programmers and how the state of programming isn't worse than it is.
Don't worry, there is a good chance that we will have to become a Socialist civilization in order to reach a Type 1 or 2 civilization. Once nearly everything is in infinite supply, everything will be free. Let me know how your capitalist society will function in a free economy. But you make a good point, we should not force Socialism, only be aware of it and not fear it. We'll probably need some hybrid to transition.
Humans want to succeed and have a successful lineage, they want to build things, they want to tinker with things, they want to learn things
Those are some rose-tinted glasses you have on. History shows that all of humanity has that potential and the best of us actually aspire to make the world a better place, but the majority of people are fk'n lazy and the only reason they act like they want to work is they want other people to think that they are important.
Don't confuse people wanting to be important and feeling important.
No where near 20% unemployment. Last new headline from the past few days said between 4-5%. 20% may include retired people or people who cannot work.
"No better than" assumes there is some universal standard to measure the worth of a person. There is no such thing as good or bad, just what makes the majority of people happier or sadder. Of course I a technologist, so I don't focus only on averages, but also percentiles. I don't just want average happiness to go up, but the 99th percentile as well.
Experience counts for naught. Most developers with 10 years of experience just experience the first year ten times over. Many big tech companies confirm this with their talent search issues. Statistically there is virtually zero difference in skill between someone who has 6 months experience or 20 years. Most people quickly reach their limits.
In my many dealings with world grade technology consulting firms, they are horrible at consulting, but they do make for great human interfacable reference books. Most of the time I spend about 5 minutes reading a Wiki article about a given technology before jumping into a meeting with a specialist, then I poke holes in their logic until their ego is bruised enough to get them to be quiet, then I start asking my questions and finally get somewhere. Their logic and understanding is almost always horribly flawed, but they do know a lot. Their opinions are pretty much useless.
They may know more facts than I do and have dealt with more issues that I have, but I will have vastly more understanding of the domain than they will ever have. Cargo-cult, that is all.
One of my co-workers prototypes all the time. He likes empirical evidence. I am the polar opposite. Not that I hate empirical evidence, but empirical evidence lies too much for me. I mostly just prototype in my head, but I seem to have very accurate mental models.
Empirical evidence will find local minimums, but not global.
TDD stands for Test Driven Development, not Test Driven Design. Architecture and design happens before development. Don't start writing code until you know WTF you're doing. Build some prototypes, but just throw them away once you understand the problem. Same thing with agile. It is not an architecture or design methodology, it is a development methodology.
I've had the opposite experience. Projects that have been going on for years where the code was such a mess that bugs took months to fix, I would re-write from scratch in a month or two and never have another reported bug. Messy code is unmanageable and does not scale. It works for only the simplest of projects. And many times these projects turn into full time jobs because they are important enough to keep working, but messy enough that anything short of a re-write will stop people from complaining.
I love using atomics, but the biggest issue I have with them is the assumptions I make are based on x86 or x64 memory ordering guarantees. Please don't use my code on ARM.
The reason I like using my own atomic thread sync code is I like to write my threaded code to not require exact ordering where possible, as long as the result is the same. Sometimes this results in duplicate work being performed and one of the results effectively discarded, but the reduction in locking overhead is a huge win for scalability.
I've only had an issue with a race-condition once, and that was when I only had a few weeks experience programming. Write you code in a way that guarantees that race conditions can only occur in certain locations and that problem is easy. I have not had to use a debugger to fix a race condition in years now.
My most recent project was extremely async and parallel for highly scalable IO. I told my manager it would take me at least 1 month to write it, I was given a week. I slapped that thing together, stuck it in prod and hoped for the best. Now, 6 months later, Someone had an odd difficult to reproduce issue. I looked at the stack-trace, got a bit perplexed for a few minutes, then realized the problem. Five minutes later I had it fixed. This pretty much describes every race condition I have ever had. Only a few times have I had to use a debugger, and that's because the issue actually existed in someone else's code, to which I did not have access.
My co-workers describe me as having a super-human intuition for debugging code. I seem to have a knack for being able to debug non-reproducible errors in system to which I have never seen the code, nor know the architecture. Based solely on the characteristics of the issue, I can infer the architecture and the nature of the problem. I've never understood other people inability to debug these issues. I just think of many mental models to solutions for the system, then pick a mental model that would have the same symptoms as being described. Nearly every time, the mental model I choose very closely matches the design of the system. People just need to get better at creating viable mental models.
Because there is no such thing as a buffer really, it's an abstraction on memory
And there's no such thing as color, it's just an abstraction of the relation among different optical inputs
And there's not such thing as thought, it's just a complex interaction of chemical reactions
And there's not such thing as random, the Universe is deterministic
And there's not such thing as life, just atoms moving around
Everything we know of in this world is just a collection of characteristics that describe an abstract idea.
Async isn't meant to help cpu intensive work loads. Generally, most computers have too much CPU power and not enough IO or scaling. If you're getting "synchronous freezing" from "cpu intensive" work that needs to be done prior to your IO, you have an easy problem on your hands. Get more cores. If modern CPUs are not enough for your workload, it's probably because you're horrible at coding.