It takes a PhD to develop that • Hacker News Board

Re: It takes a PhD to develop that

#381

Post by kaba0 » Mon, Oct 04, 2021, 8:46 PM UTC

kevingadd wrote: post #113

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…

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…

You are right in the general case. But terminals are a specific niche, not requiring the full extent of text rendering edge cases as a browser, wysiwyg editor, etc “experience”. It renders “strictly”* monospaced fonts, which makes it trivial to cache and parallelize.

* as it was brought up, one might use a non-monospace font, but that case can just use the slow path and let the “normal” people use a fast terminal

Re: It takes a PhD to develop that

#382

Post by ridethebike » Mon, Oct 04, 2021, 8:50 PM UTC

mwcampbell wrote: post #213

maficious wrote: post #180

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.

Can't recall when it was the last time I played game with no internationalization support

Re: It takes a PhD to develop that

#383

Post by CogitoCogito » Mon, Oct 04, 2021, 10:16 PM UTC

justin66 wrote: post #370

CogitoCogito wrote: post #356

Earlier quoted context omitted.

Why talk in such generalities? Look at the github repo. There are only three committers to Casey's repo. I'm sure Microsoft could manage to contact them. I'm also quite sure that Microsoft has the money to entice a commercial license if they so wish.

> Look at the github repo. There are only three committers to Casey's repo. I'm sure Microsoft could manage to contact them. Microsoft's attitude towards the code seems a little odd. [0] Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links. Given that WSL exists I can't imagine this is a universal policy towards re…

Yeah the attitude doesn’t really make any sense. How does the license preclude them looking at the code? They can even download it, compile it, and even run it _without_ accepting the license. They only need to care about the license if they decide for distribute it.

Re: It takes a PhD to develop that

#384

Post by jameshart » Mon, Oct 04, 2021, 10:19 PM UTC

db48x wrote: post #352

jameshart wrote: post #336

Earlier quoted context omitted.

So the comment that the 'PhD' reference was responding to was Muratori laying out how he figured a simple terminal renderer could be implemented, using two texture lookups in a single drawcall [0]. In the course of that, Muratori allowed, almost in passing, that of course you would need, in order to do that: > a glyph atlas encoding the cell-glyph coverage in whatever way makes it easiest to compute your ClearType bl…

I disagree. All this means is just putting the glyph cache on the GPU. DirectWrite (or any other font rendering API you care to use) already implements a glyph cache, and it already deals with filling in that cache gradually whenever you use glyphs not already present in the cache. And it already knows about Cleartype, or whatever form of antialiasing you prefer. There’s no research here.

Oh, well sure if it’s just a caching problem then it can’t be difficult.

Only hard part left would be naming it.

Re: It takes a PhD to develop that

#385

Post by tjalfi » Mon, Oct 04, 2021, 10:28 PM UTC

thih9 wrote: post #26

onion2k wrote: 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 seems referenced in the repo itself, see the “feature support” section [1]. That being said, is anyone aware of a significant missing feature that would impact performance? [1]: https://github.com/cmuratori/refterm#feature-support

Screen reader support[0] may have a noticeable performance cost.

[0] https://github.com/microsoft/terminal/issues/10528#issuecomm...

Re: It takes a PhD to develop that

#386

Post by Someone » Mon, Oct 04, 2021, 11:00 PM UTC

CogitoCogito wrote: post #356

Someone wrote: post #172

Earlier quoted context omitted.

Not always. GPL-licensed do not have to have a “ the author”. There may be hundreds of copyright holders involved (IIRC, ¿Netscape? spent years looking for people that had to agree when it planned to change their license and rewriting parts written by people who didn’t)

Why talk in such generalities? Look at the github repo. There are only three committers to Casey's repo. I'm sure Microsoft could manage to contact them. I'm also quite sure that Microsoft has the money to entice a commercial license if they so wish.

Because the comment I replied to made the generic claim (emphasis added) “One thing to remember is that it is always possible and acceptable to contact the author of a GPL-licensed piece of code”.

Re: It takes a PhD to develop that

#387

Post by kaba0 » Mon, Oct 04, 2021, 11:11 PM UTC

adamdusty wrote: post #324

mwcampbell wrote: post #273

Earlier quoted context omitted.

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

Those individual workers hurt the project and the community around it by setting the precedent that you need to create your own competing product to verify that bugs can be fixed without PhD research. Nobody should be harassed over their open source project, but that doesn't mean actions don't trigger reactions.

Nor does it mean that a simple mistake could not be remedied, as it was.

And we should be forgiving.

Re: It takes a PhD to develop that

#388

Post by crispyambulance » Mon, Oct 04, 2021, 11:42 PM UTC

moritonal wrote: post #326

crispyambulance wrote: post #285

Earlier quoted context omitted.

I think the comment below in the github thread sums up the attitude of the developer. It's definitely not a "neutral" attitude. It's somewhat chip-on-shoulder and somewhat aggressive. > Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader.…

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-grade terminal shell applications and all their features and requirements?

And even if it is "easy", so what? It just means Microsoft missed something and perhaps were kind of embarrassed, that's totally human, it happens. It's not so nice when this stuff is very public with harsh judgement all around.

This all rubs me the wrong way. I have found the Microsoft folks to be very helpful and generous with their attention on Github Issues. They've helped me and many others out, it has been genuinely refreshing. What this guy did might discourage participation and make folks more defensive to avoid losing face in a big public way over a mistake or silly gotch-ya.

Re: It takes a PhD to develop that

#389

Post by a1369209993 » Mon, Oct 04, 2021, 11:46 PM UTC

onion2k wrote: 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'…

> > for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking.

> You shouldn't automatically assume something is actually bad just because someone shows a [vastly] better proof-of-concept 'alternative'.

Apparently you should. I can confirm that the first quote is a appropriate assessment of the difficulty of writing terminal renderer. Citation: I did pretty much exactly the same thing for pretty much exactly the same reasons when (IIRC gnome-)terminal was incapable of handing 80*24*60 = 115200 esc-[-m sequences per second, and am still using the resulting terminal emulator as a daily driver years later.

Re: It takes a PhD to develop that

#390

Post by hnfong » Tue, Oct 05, 2021, 1:36 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…

> 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 construct efficient solutions to problems you have never seen before. And by "construct" I don't mean pattern-matching to previously-memorized algorithms, I mean writing something that didn't exist before you wrote it.

Yes that's what I was trying to say. When people talk about "algorithm skills" it's not clear what whether they mean only learning the stuff from the textbook, or whether they mean the ability to improvise on top of that. Sometimes I suspect people don't know the difference themselves either. For example in the context of technical interviews, if the interviewer chooses a typical question like implementing binary search, reversing a linked list etc., they are most likely going to filter for those who memorized (to some extent) the solutions instead of those with ability to create novel solutions.

So about "algorithm skills are useless and shouldn't be used when interviewing", I guess my point is, it's useful, but it really depends on the interviewer not to screw it up by picking a standard question that can easily prepared for beforehand.