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

221–230 of 429 posts

Re: It takes a PhD to develop that

#221

Post by gnustop »

amw-zero wrote: post #202
tinco wrote: 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.

And he had a condescending tone from the beginning (as he always does). Maybe if he was more respectful / likable, the developers would have responded better.

Where? He started completely neutral here:

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

We live in a time where every competent developer is slandered in public if he isn't fully submissive to the great corporate powers.

Re: It takes a PhD to develop that

#222

Post by 2OEH8eoCRo0 »

jiggawatts wrote: post #20
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 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.

Re: It takes a PhD to develop that

#223

Post by Jensson »

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.

Games are typically much better at internationalization and accessibility than developer tooling though. For example this new windows console doesn't have either, but all big games gets translated to and handles text from languages all over the world.

Re: It takes a PhD to develop that

#224

Post by jiggawatts »

mmis1000 wrote: post #114
jiggawatts wrote: post #66

Earlier quoted context omitted.

I'll reiterate a rant about Flight Simulator 2020 here because it's on-topic. It was called "download simulator" by some, because even the initial installation phase was poorly optimised. But merely calling it "poorly optimised" isn't really sufficient to get the point across. It wasn't "poor", or "suboptimal". It was literally as bad as possible without deliberately trying to add useless slowdown code. The best equi…

I though that it looks more like 'no one touches it at all after function part finished'. It is insane that someone still do decompress and downloading in the same thread and blocks download during unzip the resource in 2021. Even 2000's bash programmer knows you had better don't do them in order or it will be slow...

It also downloads hundreds of thousands of tiny files over a high-latency connection.

At least initially, it didn't use the XBox CDN either.

Re: It takes a PhD to develop that

#225

Post by knuthsat »

MontyCarloHall wrote: post #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…

I really cannot fathom how one could forget fundamentals.

I can prove the average complexity of quicksort with simple math transformations of initial recurrence equation which I do not even have remembered but I'm sure I could derive. Last time I did this was maybe 8 years ago if not more.

Yet somehow an accomplished dev cannot spot accidentally quadratic behavior when coding in something that is not Haskell.

IMO, the average dev and average accomplished dev is no longer the kind that knows the fundamentals. Not that it's necessary in all cases but eventually everything will look an equivalent of a doctoral thesis when the average codes the spaghetti mess.

Recently I was reviewing code with map(find).sort(indexOf) (O(n^2 log n + n^2) behavior) when it could have been a simple dict; map(dict.get) (O(n)). This person has 10 years of coding experience. When looking at the resume, the dev is pretty accomplished, productive, and worthy of the salary. But I assume the knowledge of fundamentals was missing from the start.

Re: It takes a PhD to develop that

#226

Post by mwcampbell »

avereveard wrote: post #214
mwcampbell wrote: post #209

Earlier quoted context omitted.

I suspect an i18n issue. What locale are you using, and what is the decimal separator character supposed to be in your locale?

https://i.imgur.com/WrsVwFz.png absolutely standard

It looks like your "Digit grouping symbol" field is empty. I'm sure that's standard in some locales, though not for US English. I don't know how to make that field empty; when I try, Windows says it's invalid. So I wonder if your locale sets that separator to some kind of Unicode character that, in a proper renderer, is equivalent to no character at all. If that's the case, then I'm guessing refterm could handle that character as easily as it handles VT escape codes. But this does lend some weight to the position that Casey was oversimplifying things a bit.

Re: It takes a PhD to develop that

#227

Post by Jensson »

2OEH8eoCRo0 wrote: post #222
jiggawatts wrote: post #20

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.

Do you use colored text tags? The performance issues only happened when that was on.

Re: It takes a PhD to develop that

#228

Post by jiggawatts »

avereveard wrote: post #206
mwcampbell wrote: post #144

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.

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 content of a scientific journal paper because of a typo.

"Sorry Mr Darwin, I'm sure you believe that your theory is very interesting, but you see here on page 34? You wrote 'punctuted'. I think you meant 'punctuated'. Submission rejected!"

Re: It takes a PhD to develop that

#229

Post by stefs »

inexperienced developers are unable - or just rarely - ask themselves the question:

"is the current performance in the right ballpark of where it should be?"

here it's obvious - muratori took one look at that thing and just knew that "no, 2-3 fps is definitely, completely off". i, too, had a couple of those moments where i got my hands on some code and thought: "that just can't be right" and then found O² algorithms, byte-by-byte io copy routines, database abuse or duplicated work.

if you don't have the rough reference points of what should be right, you often just don't question correctly working code.

Re: It takes a PhD to develop that

#230

Post by mkr-hn »

moffkalast wrote: post #220
amw-zero wrote: post #202

Earlier quoted context omitted.

And he had a condescending tone from the beginning (as he always does). Maybe if he was more respectful / likable, the developers would have responded better.

Well given how absurdly big the difference is, and the main thing he did was render on demand instead of 7000fps I think he has a good reason to be condescending and they totally deserve it for wasting millions of people's time with this shit.

See also: the blinking cursor in Visual Studio Code.

Here's a thread on it with other examples: https://news.ycombinator.com/item?id=13940014

They fixed it, but it was a sign of the times. Everything we've used over the decades had to be re-implemented for the web and stuff like Electron, and the people doing the implementing use such powerful machines that they don't even notice a simple blinking cursor devouring CPU or think about its impact on normal computers.

Post reply on HN