Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

261–270 of 429 posts

Re: It takes a PhD to develop that

#261

Earlier quoted context omitted.

Third'ing: the current crop of new developers have no freaking idea how much power they have at their finger tips. Us greybeard old game developers look at today's hardware and literally cream our jeans in comparison to the crap we put up with in the previous decades. People have no idea, playing with their crappy interpenetrated languages, just how much raw power we have if one is willing to learn the low level lang…

I'd say it is almost the other way around. We have so much wonderful CPU power that we can spare some for the amazing flexibility of Python etc. Also it's not that simple. One place I worked at (scientific computation-kind of place), we'd prototype everything in Python, and production would be carefully rewritten C++. Standards were very high for prod, and we struggled to hire "good enough", modern C++, endless debat…

Python has nice optimised libs for that, so it's not completely a surprise for that kind of application.

If you're doing generic symbol shuffling with a bit of math, Python is fast-ish to code and horribly slow to run. You can easily waste a lot of performance - and possibly cash - trying to use it for production.

Whether or not you'll save budget by writing your own optimised fast libs in some other lang is a different issue, and very application dependent.

Re: It takes a PhD to develop that

#262

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…

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.

Re: It takes a PhD to develop that

#263

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…

And to be clear, Microsoft probably has plenty of people capable of writing this kind of code. They just aren’t working on console.

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.

Re: It takes a PhD to develop that

#264

Earlier quoted context omitted.

How is it not applicable when the thing at question is rendering text and rendering is the core of game development? This argument is stupid. Do you have to be a slowpoke to develop commercial apps?

My point is that a UI that meets the needs of as many users as possible, including things like internationalization and accessibility, is much more complex than a typical game UI. That complexity drives developers to use abstractions that often make it much more difficult to optimize. And in the big picture, support for these things that add complexity is often more important than top-speed rendering.

Video games often have an international audience and go to great lengths to support accessibility and multiplatform support, ie. supporting both tablet and desktop. It's laughable how bad many enterprise UIs are that fail to handle different locales, or issues displaying right-to-left text and assuming everyone is using an English speaking standard desktop environment, whereas many indie games manage to handle these things very well.

Re: It takes a PhD to develop that

#265

Earlier quoted context omitted.

doesn't work even with the proper font https://i.imgur.com/WeV8Ror.png

You're not arguing in good faith. Casey threw something together in a matter of days that had 150% of the features of the Windows Terminal renderer , but none of the bug fixing that goes into shipping a production piece of software. That screenshot you keep parading around is a small issue with a quick fix. It's not like Casey's approach is inherently unable to deal with punctuation! You don't discard the entire cont…

In this case, the bug fixing is probably the lion's share of the work though - there's a huge amount of subtle edge cases involved in rendering text, and the Microsoft employees almost certainly know this. And the example that broke it isn't even something particularly obscure. We're literally talking about the output of the dir command, one of the first things someone is likely to do with a terminal window, not displaying correctly. He basically did the easy part of the work and lambasted some Microsoft employees as idiots because they thought it was more complex than that.

Re: It takes a PhD to develop that

#266

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.

yeah, i would be really sad if I was at the receiving end of this.

One guy is not 100% correct one day (because we overworked devs always are?), and the next day someone has written a blog text painting him as a subpar dev and now he is on front page of HN used as an example...

Re: It takes a PhD to develop that

#267
Most of the industry seems structured to keep devs at an intermediate level: resume-driven hiring, ageism, proliferation of open source that prioritizes easy over simple, little discussion of software design, complete lack of education/resources to move devs past that, and incentives that push people into management.

Another thing I realized when writing this: where do experienced devs congregate? (It isn't Twitter.)

Re: It takes a PhD to develop that

#268
post #7

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'…

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] an…

Sometimes you don't know you have a performance problem until you have something to compare it to.

Microsoft's greatest technical own goal of the 2010s was WSL 2.

The original WSL was great in most respects (authentic to how Windows works; just as Windows NT has a "Windows 95" personality, Windows NT can have a "Linux" personality) but had the problem that filesystem access went through the Windows filesystem interface.

The Windows filesystem interface is a lot slower for metadata operations (e.g. small files) than the Linux filesystem interface and is unreformable because the problem is the design of the internal API and the model for security checking.

Nobody really complained that metadata operations in Windows was slow, they just worked around it. Some people though were doing complex build procedures inside WSL (build a Linux Kernel) and it was clear then there was a performance problem relative to Linux.

For whatever reason, Microsoft decided this was unacceptable, so they came out with WSL 2 which got them solidly into Kryptonite territory. They took something which third party vendors could do perfectly well (install Ubuntu in a VM) and screwed it up like only Microsoft can (attempt to install it through the Windows Store, closely couple it to Windows so it almost works, depend on legitimacy based on "it's from Microsoft" as opposed to "it works", ...)

Had Microsoft just accepted that metadata operations were a little bit slow, most WSL users would have accepted it, the ones who couldn't would run Ubuntu in a VM.

Re: It takes a PhD to develop that

#269

Earlier quoted context omitted.

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] an…

What's wrong with the performance? I don't notice any performance issues in Windows terminal.

[deleted]

Re: It takes a PhD to develop that

#270
post #259

Would just like to say that: 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 th…

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.
Post reply on HN