5 ms·

In this case: nothing. The fast renderer was written by one person in a few days. It's clearly a "few thousand loc" codebase, not "millions loc". The 100x slo

by kjksf 5y ago

In this case: nothing. The fast renderer was written by one person in a few days. It's clearly a "few thousand loc" codebase, not "millions loc". The 100x slower renderer was also written by one person (or at most few). It really is the difference between programmers. It's also a good example that 10x programmers do exist, at least in certain situations. The Microsoft programmers are not dumb. They certainly are not cheap. And yet here we have one guy who can write code that is 10-100x faster, in just few days.

Zababa 5y ago
I don't think that's exactly true. It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part. > The 100x slower renderer was also written by one person (or at most few). The difference between one person and a few is massive in my experience. > It really is the difference between programmers. > It's also a good example that 10x programmers do exist, at least in certain situations. > The Microsoft programmers are not dumb. They certainly are not cheap. > And yet here we have one guy who can write code that is 10-100x faster, in just few days. I think it's a difference between incentives too. Microsoft programmers are not here to optimize for performance, but to push features, performance being one of them in some cases. For example, the research in file explorer is still painfully slow, probably because they have some other things to do. Many people could make it faster in a few days I guess. But these people aren't inside Microsoft being pressured to do other things. Software made to demonstrate how fast something can be is made in a very different environement and with very different incentives compared to almost all comercial software. For pretty much anything out there, someone can take it, isolate it and make it run 10-100x times faster I think. The thing is, in most organizations you don't have that kind of time.
- Attummm 5y ago
  Looks like you dont now the full story behind it. But there is quite a back story to this. The guy in video called what your doing now "the excuse parade". Instead of finding solutions, your time and energy goes into making excuses. Watch the full video.
  - Zababa 5y ago
    > The guy in video called what your doing now "the excuse parade". > Instead of finding solutions, your time and energy goes into making excuses. Excuses for what exactly? I don't remember writing that code. I'm explaining incentives that leads to slow code. I usually try to write the best code I can in the time I have, but if one day the problem is that my code is too slow, I won't be making excuses. I chose at the time to not spend very much time on performance to ship faster, and that was a conscious choice on my part.
    - ratww 5y ago
      The "excuse parade" mentioned by the grandparent poster is another name for what psychology calls "rationalisation". Microsoft fucked up about performance, period. The reason for that is not because the Terminal provided too many features, or because they wanted the code to be "readable". The manager didn't even claim the team didn't have time to do it, he flat out said it would be impossible without taking a few years to research. Time and time again we see this kinda thing happening in software and people jump into made-up rationalisations because they're in denial about the root cause of issues.
      - Zababa 5y ago
        I think there's a difference between most software being slow because it's not a priority, and some specific parts like that terminal being slow because people have absolutely no clue and are in denial.
        ratww 5y ago
        But the fact that higher performance is not a priority is something that is held together by those excuses and rationalisations. People complain about performance all the time, both users and people inside their teams, but the thinking you're espousing is so widespread that developers clamouring for optimisations are just shut down. End-users not having to wait 5 or 10 seconds unnecessarily can be a boon in productivity in some industries that use Enterprise Software. But we can't rely on having Casey Muratori going to a supermarket whose POS is slow and rewriting the software on a weekend and publicly shaming the supermarket chain on Twitter. Change has to come from within. Even accepting reports that the software is slow would be a good start. The problem is not that the inefficiency exists or that they can take too long to fix. The problem is that no team ever really cares to stop and say "ok is this inefficient, how long will it take to optimise? Will we get gains from that?". Instead of asking and researching, people just do as you do: they rationalise by saying "I can't prove that it can't be faster and I can't prove that it's not costing us or our users money, but it is my belief and no proof will make me change it". This is a industry wide problem. It's anti-scientific posturing that's leading to widespread software slowness, programmed obsolescence and excessive spending of hardware.
- kjksf 5y ago
  It's funny because Casey made this video partly to push back on people like you who come up with limitless excuses for why slow code is "actually the right way to do it". I guess it didn't work. Are you really arguing that the code is 10-100x slower because it was written by 2 people and not one? And if the reason we write slow code is to save programmer time, as your other argument goes, why is it ok to put 2 people to write code that can be written by 1 guy? That excuse doesn't make it better, it just makes it look doubly bad for Microsoft. Not only they can't write fast code, they spend twice as much time doing so!
  - Zababa 5y ago
    > It's funny because Casey made this video partly to push back on people like you who come up with limitless excuses for why slow code is "actually the right way to do it". I'm not saying it's "actually the right way to do it", I'm saying that it's how it's done in real life. That kind of argument reminds me a lot of Robert Martin that is always saying that the fix to software is to have everyone be more disciplined. It's true but it's also absolutely useless. It's like saying "people should be less mean to each other". Yes, they should, we've been saying that for thousands of years. Does that come with anything? A new tool to show how fast your code can be? It's nice to show to people how fast the code can go, especially since the students didn't seem to think that it was possible. But then what? > And if the reason we write slow code is to save programmer time, as your other argument goes, why is it ok to put 2 people to write code that can be written by 1 guy? You measure time in man hours, not just in men.
- ratww 5y ago
  > It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part. But, AFAIK, the new Terminal was new. Sure, it's 3 years old already, but Microsoft still didn't have the hypothetical "this is part of an old system" constraint when they started writing it. > Microsoft programmers are not here to optimize for performance, but to push features, performance being one of them in some cases Microsoft's marketing copy for the new Terminal cites "fast, efficient" in the first paragraph. It also cites GPU optimisation. Clearly performance was a goal. Also, as been discussed ad-nauseam in other HN threads, Casey also added some extra features that didn't exist in MS's New Terminal. The "busy doing features" excuse also doesn't apply.

by kjksf 5y ago

Zababa 5y ago

I don't think that's exactly true. It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part. > The 100x slower renderer was also written by one person (or at most few). The difference between one person and a few is massive in my experience. > It really is the difference between programmers. > It's also a good example that 10x programmers do exist, at least in certain situations. > The Microsoft programmers are not dumb. They certainly are not cheap. > And yet here we have one guy who can write code that is 10-100x faster, in just few days. I think it's a difference between incentives too. Microsoft programmers are not here to optimize for performance, but to push features, performance being one of them in some cases. For example, the research in file explorer is still painfully slow, probably because they have some other things to do. Many people could make it faster in a few days I guess. But these people aren't inside Microsoft being pressured to do other things. Software made to demonstrate how fast something can be is made in a very different environement and with very different incentives compared to almost all comercial software. For pretty much anything out there, someone can take it, isolate it and make it run 10-100x times faster I think. The thing is, in most organizations you don't have that kind of time.

Attummm 5y ago
Looks like you dont now the full story behind it. But there is quite a back story to this. The guy in video called what your doing now "the excuse parade". Instead of finding solutions, your time and energy goes into making excuses. Watch the full video.
- Zababa 5y ago
  > The guy in video called what your doing now "the excuse parade". > Instead of finding solutions, your time and energy goes into making excuses. Excuses for what exactly? I don't remember writing that code. I'm explaining incentives that leads to slow code. I usually try to write the best code I can in the time I have, but if one day the problem is that my code is too slow, I won't be making excuses. I chose at the time to not spend very much time on performance to ship faster, and that was a conscious choice on my part.
  - ratww 5y ago
    The "excuse parade" mentioned by the grandparent poster is another name for what psychology calls "rationalisation". Microsoft fucked up about performance, period. The reason for that is not because the Terminal provided too many features, or because they wanted the code to be "readable". The manager didn't even claim the team didn't have time to do it, he flat out said it would be impossible without taking a few years to research. Time and time again we see this kinda thing happening in software and people jump into made-up rationalisations because they're in denial about the root cause of issues.
    - Zababa 5y ago
      I think there's a difference between most software being slow because it's not a priority, and some specific parts like that terminal being slow because people have absolutely no clue and are in denial.
      - ratww 5y ago
        But the fact that higher performance is not a priority is something that is held together by those excuses and rationalisations. People complain about performance all the time, both users and people inside their teams, but the thinking you're espousing is so widespread that developers clamouring for optimisations are just shut down. End-users not having to wait 5 or 10 seconds unnecessarily can be a boon in productivity in some industries that use Enterprise Software. But we can't rely on having Casey Muratori going to a supermarket whose POS is slow and rewriting the software on a weekend and publicly shaming the supermarket chain on Twitter. Change has to come from within. Even accepting reports that the software is slow would be a good start. The problem is not that the inefficiency exists or that they can take too long to fix. The problem is that no team ever really cares to stop and say "ok is this inefficient, how long will it take to optimise? Will we get gains from that?". Instead of asking and researching, people just do as you do: they rationalise by saying "I can't prove that it can't be faster and I can't prove that it's not costing us or our users money, but it is my belief and no proof will make me change it". This is a industry wide problem. It's anti-scientific posturing that's leading to widespread software slowness, programmed obsolescence and excessive spending of hardware.
kjksf 5y ago
It's funny because Casey made this video partly to push back on people like you who come up with limitless excuses for why slow code is "actually the right way to do it". I guess it didn't work. Are you really arguing that the code is 10-100x slower because it was written by 2 people and not one? And if the reason we write slow code is to save programmer time, as your other argument goes, why is it ok to put 2 people to write code that can be written by 1 guy? That excuse doesn't make it better, it just makes it look doubly bad for Microsoft. Not only they can't write fast code, they spend twice as much time doing so!
- Zababa 5y ago
  > It's funny because Casey made this video partly to push back on people like you who come up with limitless excuses for why slow code is "actually the right way to do it". I'm not saying it's "actually the right way to do it", I'm saying that it's how it's done in real life. That kind of argument reminds me a lot of Robert Martin that is always saying that the fix to software is to have everyone be more disciplined. It's true but it's also absolutely useless. It's like saying "people should be less mean to each other". Yes, they should, we've been saying that for thousands of years. Does that come with anything? A new tool to show how fast your code can be? It's nice to show to people how fast the code can go, especially since the students didn't seem to think that it was possible. But then what? > And if the reason we write slow code is to save programmer time, as your other argument goes, why is it ok to put 2 people to write code that can be written by 1 guy? You measure time in man hours, not just in men.
ratww 5y ago
> It's not the same thing to write a piece of code as part of a whole system, vs rewriting that piece of code as an isolated part. But, AFAIK, the new Terminal was new. Sure, it's 3 years old already, but Microsoft still didn't have the hypothetical "this is part of an old system" constraint when they started writing it. > Microsoft programmers are not here to optimize for performance, but to push features, performance being one of them in some cases Microsoft's marketing copy for the new Terminal cites "fast, efficient" in the first paragraph. It also cites GPU optimisation. Clearly performance was a goal. Also, as been discussed ad-nauseam in other HN threads, Casey also added some extra features that didn't exist in MS's New Terminal. The "busy doing features" excuse also doesn't apply.