Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

Post reply on HN
Print view View original

271–280 of 429 posts

Re: It takes a PhD to develop that

#271

Post by [deleted] »

dr_hooo wrote: post #131
moralestapia wrote: post #8

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

I would really be surprised if any tenured professor would shut down a solution to a well known hard problem just based on his ego. More likely the solution is not as well presented, researched or thought through as it seems (I'm assuming we're not talking about astrophysics here).

[deleted]

Re: It takes a PhD to develop that

#272

Post by crispyambulance »

Aeolun wrote: post #147
crispyambulance wrote: post #137

Earlier quoted context omitted.

> The "complaining developer" produced a proof of concept in just two weekends... That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side. Instead of both sides asserting (or "proving") that they're "right" could they not have collabo…

> could they not have collaborated to put together an improvement in Windows Terminal? My experience with people that want to collaborate instead of just recognizing and following good advice is that you spend a tremendous amount of effort just to convince them to get their ass moving, then find out they were not capable of solving the problem in the first place, and it’s frankly just not worth it. Much more fun to j…

> Much more fun to just reimplement the thing and then say “You were saying?”

The thing is NO ONE likes to lose face. He could have still done what he did (and enjoy his "victory lap") but in a spirit of collaboration.

To be fair, MS folks set themselves up for this but the smart-alec could have handled it with more class and generosity.

Re: It takes a PhD to develop that

#273

Post by mwcampbell »

c7DJTLrn wrote: post #249

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

> 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.

Regardless of what you think about Microsoft the company, please remember that the individual workers and managers are people who can be hurt by our tendency to form self-righteous mobs. And according to another commenter [1], one of the people working on Windows Terminal was hurt to the point that they quit.

Full disclosure: I'm inclined to defend the Microsoft team here because I was at Microsoft (on the Windows accessibility team) for a while. I don't think that I or my former teammates fit the stereotype you described. And while I never met any of the developers on the Windows Terminal team (at least not knowingly), I could very easily have crossed paths with one of them; I believe my team used to be in the same building as theirs. So I'm inclined to be charitable.

[1]: https://news.ycombinator.com/item?id=28746624

Re: It takes a PhD to develop that

#274

Post by vidarh »

jiggawatts wrote: post #73
ribit wrote: post #58

Earlier quoted context omitted.

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

To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow. That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach. The Windows Terminal is a special case that does…

Exactly. Fast terminal rendering on bitmap displays has been a solved problem for at least 35+ years. Lower resolutions, sure, but also magnitudes slower hardware.

Re: It takes a PhD to develop that

#275

Post by zibzab »

jameshart wrote: post #263
jameshart wrote: post #251

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.

Microsoft has _Micheal Abrash_.

He wrote The Book on rendering performance. Michael's super optimized x86 assembly routines for lighting and texturing is the reason we can run Quake on toasters.

Anyway, I don't think they should hire Casey. Specially after that demonstration of not understanding the big-picture and not being a team player...

Re: It takes a PhD to develop that

#276

Post by mwcampbell »

makomk wrote: post #265
jiggawatts wrote: post #228

Earlier quoted context omitted.

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

In Casey's defense (I'm ambivalent on this one), while the dir command itself isn't obscure, one could argue that using a no-op Unicode character as the digit group separator is an obscure case, at least for an American programmer. But I think your overall point still stands.

Re: It takes a PhD to develop that

#277

Post by smichel17 »

I think a significant contributing factor is that management is a local maximum.

I am a self-identified "sort of knows what they are doing" (albeit, sometimes insecure about that) professional programmer. I've also had the chance to take a leadership position. So, I think I have a useful perspective here.

The amount "I" can accomplish in a leadership position is so much higher than by coding directly. So, on the margins, it's really hard to justify time spent coding, compared to coordinating others. It's incredibly easy to imagine stagnating as a coder due to not doing very much of it. Yet, clearly when everyone follows this route, software quality suffers. I don't have any particular solutions.

Perhaps eventually the rate of expansion of programmers will slow, and we'll end up with too many sort of knows what they're doing" programmers for everyone to move to management, so people/companies will start waiting until programmers hit the experienced mark to make the leap.

Re: It takes a PhD to develop that

#278

Post by incrudible »

ZeroGravitas wrote: post #181
incrudible wrote: post #149

Earlier quoted context omitted.

I just want Microsoft to develop a proper terminal application and not handwave away complaints about performance with "that's a PhD right there". Even if it was a PhD, I'd then expect a PhD to be put to the task, because this is a crucial component of the operating system. Realistically though, a PhD is the opposite of what you want here. A PhD is almost by definition an inexperienced programmer. It's also someone w…

I was more responding to the article, which used that specific example as a jumping off point to talk about management structure in software development generally. I don't use Windows, but I do use Kitty terminal ( https://sw.kovidgoyal.net/kitty/ ) and from my interactions with that project and trying to get code ligatures working in my setup I've learned that terminals are really complex, both for technical and leg…

The ticket discussion brought to light that it is a rendering problem. The other person wrote a terminal renderer that has none of the performance problems and all of the required features. I would say the MS developers have been proven wrong.

Re: It takes a PhD to develop that

#279

Post by fuzzfactor »

jiggawatts wrote: post #73
ribit wrote: post #58

Earlier quoted context omitted.

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

To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow. That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach. The Windows Terminal is a special case that does…

Supercomputer or not, it's a terminal.

In the real-CRT-terminal days of the 1970's & 1980's of course the interface to the local or remote mainframe or PC was IO-bound but not much else could slow it down.

UI elements like the keyboard/screen combo have been expected to perform at the speed of light for decades using only simple hardware to begin with.

The UX of a modern terminal app would best be not much different than a real CRT unit unless the traditional keyboard/display UI could actually be improved in some way.

Even adding a "mouse" didn't slow down the Atari 400 (which was only an 8-bit personal computer) when I programmed it to use the gaming trackball to point & click plus drag & drop. That was using regular Atari Basic, no assembly code. And I'm no software engineer.

A decade later once the mouse had been recognized and brought into the mainstream it didn't seem to slow down DOS at all, compared to a rodent-free environment.

Using modern electronics surely there should not be any perceptable lag compared to non-intelligent CRT's over dial-up.

Unless maybe the engineers are not as advanced as they used to be decades ago.

Or maybe the management/approach is faulty, all it takes is one non-leader in a leadership position to negate the abilities of all talented operators working under that sub-hierarchy.

Re: It takes a PhD to develop that

#280

Post by kevingadd »

Aeolun wrote: post #164
kevingadd wrote: post #113

Earlier quoted context omitted.

Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters. Of…

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