A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.
I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases. You shouldn't automatically assume something is actually bad just because someone shows a better proof-of-concept 'alternative'. They may have just ignored half the stuff it needs to do.
This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all.
The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
[1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.
That sounds like you've never seen performance of a heavily worked-on subsystem increase by 10x because one guy who was good at that kind of stuff spent a day or two focused on the problem.
I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimized codebases, most teams either a) just don't have the right people to find them, or b) have too much other shit that's on fire to let anyone except a newbie look at stuff like performance.
I don't know about you, but I was really laughing out loud reading that GitHub conversation.
GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time
MS engineers: drawing colored text is SLOW, what do you expect
P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can render huge files with real-time syntax highlighting, browsers that can quickly layout much more complex text, and, obviously Linux and Mac terminal emulators that somehow have no issue whatsoever rendering large amount of colored text.
I understand the scepticism about such claims, but Casey's renderer is not a toy, and handles a number of quite dificult test-cases correctly. He solicited feedback from a sizeable community to try and break his implementation. The code is vailable here: https://github.com/cmuratori/refterm
refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports:
* Multicolor fonts
* All of Unicode, including combining characters and right-to-left text like Arabic
Glyphs that can take up several cells
* Line wrapping
* Reflowing line wrapping on terminal resize
* Large scrollback buffer
* VT codes for setting colors and cursor positions, as well as strikethrough, underline, blink, reverse video, etc.
Reading the thread itself, it’s a bit of both. Windows Terminal is complex, ClearType is complex and Unicode rendering is complex. That said… https://github.com/cmuratori/refterm does exist, does not support ClearType, but does claim to fully support Unicode. Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 and (b) it sounds like the Windows Terminal project is indeed a bit more complicated than can be hacked on over a weekend and would need extensive refactoring to support the approach. So it sounds a bit more like a brownfield problem than simply ignoring half the things it needs to do, though it probably does that too.
It's the hardest thing about building perf-related PoCs. Every time I've built a prototype to prove out an optimization, I've spent the entire duration of the project watching the benefit shrink, stressing that it would dwindle to nothing by the end. So far, I've been lucky and careful enough that I haven't convinced a team to expend massive resources on a benefit that turned out to be fictional, but I've had it happen enough times at the scale of a p-day or two that it always worries me.
...So none of these typical hand-wavy dismissals apply:
1. "Is it really faster for edge cases"
2. "He probably didn't implement certain features like Arabic and Chinese"
3. "Businesses just wants enough"
4. "Businesses just wants enough"
5. "It probably makes some closed-world assumption"
The performance of RefTerm didn't come from some big tradeoff; it came from using the right perspective and keeping things simple.
Sure, past a certain complexity threshold, you'd have to work for extra perf, but from my observations, folks who immediately jump to the wrong implicit conclusion that "good perf must have required compromises" got conditioned to think this way because the software they work on are already (often unnecessarily) complex.
Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.
I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.
This definitely resonates. I've often talked about how the key transition to 'lead engineer' is when you learn how to wield a team of programmers to solve a technical problem, instead of solving it yourself, and to higher levels it's when you learn how to wield an entire organization to some technical purpose.
These ARE much clunkier tools than a compiler.
Another way I've expressed it is how the tool you use to get started on implementing a change shifts as you grow more senior (if you'll forgive an IDE-centric kind of view - this is meant to reflect life in a Big Org - feel free to substitute with appropriate emacs commands)
- Junior Dev: File > Open
- Dev: File > New
- Senior Dev: File > New Project
- Lead Dev: File > New Diagram
- Principal Dev: File > New Powerpoint Presentation
There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming is concerned but there's also a space for more junior programmers to learn and grow without trashing the whole project in the process. The Godot engine seems to be turning into this sort of sweet spot model with its tech lead. However in a company this seems like an unstable situation, since I've seen such leads advance another step and now the only thing they "architect" is business strategy via all-day meetings, like any other executive, and the last time they coded anything was years ago. You might get them on a rare code review but they've become so far removed from the details they're not as helpful as they used to be, which in turn leads to not including them anymore. This distance hurts again because now that they have at least some influence (not as much as the 'equivalent' managerial track position, 'mysteriously') to address long-standing dev pains they are too far removed from the pain to spend their limited influence fighting it.
My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?
There is that joke about the University Professors talking about the best high level language, throwing out various languages until one just replied with "Grad Student".
It does make a lot of sense, you describe the problem in a very high level and abstract way and at the end of the process you get an executable out of it.
But yeah, as you go up the ladder, even the technical one, you end up needing people skills more and more than any technical or programming skill. Usually by senior level you're the best that you'll ever be at technical topics (hand wavy description here, don't nitpick), and the only way to progress up is to improve communication. No amount of extra technical knowledge will help you if you cannot communicate well.
Juniors are beginners, learners, apprentices, and are bound to make mistakes and design things poorly. The issue is there are so few high-quality engineers relative to the demand, and it's hard to prove who is high-quality before they're onboard for a few months. So, if someone is high-quality, you really don't want to lose them, so you promote them, pay them more, try your best to keep them on-board. There's a benefit to elevating them out of the weeds, because often they can glance at the weeds and tell someone else how to clean it up easily, without spending their effort to actually do it.
Furthermore, they can glance at 10 patches of weeds, 10 junior engineers, and find the couple that need more guidance than the others. They can leverage their knowledge through others, assessing their strengths/weaknesses as coders in ways juniors never could.
It seems like companies are creating independent contributor tracks to remedy this issue. You can have people who are legendary programmers float around and contribute where they wish.
This is well-said and resonates with me quite a bit. How do we build expertise in an engineering organization where the best engineers are incentivized not to engineer?
I really appreciate this perspective. Better tooling to enable individuals to penetrate more layers of abstraction sound great. To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.
However, I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.
This reflects a lot of what goes on in Academia as well.
Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career.
"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch. Cue exploitation of interns and other newcomers and you almost have the whole picture on how things get actually done. Hence why "science advances one funeral at a time". Once someone reaches its own Peter level [1], it stops being a productive force and becomes a plug that jams everything behind it.
This is both annoying and understandable. For the dev team, to dive into this performance optimization would mean punting something else from their roadmap. I suspect they weighed their perceived chances of success against the projected cost and reached a certain conclusion which in retrospect seems wrong. The independent developer did not have that "hurdle" as he simply did this at the expense of whatever other fun programming challenges he may have done those weekends. It's awesome that he turned out to be right. But I suspect if he turned out wrong we'd never hear about it. There was likely no tradeoff analysis on his part in undertaking this project, while the dev team did have to do one.
On the flip side, I have seen developers get really hung up on what is academically difficult rather than what is practically doable. I had a young developer who worked for me get really upset and hung up on the fact that something he was asked to do was NP equivalent, meaning there's no non-exponential time algorithm to implement what I was asking for. It took me weeks to realize this was messing with him and then about 5 mins to dig into the data and show that input length never practically exceeds like 7, so an exponential algorithm was fine. So I can see how a dev could get stuck thinking something is really hard when it really isn't. But I don't think it makes them a bad dev, it's just hard to transcend your own perspective.
I'm not sure "It doesn't take a PhD, just years of experience" is quite the rejoinder the author thinks it is.
Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?
The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."
That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.
So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.
It IS a good argument for why MS should accept open source contributions, though.
It's not really what the MS devs said though: "I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation"
This seems to mean, nobody has ever done that, it is a research project (a doctorate thesis must be about something that has never been researched before, at least where I live).
This particular problem cannot be a PhD subject, because it has already been researched, solved and done multiple times, by different persons and on different projects.
Someone can use the knowledge already widely available on the internet to grasp what the issue is, and implement a solution in their own project.
Years of experience aren't a PhD. Years of experience can help you understand a thesis, but only if the research doesn't exist yet, can it be considered a doctoral research project.
I think the other piece the comment and the rejoinder miss is is: A PhD generally means you've done four years of work post bachelors, and some of that work was novel.
A PhD alone does not make someone an expert in most modern senses in software. The folks the author describes as "experienced" often have more than a decade of working software knowledge from after their education.
Casey Muratori has 30 years of programming experience. That's not a PhD, that's a PhD and then an additional 20+ years of experience.
2. Since this whole affair, the developers have apologized and corrected themselves which is usually unacknowledged in these discussions.
3. The developers have made a number of performance improvements since (most of which are in the latest preview release).
4. This episode is constantly retold and used to bully the developers even after these apologies and this has lead to one of the developers to quit (paradoxically one of the devs who after these posts made the most effort to figure out where the bottlenecks are).
If that's the case, they should really link those developments/retractions/apologies in the comments of that issue. The way the comments end in that issue is a really bad look, and there's no hint to the reader that there was any further developments, either in the code or the dev team.
It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
Leadership is a lot more than about "shuffling paper" in an "ivory tower".
As a lead (in any decent company), you get to participate in critical design reviews; you get to read and review code; you get to shape the trajectory of others; you get to participate in discussions with the product teams. If you work smart, you get free time that you can use to keep coding. All of this can be extremely rewarding.
You are not serving our domain by painting this kind of picture of leadership. The truth is, you can excel as a software engineer, but you can also excel as a lead. And none is better than the other.
I dedicate this message to the "wet behind the ears" people you are referring to who would never consider the role if they were to stick to this poor vision you're delivering.
I agree with you, but few companies know how to appreciate those who decided to progress in the technical excellence. In most not taking a "leadership" (aka management) position means your career reaches a dead end.
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
I think you misread the post.
I don't see where this is criticizing the role of leadership. Good leaders exists (though, they are rare). I have been led by some of those inspiring people. But I've never met a leader (as good as it was) who continued to be a great software engineer.
The point is that they all were stuck in the "Sort of knows what they are doing" zone. And that's ok for being a great leader. But then, nobody in the company is kept long enough at a position to become what the author describe as "Experienced".h
> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way.
It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job.
In a 14 year career, I have had "leadership" that is not completely horrible for about 6 months, but that I still would not call good, at best it is mediocre. If only most "leaders" were wet behind the ears instead of bordering on grossly incompetent.
If people's experience of leadership is that it is almost always dead-weight, then the problem is that it is almost always dead-weight, not that people call it out for being almost always dead-weight.
And by the way, I have never met one person who thought they were a good leader that was even slightly so. People who think they are good leaders are almost invariably pompous, arrogant and ignorant.
If you read the article, the author is discussing a conversation on Github and developer experience. The article isn't an indictment about academia (it doesn't even really come up at all).
Re the author's competence argument, given how complex software development is as a field, a better approach should be to always assume that there's a person out there who can solve a problem quicker and more competently than your guesstimate. Of course, you should also assume that they're not going to, and that you - with all of your issues, lack of experience, and general :/ 'iness - is the one who's either going to have to fix it or find someone who can.
The worst part is that the kind of arguments he was met with is exactly the kind of arguments people use to get headcount and climb the ladder within corporations.
Spending a little time writing a well designed and fully working solution => Good job, now take the next ticket!
Spending a lot of time explaining why something can't be done with this budget => Promoted to manager!
Spending a year of time explaining why the project need a much bigger budget to deliver features => Promoted to director!
This is neither the problem nor what the article is talking about. Your argument is so overgeneralized that i don't even know where to start taking it apart.
I understand that different people have different skill sets, that's totally fine. I don't think every single senior developer at Microsoft should have the skillset to fix performance issues like this. That said, however, I do think developers should be able to recognize when a task requires a skill that they do not have. In those cases it's best to reach out to someone within the organization who has that skill. Or, you know, you can be a senior developer at Microsoft and condescendingly claim that it's impossible, or "takes a PhD to develop that". I guess this is what you get when you fill organizations with people who don't care about performance, computer science or algorithms.
I'm going to use this case as another example to point to when people argue that algorithm skills are useless and shouldn't be used when interviewing.
I feel this is missing the elephant in the room, which is that experts are not interchangeable. They have typically specialized in whatever they have spent lots on time doing, and so developers in different sectors develop a lot of different skills that are typically not very useful for developers in different sectors.
A result from that is that what may be trivial for people in one sector is hard for people in a different sector, and vice versa. Often people will not know enough about sectors different from the one they operate in to know what is hard or not in other sectors.
Counter argument: If the experienced programmers stay where they are, software development will forever remain craftsmanship. A single developer can only tutor so many juniors.
In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got released.
SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable. You're not a bad engineer because you never touched the latest hypetech or programming language. You are a bad engineer if you only consider yourself a "frontend developer with react on chrome".
> SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable.
Software engineering can never be anything but an art form!
A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone else wrote--cutting up vegetables, operating the stove, and so on--without making culinary decisions of their own. Experienced chefs, though, come up with ideas for things to cook, which you can't effectively do just by following some procedure. You need to have some creative je-ne-sais-quoi.
In software engineering, we have no long-term need for the first category of people. Any programming task that doesn't require human creativity can be automated. (When's the last time you decided which CPU registers corresponded to which variable names in your program?) An effective programmer uses abstraction for precisely this purpose. They spend all day, every day on making the hard decisions, and they let the computer handle the rest.
This is why Enterprise Software Architecture techniques have always been and will always be doomed to fail. You can't have senior engineers come up with rules that junior engineers can just mechanically follow to write good code. If you could, you wouldn't need the junior engineers, since you could just tell a compiler or code generator or something to follow the rules instead. Everyone who works on a codebase needs to be capable of making good decisions about code, in a way you can't boil down to science and checklists, or the best they can ever do is waste their own time producing repetitive boilerplate.
Good software development can't be anything but craftsmanship, or art if you think of "art" as in "artisan".
Think of what a developer is, and what a computer is. A computer is a dumb machine, it lacks creativity, it is only good at executing orders, but that, it does it very well, and very fast. A programmer is a human, creative and able to see the big picture, his task is to inject his human qualities into the dumb machine, so that the machine can do things that are useful for humans.
So, programming is the opposite of applying recipes, if there is a well defined recipe, that's for the machine, not for the human. If programming is not an at least a little bit of an art form, it means the programmer is doing the job of the computer, which is a waste of valuable human time on something the machine can do better.
I'm somewhere in the middle. I see software development as an art form, however it's not disconnected from its solid scientific roots.
Sometimes, the art part is for fun (i.e.: your weekend project), sometimes it's for pushing systems to the limit (i.e.: scientific programming, demoscene, or where performance is really needed).
In my case, the art is exploiting the hardware or the theory in a way that it works smoothly and very performant for the cases you have.
This doesn't mean the deadlines doesn't matter, and explicit, slow, but very robust code doesn't have its place. On the contrary, it has many places. We need to make the correct trade-offs to get our job done the best way possible.
On the mentoring side, training people is hard, because of both parties. Low ego, open mindedness and being open to being wrong is very important. I try to mentor some people around me, and I encourage them to go further than I did. Lastly, I find passing the "old way" to new generations very valuable. While these old ways are inevitably lower level and less hip, they're tried, stood the test of the time, and generally performant enough (or very performant in some cases).
Just a side note, your idea of art is a bit naive. Take for example the work done by Christo and Jeanne-Claude, citing wikipedia:
> Their work was typically large, visually impressive, and controversial, often taking years and sometimes decades of careful preparation – including technical solutions, political negotiation, permitting and environmental approval, hearings and public persuasion.
I pity the developer (or maybe manager) at Microsoft who wrote the GitHub comment on which this article's title is based. (And no, I never met him when I was at Microsoft.) If he's in the Seattle area, he's likely not even awake yet, but when he is, I expect he's going to have a bad day. Assuming he's not already sick of the Windows Terminal versus refterm drama, it would be interesting to read his perspective.
The very ticket [1] is locked by this epic ending:
> You were overly confident in your opinion, but I hope this website helps you understand that it's actually really damn hard.
> The reason your program shows a high FPS under other terminal emulators is simply, because their rendering pipeline works independent of VT ingestion. Gnome Terminal is not laying out text faster than your display refresh rate either. And of course, again, this is something WT will probably do as well in the future... but this project is nowhere near as old as Gnome Terminal is.
The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions.
The tone gets quite condescending towards him.
He gets out of all this with flying colours. He should consider adding that Github issue to his resume.
He is already well-known enough in his field past the point of writing a resume, and I don't think he really would want to enter the corporate IT world that he intensely despises (even with lots of cash). Plus he's already busy on his own working on various projects: the video game 1935 (which we don't really know that much of), Star Code Galaxy (a CS course focusing on fundamentals), and Handmade Hero (A live recording / tutorial of making a game from scratch). He's already really
Yeah, typical Microsoft developers (https://github.com/microsoft/terminal/issues/10362). That issue was pretty mild, they felt threatened and used CoC principles ("combative") to shut down the threat.
This is how they also ruin "open" source projects like Python now.
> I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively…
Yes, it might be seen as combative since it amounts to saying "you guys seem to be clueless". When proven in experiments, it means that the combativeness was justified.
Imo, the language in this quote is almost unacceptable. It's a roundabout way of saying "stand back little peon, you are not important enough to be thinking about problems that concern us."
It's inevitable that when people overestimate their competence and judgement, the moment when humility is forced on them is experienced as painful. Adjust prejudices and move on.
Saying that is is a multiyear long undertaking was probably a little silly and makes it sound like the person who said that can't have been involved wi4th the software otherwise they would have known this but there might also be another explanation that we have seen, particularly with Microsoft:
You can't sell the things that make people just like the software, only new headline features do that.
Example 1: When you open visual studio 2019, you get a search box by default that allows you to type in your project name and it looks for it in the MRU list. Except this is intolerably slow! I suspect it might not be the searching itself, perhaps a tonne of threads are doing something but it is terrible. ANY search algorithm looking through a list of no more than 50 things should be instance, theirs takes up to around 10 seconds and does fuzzy search by default! Why don't they fix it? They wouldn't sell any more units by fixing it and you won't upgrade to the newer improved version.
Example 2: When you install nuget packages in visual studio on netfx projects, it modifies the assembly redirects in web.config by re-writing the entire file even if there are no changes. Oh, and it adds extra spaces and stuff so that the diff tools think every single line has changed. I have to manually delete all of the entries, build it again, let visual studio warn me about missing redirects, double-click the warning and VS writes the file in the original style revealing the maybe 2 actual changes. This is total horsesh*t but they won't fix it. Why? You should be using dotnet core, even if your project is 5 years old and established.
It's a shame because there are lots of things to like about MS tooling compared to lots of competitors but each of these things will be a coffin nail that eventually will cause people to jump ship.
The difference here is that the developer of RefTerm is an experienced, professional developer passionate about his craft and building good software. Microsoft is a faceless entity composed of people who mostly don't care about what they do during the day and are just getting by so they can get paid. There's no shame in that. But there is shame in patronising someone when they demonstrate something to be false and locking the thread on GitHub such that no further discussion is possible...
Microsoft is sluggish and delivers products that do the job and nothing more. Sadly, that's the modus operandi of most software companies. That's why nimble little startups are still managing to steal pieces of various markets.
I use Windows Terminal quite often and have definitely noticed its terrible performance. So this is definitely something visible in the real world and not just nitpicking.
inexperienced developers are unable - or just rarely - ask themselves the question:
"is the current performance in the right ballpark of where it should be?"
here it's obvious - muratori took one look at that thing and just knew that "no, 2-3 fps is definitely, completely off". i, too, had a couple of those moments where i got my hands on some code and thought: "that just can't be right" and then found O² algorithms, byte-by-byte io copy routines, database abuse or duplicated work.
if you don't have the rough reference points of what should be right, you often just don't question correctly working code.
[+] [-] onion2k|4 years ago|reply
I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove' that it can be faster by making a proof-of-concept the only reason theirs is faster is because it doesn't implement the important-but-slow bits and it ignores most of the edge cases. You shouldn't automatically assume something is actually bad just because someone shows a better proof-of-concept 'alternative'. They may have just ignored half the stuff it needs to do.
[+] [-] jiggawatts|4 years ago|reply
The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal!
RefTerm 2 vs Windows Terminal in action: https://www.youtube.com/watch?v=99dKzubvpKE
Refterm 2 source: https://github.com/cmuratori/refterm
One of the previous discussions: https://news.ycombinator.com/item?id=27775268
[1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.
[+] [-] cornel_io|4 years ago|reply
I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimized codebases, most teams either a) just don't have the right people to find them, or b) have too much other shit that's on fire to let anyone except a newbie look at stuff like performance.
[+] [-] ribit|4 years ago|reply
GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time
MS engineers: drawing colored text is SLOW, what do you expect
P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can render huge files with real-time syntax highlighting, browsers that can quickly layout much more complex text, and, obviously Linux and Mac terminal emulators that somehow have no issue whatsoever rendering large amount of colored text.
[+] [-] macmac|4 years ago|reply
[+] [-] Hendrikto|4 years ago|reply
refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports:
* Multicolor fonts
* All of Unicode, including combining characters and right-to-left text like Arabic Glyphs that can take up several cells
* Line wrapping
* Reflowing line wrapping on terminal resize
* Large scrollback buffer
* VT codes for setting colors and cursor positions, as well as strikethrough, underline, blink, reverse video, etc.
[+] [-] lstamour|4 years ago|reply
[+] [-] mistercow|4 years ago|reply
[+] [-] chenglou|4 years ago|reply
1. Faster in every case tested
2. More fully-featured, including i18n
3. Easier to read and maintain (see for yourself)
4. Shorter
5. Using existing libs, aka interops well
...So none of these typical hand-wavy dismissals apply:
1. "Is it really faster for edge cases"
2. "He probably didn't implement certain features like Arabic and Chinese"
3. "Businesses just wants enough"
4. "Businesses just wants enough"
5. "It probably makes some closed-world assumption"
The performance of RefTerm didn't come from some big tradeoff; it came from using the right perspective and keeping things simple.
Sure, past a certain complexity threshold, you'd have to work for extra perf, but from my observations, folks who immediately jump to the wrong implicit conclusion that "good perf must have required compromises" got conditioned to think this way because the software they work on are already (often unnecessarily) complex.
[+] [-] TeMPOraL|4 years ago|reply
I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.
--
[0] - https://news.ycombinator.com/item?id=27417462
[1] - https://news.ycombinator.com/item?id=28568053
[+] [-] jameshart|4 years ago|reply
These ARE much clunkier tools than a compiler.
Another way I've expressed it is how the tool you use to get started on implementing a change shifts as you grow more senior (if you'll forgive an IDE-centric kind of view - this is meant to reflect life in a Big Org - feel free to substitute with appropriate emacs commands)
- Junior Dev: File > Open
- Dev: File > New
- Senior Dev: File > New Project
- Lead Dev: File > New Diagram
- Principal Dev: File > New Powerpoint Presentation
- Staff Dev: File > New Recurring Meeting Request
[+] [-] Jach|4 years ago|reply
My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?
[+] [-] daemin|4 years ago|reply
It does make a lot of sense, you describe the problem in a very high level and abstract way and at the end of the process you get an executable out of it.
But yeah, as you go up the ladder, even the technical one, you end up needing people skills more and more than any technical or programming skill. Usually by senior level you're the best that you'll ever be at technical topics (hand wavy description here, don't nitpick), and the only way to progress up is to improve communication. No amount of extra technical knowledge will help you if you cannot communicate well.
[+] [-] WhompingWindows|4 years ago|reply
Furthermore, they can glance at 10 patches of weeds, 10 junior engineers, and find the couple that need more guidance than the others. They can leverage their knowledge through others, assessing their strengths/weaknesses as coders in ways juniors never could.
[+] [-] hardwaregeek|4 years ago|reply
[+] [-] jdauriemma|4 years ago|reply
[+] [-] zurfer|4 years ago|reply
[+] [-] TheCoelacanth|4 years ago|reply
[+] [-] moralestapia|4 years ago|reply
Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career.
"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch. Cue exploitation of interns and other newcomers and you almost have the whole picture on how things get actually done. Hence why "science advances one funeral at a time". Once someone reaches its own Peter level [1], it stops being a productive force and becomes a plug that jams everything behind it.
1: https://en.wikipedia.org/wiki/Peter_principle
[+] [-] xyzelement|4 years ago|reply
On the flip side, I have seen developers get really hung up on what is academically difficult rather than what is practically doable. I had a young developer who worked for me get really upset and hung up on the fact that something he was asked to do was NP equivalent, meaning there's no non-exponential time algorithm to implement what I was asking for. It took me weeks to realize this was messing with him and then about 5 mins to dig into the data and show that input length never practically exceeds like 7, so an exponential algorithm was fine. So I can see how a dev could get stuck thinking something is really hard when it really isn't. But I don't think it makes them a bad dev, it's just hard to transcend your own perspective.
[+] [-] jameshart|4 years ago|reply
Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?
The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."
That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.
So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.
It IS a good argument for why MS should accept open source contributions, though.
[0] https://caseymuratori.com/blog_0001
[+] [-] reyqn|4 years ago|reply
This seems to mean, nobody has ever done that, it is a research project (a doctorate thesis must be about something that has never been researched before, at least where I live).
This particular problem cannot be a PhD subject, because it has already been researched, solved and done multiple times, by different persons and on different projects.
Someone can use the knowledge already widely available on the internet to grasp what the issue is, and implement a solution in their own project.
Years of experience aren't a PhD. Years of experience can help you understand a thesis, but only if the research doesn't exist yet, can it be considered a doctoral research project.
[+] [-] zbobet2012|4 years ago|reply
A PhD alone does not make someone an expert in most modern senses in software. The folks the author describes as "experienced" often have more than a decade of working software knowledge from after their education.
Casey Muratori has 30 years of programming experience. That's not a PhD, that's a PhD and then an additional 20+ years of experience.
[+] [-] jameshart|4 years ago|reply
In fact, consider the hypothetical of: what if Microsoft had hired Casey Muratori.
Do you imagine they’d have put him on the console team?
I mean the Windows console, not the X Box console, or the Minecraft console.
[+] [-] xoac|4 years ago|reply
1. WT is probably my favorite Microsoft product
2. Since this whole affair, the developers have apologized and corrected themselves which is usually unacknowledged in these discussions.
3. The developers have made a number of performance improvements since (most of which are in the latest preview release).
4. This episode is constantly retold and used to bully the developers even after these apologies and this has lead to one of the developers to quit (paradoxically one of the devs who after these posts made the most effort to figure out where the bottlenecks are).
[+] [-] rfrey|4 years ago|reply
[+] [-] oakfr|4 years ago|reply
Leadership is a lot more than about "shuffling paper" in an "ivory tower".
As a lead (in any decent company), you get to participate in critical design reviews; you get to read and review code; you get to shape the trajectory of others; you get to participate in discussions with the product teams. If you work smart, you get free time that you can use to keep coding. All of this can be extremely rewarding.
You are not serving our domain by painting this kind of picture of leadership. The truth is, you can excel as a software engineer, but you can also excel as a lead. And none is better than the other.
I dedicate this message to the "wet behind the ears" people you are referring to who would never consider the role if they were to stick to this poor vision you're delivering.
[+] [-] oytis|4 years ago|reply
I agree with you, but few companies know how to appreciate those who decided to progress in the technical excellence. In most not taking a "leadership" (aka management) position means your career reaches a dead end.
[+] [-] pjerem|4 years ago|reply
I think you misread the post.
I don't see where this is criticizing the role of leadership. Good leaders exists (though, they are rare). I have been led by some of those inspiring people. But I've never met a leader (as good as it was) who continued to be a great software engineer.
The point is that they all were stuck in the "Sort of knows what they are doing" zone. And that's ok for being a great leader. But then, nobody in the company is kept long enough at a position to become what the author describe as "Experienced".h
[+] [-] zohch|4 years ago|reply
It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job.
In a 14 year career, I have had "leadership" that is not completely horrible for about 6 months, but that I still would not call good, at best it is mediocre. If only most "leaders" were wet behind the ears instead of bordering on grossly incompetent.
If people's experience of leadership is that it is almost always dead-weight, then the problem is that it is almost always dead-weight, not that people call it out for being almost always dead-weight.
And by the way, I have never met one person who thought they were a good leader that was even slightly so. People who think they are good leaders are almost invariably pompous, arrogant and ignorant.
[+] [-] zhdc1|4 years ago|reply
Re the author's competence argument, given how complex software development is as a field, a better approach should be to always assume that there's a person out there who can solve a problem quicker and more competently than your guesstimate. Of course, you should also assume that they're not going to, and that you - with all of your issues, lack of experience, and general :/ 'iness - is the one who's either going to have to fix it or find someone who can.
[+] [-] Jensson|4 years ago|reply
Spending a little time writing a well designed and fully working solution => Good job, now take the next ticket!
Spending a lot of time explaining why something can't be done with this budget => Promoted to manager!
Spending a year of time explaining why the project need a much bigger budget to deliver features => Promoted to director!
This is the main problem.
[+] [-] siva7|4 years ago|reply
[+] [-] baobabKoodaa|4 years ago|reply
I'm going to use this case as another example to point to when people argue that algorithm skills are useless and shouldn't be used when interviewing.
[+] [-] jstimpfle|4 years ago|reply
[+] [-] yxhuvud|4 years ago|reply
A result from that is that what may be trivial for people in one sector is hard for people in a different sector, and vice versa. Often people will not know enough about sectors different from the one they operate in to know what is hard or not in other sectors.
[+] [-] choeger|4 years ago|reply
In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got released.
SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable. You're not a bad engineer because you never touched the latest hypetech or programming language. You are a bad engineer if you only consider yourself a "frontend developer with react on chrome".
All IMO, of course.
[+] [-] csande17|4 years ago|reply
Software engineering can never be anything but an art form!
A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone else wrote--cutting up vegetables, operating the stove, and so on--without making culinary decisions of their own. Experienced chefs, though, come up with ideas for things to cook, which you can't effectively do just by following some procedure. You need to have some creative je-ne-sais-quoi.
In software engineering, we have no long-term need for the first category of people. Any programming task that doesn't require human creativity can be automated. (When's the last time you decided which CPU registers corresponded to which variable names in your program?) An effective programmer uses abstraction for precisely this purpose. They spend all day, every day on making the hard decisions, and they let the computer handle the rest.
This is why Enterprise Software Architecture techniques have always been and will always be doomed to fail. You can't have senior engineers come up with rules that junior engineers can just mechanically follow to write good code. If you could, you wouldn't need the junior engineers, since you could just tell a compiler or code generator or something to follow the rules instead. Everyone who works on a codebase needs to be capable of making good decisions about code, in a way you can't boil down to science and checklists, or the best they can ever do is waste their own time producing repetitive boilerplate.
[+] [-] GuB-42|4 years ago|reply
Think of what a developer is, and what a computer is. A computer is a dumb machine, it lacks creativity, it is only good at executing orders, but that, it does it very well, and very fast. A programmer is a human, creative and able to see the big picture, his task is to inject his human qualities into the dumb machine, so that the machine can do things that are useful for humans.
So, programming is the opposite of applying recipes, if there is a well defined recipe, that's for the machine, not for the human. If programming is not an at least a little bit of an art form, it means the programmer is doing the job of the computer, which is a waste of valuable human time on something the machine can do better.
[+] [-] bayindirh|4 years ago|reply
Sometimes, the art part is for fun (i.e.: your weekend project), sometimes it's for pushing systems to the limit (i.e.: scientific programming, demoscene, or where performance is really needed).
In my case, the art is exploiting the hardware or the theory in a way that it works smoothly and very performant for the cases you have.
This doesn't mean the deadlines doesn't matter, and explicit, slow, but very robust code doesn't have its place. On the contrary, it has many places. We need to make the correct trade-offs to get our job done the best way possible.
On the mentoring side, training people is hard, because of both parties. Low ego, open mindedness and being open to being wrong is very important. I try to mentor some people around me, and I encourage them to go further than I did. Lastly, I find passing the "old way" to new generations very valuable. While these old ways are inevitably lower level and less hip, they're tried, stood the test of the time, and generally performant enough (or very performant in some cases).
[+] [-] cuillevel3|4 years ago|reply
> Their work was typically large, visually impressive, and controversial, often taking years and sometimes decades of careful preparation – including technical solutions, political negotiation, permitting and environmental approval, hearings and public persuasion.
[+] [-] mwcampbell|4 years ago|reply
[+] [-] imcotton|4 years ago|reply
> You were overly confident in your opinion, but I hope this website helps you understand that it's actually really damn hard.
> The reason your program shows a high FPS under other terminal emulators is simply, because their rendering pipeline works independent of VT ingestion. Gnome Terminal is not laying out text faster than your display refresh rate either. And of course, again, this is something WT will probably do as well in the future... but this project is nowhere near as old as Gnome Terminal is.
[1] https://github.com/microsoft/terminal/issues/10362#issuecomm...
[+] [-] mytailorisrich|4 years ago|reply
The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions.
The tone gets quite condescending towards him.
He gets out of all this with flying colours. He should consider adding that Github issue to his resume.
[+] [-] cyber_kinetist|4 years ago|reply
[+] [-] vblap|4 years ago|reply
This is how they also ruin "open" source projects like Python now.
[+] [-] yobbo|4 years ago|reply
Yes, it might be seen as combative since it amounts to saying "you guys seem to be clueless". When proven in experiments, it means that the combativeness was justified.
Imo, the language in this quote is almost unacceptable. It's a roundabout way of saying "stand back little peon, you are not important enough to be thinking about problems that concern us."
It's inevitable that when people overestimate their competence and judgement, the moment when humility is forced on them is experienced as painful. Adjust prejudices and move on.
[+] [-] lbriner|4 years ago|reply
You can't sell the things that make people just like the software, only new headline features do that.
Example 1: When you open visual studio 2019, you get a search box by default that allows you to type in your project name and it looks for it in the MRU list. Except this is intolerably slow! I suspect it might not be the searching itself, perhaps a tonne of threads are doing something but it is terrible. ANY search algorithm looking through a list of no more than 50 things should be instance, theirs takes up to around 10 seconds and does fuzzy search by default! Why don't they fix it? They wouldn't sell any more units by fixing it and you won't upgrade to the newer improved version.
Example 2: When you install nuget packages in visual studio on netfx projects, it modifies the assembly redirects in web.config by re-writing the entire file even if there are no changes. Oh, and it adds extra spaces and stuff so that the diff tools think every single line has changed. I have to manually delete all of the entries, build it again, let visual studio warn me about missing redirects, double-click the warning and VS writes the file in the original style revealing the maybe 2 actual changes. This is total horsesh*t but they won't fix it. Why? You should be using dotnet core, even if your project is 5 years old and established.
It's a shame because there are lots of things to like about MS tooling compared to lots of competitors but each of these things will be a coffin nail that eventually will cause people to jump ship.
[+] [-] c7DJTLrn|4 years ago|reply
Microsoft is sluggish and delivers products that do the job and nothing more. Sadly, that's the modus operandi of most software companies. That's why nimble little startups are still managing to steal pieces of various markets.
I use Windows Terminal quite often and have definitely noticed its terrible performance. So this is definitely something visible in the real world and not just nitpicking.
[+] [-] stefs|4 years ago|reply
"is the current performance in the right ballpark of where it should be?"
here it's obvious - muratori took one look at that thing and just knew that "no, 2-3 fps is definitely, completely off". i, too, had a couple of those moments where i got my hands on some code and thought: "that just can't be right" and then found O² algorithms, byte-by-byte io copy routines, database abuse or duplicated work.
if you don't have the rough reference points of what should be right, you often just don't question correctly working code.