It takes a PhD to develop that • Hacker News Board

Re: It takes a PhD to develop that

#401

Post by lkey » Tue, Oct 05, 2021, 5:18 AM UTC

wtallis wrote: post #399

lkey wrote: post #394

Earlier quoted context omitted.

Taking responsibility (which the developers later did by the way, even in this thread) and enduring abuse (which is also well documented here and elsewhere) should not be put on the same level. More broadly, I'd much rather endure a slightly slow terminal made by developers acting in the open and in (mostly) good faith than the intentionally malicious software produced by actual bad actors within Google, Facebook, Mi…

"Abusive" is probably the the best one-word description of the way Microsoft and its software interacts with users. But I thing we'd agree it's a bit of a stretch to apply that to the case of a slightly slow terminal. However, it is absolutely fair to call it abusive when Microsoft tries to deny their problems or lie to their users that those problems are not Microsoft's fault and are something the users must simply…

The person that quit the project (and possibly the internet at large) wasn't a microsoft employee.

In my mind, there are two asymmetries.

* Microsoft v. Users

and

* Casey's network v. a 3-4 man open source team within microsoft

I don't disagree that the former is abusive.

However, it's my contention that this incident is primarily about the latter.

Casey, rightly, already had some pent up rage about the former asymmetry as well.

But it was a human manager/dev? within that small team, not Microsoft writ large, that got defensive about the software he was responsible for.

I believe I'd feel embarrassed and defensive too if something I'd worked on turned out to be flawed in a painfully obvious way. I can understand avoiding the grim truth by denying that the problem has truly been solved by ~700 lines of C.

Something else that I'll note here is that the vast majority of "Your software is too slow, Here's how to fix it, I could do it in a weekend, and by the way this whole problem space is actually super simple." tickets do not end up realizing software speedups. Without proper context, they just sounds patronizing, making the argument easier to dismiss.

Re: It takes a PhD to develop that

#402

Post by Nevermark » Tue, Oct 05, 2021, 6:27 AM UTC

schlupa wrote: post #168

eloisant wrote: post #46

Earlier quoted context omitted.

More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view. "Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.

There's also sometimes the incentive to slow things down because if it is too fast, the client will perceive that he paid too much money for an operation that takes no time, i.e. it doesn't exists seems unimportant.

It would be a shame for a truly artistically designed busy-wheel if it didn't get turn once or twice, regardless of the time it was actually needed!

Re: It takes a PhD to develop that

#403

Post by ripley12 » Tue, Oct 05, 2021, 6:32 AM UTC

DHowett wrote: post #287

mwcampbell wrote: post #169

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.

As the guy responsible for that comment (and the dev lead for the team! Hi!) I can say it haunts me pretty much weekly. My parenthetical-laden snarky sense of humor, my use of italics to indicate speech-like emphasis and pretty much everything else about that comment has been dissected to parts as small as possible. In the end, though? Yeah, I was completely wrong. I don’t know much about graphics engineering and I’m…

My sympathies to you and the rest of the WT team. I think you’re doing a bang-up job under difficult platform constraints (that most people don’t appreciate), and the amount of vitriol spilled over this one interaction has been really disappointing.

Just remember that there’s a huge number of people who appreciate the work you’re doing to modernize terminal experiences on Windows (nearly 78k GitHub stars!)

Re: It takes a PhD to develop that

#404

Post by maficious » Tue, Oct 05, 2021, 8:15 AM UTC

avereveard wrote: post #333

Jensson wrote: post #313

Earlier quoted context omitted.

That is a terminal bug and not a rendering bug though, since the problem was that the terminal didn't properly fetch your user settings here. Feeding the same character into the other rendering would cause the same issue. Nobody said he made a fully functional better terminal, just that the terminal rendering was better and functional. Doing everything needed for a fully functional terminal is a lot of work, but doin…

> Nobody said he made a fully functional better terminal > 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! easily falsifiable bullshit found to be false. https://news.ycombinator.com/item?id=28744084

I have to say though, the responder to the first comment did a bad job at conveying what exactly refterm is... Apparently people falsely think that refterm is a terminal emulator and use it interchangeably with terminal and terminal renderer, while it isn't.

If you were to open refterm once, you'd see a text that explicitly states "DO NOT USE IT AS A TERMNIAL EMULATOR", or something like that (can't open it now to copy exact).

Re: It takes a PhD to develop that

#405

Post by moritonal » Tue, Oct 05, 2021, 9:25 AM UTC

crispyambulance wrote: post #388

moritonal wrote: post #326

Earlier quoted context omitted.

That exact case seem a very appropriate scenario for clarifying? Microsoft kept saying something was difficult, whilst Casey knew that it was not, so really he was being polite by first confirming that there wasn't something he'd overlooked?

Whether or not you see his behavior as polite, I guess, is a matter of how you read people and the context of the situation. That said, he did literally admit he was being "terse". I think it was counterproductive at best and rather mean at worst. As for whether it really is "difficult", one has to ask for whom? For someone that is intimately familiar with C++, DirectX, internationalization, the nature of production-…

Some people prefer to communicate with less words? This is an issue that crops up often with different cultures working on a single issue.

As for difficult, the context is very much set from it being a Github Issue on their own repo, meaning there is a certain assumption of skill.

You're cutting Microsoft a lot of slack here, and it feels like you're forgetting that out of this whole transaction MS end up with free labour and bug-fixes? They choose for the setting to be very public, and they choose to let their employee's directly reply to customers with quotes like[1]: ["I will take your terse response as accepting the summary.", "somewhat combatively", "peppering your comments with clauses like", "impugning the reader."]. All of which are corporate-passive-aggression and (in my mind) are vastly more antagonistic than Casey ever was?

1. https://github.com/microsoft/terminal/issues/10362

Re: It takes a PhD to develop that

#406

Post by jstimpfle » Tue, Oct 05, 2021, 9:39 AM UTC

baobabKoodaa wrote: post #364

hnfong wrote: post #355

Earlier quoted context omitted.

In practice things are much more nuanced than what you learn in school and textbooks. Sometimes you have a convenient library that sort of does what you want, but it does a lot more. Do you just use it, or do you re-implement only the subset that you need which can be optimized to run much faster? That's not an algorithm question but more of a software engineering tradeoff between impact (how badly your users/busines…

> Algorithm "skills" are probably overrated in the sense that people can memorize textbook algorithms and their analyses all they want ... Memorizing algorithms has very little to do with algorithm skills. You can memorize any algorithm textbook you like, then go take part in an algorithm competition and see how far that will get you (spoiler alert: not far). If you are good at algorithms, you have the ability to con…

> In this case things weren't nuanced and complicated and whatnot justifying a 40x performance drop when rendering colored text. In this case things really were simple: turns out this was just a horribly inefficient solution (like Many products written by Microsoft are).

My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To clarify, in practice, what you use 90% of the time are plain arrays and indices / pointers. Occasionally you'll use a hashmap to lookup (distributed) or cache something.

Performance drops in the real world are most often explained by lack of understanding what certain library calls do, lack of understanding what are their performance characteristics, and/or lack of understanding what needs to be done to satisfy the requirements, or what the requirements should even be.

In most real-world programming domains (probably including the issue discussed here), most problems look somewhat like the following example: Someone reads byte-by-byte from some input stream by calling the read() system call, instead of using a buffered variant (like stdio fgetc()). They might not even notice that they are doing this, because the calls are hidden below a library abstraction. Now for each byte read, there are ball-park 1000 cycles wasted due to system call overhead and other related performance decreasing effect. So there is an overhead on the order of 1000x maybe. This leads to terrible performance, but it's not related to "algorithms" (asymptotic complexity is not the issue here, we're just pumping data).

Re: It takes a PhD to develop that

#407

Post by Aeolun » Tue, Oct 05, 2021, 9:46 AM UTC

kevingadd wrote: post #280

Aeolun wrote: post #164

Earlier quoted context omitted.

> naturally going to be somewhat slow Naturally slow for a text renderer might mean it renders in 4ms instead of 0.1.

Yes, and for a terminal like discussed in the article, 4ms is considered unacceptably slow

I dunno what framerate you expect your terminal to run at, but 250hz should be enough for everyone.

Re: It takes a PhD to develop that

#408

Post by Hendrikto » Tue, Oct 05, 2021, 10:19 AM UTC

zacmps wrote: post #379

Hendrikto wrote: post #108

Earlier quoted context omitted.

From the refterm README: 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…

The really hard part of writing a terminal emulator, at least from my experience working on Alacritty, is fast scrolling with fixed regions (think vim). Plently of other parts of terminal emulators are tricky to implement performantly, ligatures are one Alacritty hasn't got yet.

Thanks for the insight.

I have never written a terminal enulator, so could you maybe summarize why fast scrolling with fixed regions is so hard to implement?

Re: It takes a PhD to develop that

#409

Post by crispyambulance » Tue, Oct 05, 2021, 10:54 AM UTC

dllthomas wrote: post #400

wtallis wrote: post #373

Earlier quoted context omitted.

If you're going to read emotional content into that "Am I missing something?", I think sarcasm and derision are not the most plausible options. In this case, it seems like incredulity is the more likely and appropriate reaction: because it seemed like the person asking the question was putting a lot more thought and effort into the discussion than the Microsoft developers who were not willing to seriously reconsider…

Oh, I didn't mean that sarcasm and derision is how the Microsoft developers interpreted the phrase. I was speaking to the notion that the question was necessarily innocent and could only be interpreted thusly. I would say that incredulity falls within the range between "completely inoffensive" and "outright hostile", and very much toward the former side of the scale. It can be hard to distinguish from feigned incredu…

"Feigned incredulity" can be every bit as caustic as outright hostility.

It's all a matter of perception and context, of course. And though you say there's only one way to interpret it, even you describe it as a continuum.

Sadly, this is all just a sad missed opportunity.

MS could have been less defensive and more open to possible solutions. The genius programmer could have slowed his roll a bit and could have been more collaborative.

Re: It takes a PhD to develop that

#410

Post by cdogl » Tue, Oct 05, 2021, 2:24 PM UTC

strogonoff wrote: post #61

eloisant wrote: post #46

Earlier quoted context omitted.

More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view. "Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.

There’s a bit of incentive misalignment when commercial software performance is concerned. If we presume customers with tighter budgets tend to be more vocal and require more support, and customers on slower machines are often customers on tighter budgets, the business as a whole might actually not mind those customers leaving as it’d require less support resources spent on customers who are more difficult to upsell…

Though we're now in a situation where lots of software (see: Word and Excel) is painfully slow even on high-end desktop hardware.