Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

171–180 of 429 posts

Re: It takes a PhD to develop that

#171
In my experience, basic coding skills can really atrophy in senior developers who quit writing code years ago and are full-time architects/managers.

I’ve interviewed more than a handful of extremely accomplished people with decades of experience as developers and then engineering managers who couldn’t answer extremely basic coding questions (we’re talking “efficiently find duplicates in a list” or “compute Fibonacci numbers” basic). These people never could get past the O(n^2) brute force solution for finding duplicates (or the brute force compute every Fibonacci number starting from 1, 1), because they hadn’t thought about even basic algorithmic complexity in so long. And when people like this are giving orders from the top, you can see how software can get so slow.

I have no doubt that when these people were actually still coding, they could have answered my questions in their sleep. Quitting coding for engineering management really does one a disservice IMO. To this article’s point, I’ve also had the pleasure of working with people with decades of experience who never quit coding even as senior managers and their level of competence and productivity is astounding.

Re: It takes a PhD to develop that

#172

Earlier quoted context omitted.

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…

> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 One thing to remember is that it is always possible and acceptable to contact the author of a GPL-licensed piece of code to enquire whether they would consider granting you a commercial license. It may not be worthwhile but if you find exactly what you're looking for and that would take you months to develop yourself then it may very well be.

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)

Re: It takes a PhD to develop that

#173

Earlier quoted context omitted.

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

I’ve seen it at least as many times, too. Most of the time, the optimization is pretty obvious. Adding an index to a query, or using basic dynamic programming techniques, or changing data structures to optimize a loop’s lookups. I can’t think of a counter example, actually (where a brutally slow system I was working on wasn’t fairly easily optimized into adequate performance).

It is nice when a program can be significantly sped up by a local change like that but this is not always the case.

To go truly fast, you need to unleash the full potential of the hardware and doing it can require re-architecting the system from the ground up. For example, both postgres and clickhouse can do `select sum(field1) from table group by field2`, but clickhouse will be 100x faster and no amount of microoptimizations in postgres will change that.

Re: It takes a PhD to develop that

#174
post #150

Earlier quoted context omitted.

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

As far as I understood from the video about refterm the speedup is mostly due to not rendering literally every frame in sequence (after all, who needs that), which is what windows terminal seems to be doing. That seems like it would be unaffected by correcting font rendering.

> That seems like it would be unaffected by correcting font rendering.

It is.

"... extremely slow Unicode parsing with Uniscribe and extremely slow glyph generation with DirectWrite..."

Glyph generation is about rasterising text, because you can't just feed it the font file.

Re: It takes a PhD to develop that

#175

Earlier quoted context omitted.

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

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.

That is probably why they have this law called wirths law about the wintel ecosystem. What Andy giveth, Bill taketh away.

Or Gates's law "The speed of software halves every 18 months"

Re: It takes a PhD to develop that

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

Re: It takes a PhD to develop that

#177
Such an interesting case. We need to encourage respectfully disagreeable people like the developer who raised this issue. A less disagreeable person would have stopped pushing after receiving the GitHub feedback regarding how complex the problem was.

Re: It takes a PhD to develop that

#178

Earlier quoted context omitted.

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

Refterm is a not a full-featured terminal in terms of configurability, but it has all the features needed for rendering. Configuration like: choosing fonts, choosing colors, tabs, whatever, it's misc. features, which are unrelated to rendering. The case here is about rendering and it's exactly what is shite in every terminal emulator. I don't understand why everyone is arguing about it anyway. Refterm provides a fix,…

The fact that Casey Muratori's proposed approach requires the terminal to reimplement the process of correctly mapping characters to glyphs - including stuff like fallbacks to other fonts - is a huge part of the argument for why it's much harder to implement and more complicated than he claims. If it really doesn't do that right for something as simple as a decimal seperator for the font some random HN commenter happened to use, that does tend to suggest the Microsoft employees are in the right here.

Re: It takes a PhD to develop that

#179

Earlier quoted context omitted.

The font, m8, the font. Use monospcae font and it works like a charm.

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?

Re: It takes a PhD to develop that

#180
post #49

Earlier quoted context omitted.

And the experienced developer is Casey Muratori who is somewhat well known for being a very experienced developer. That makes it less likely that he doesn't know what he's talking about and is skipping over hard/slow features.

However, his experience, in games and game development tools AFAIK, might not be fully applicable to the development of mainstream commercial software that has to try to be all things to all people, including considerations like internationalization, accessibility, and backward compatibility. The performance difference that he demonstrated between Windows Terminal and refterm is certainly dramatic, but I wouldn't be…

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