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

301–310 of 429 posts

Re: It takes a PhD to develop that

#301

Post by phkahler »

stephc_int13 wrote: post #216
lbayes wrote: post #196

Earlier quoted context omitted.

I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil." I have encountered far too many people who interpret that to mean, "thou shall not even even consider performance until a user, PM or executive complains about it."

Agreed, as a young performance oriented coder I've been often looked down by people who used Knuth almost god-like authority to dress up all sorts of awful engineering. And of course most people don't know the full quote and they don't care about what Knuth really meant at the time.

>> I've been often looked down by people who used Knuth almost god-like authority to dress up all sorts of awful engineering.

Quick quips don't get to trump awful engineering. Just say call Knuth a boomer and point to the awful aspects of actual code. No disrespect to Knuth, just dismiss him as easily as people use him to dismiss real problems.

Re: It takes a PhD to develop that

#302

Post by zadjii »

vblap wrote: post #162
mytailorisrich wrote: post #44

The github issue is a gem. The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions. The tone gets quite condescending towards him. He gets out of all this with flying colours. He should consider adding that Github issue to his resume.

Yeah, typical Microsoft developers ( https://github.com/microsoft/terminal/issues/10362 ). That issue was pretty mild, they felt threatened and used CoC principles ("combative") to shut down the threat. This is how they also ruin "open" source projects like Python now.

That's a pretty terrible interpretation of events here. Along side the "combative" phrasing was a bit of self reflection

> 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. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.

That post is literally not trying to shut down the conversation, it's simply reflecting on the tone of the commentator. elsewhere in the comment he even prompts for more discussion on the topic. At no point is the CoC invoked.

Re: It takes a PhD to develop that

#303

Post by allo37 »

I noticed that when you propose a new idea, often there is no shortage of resident "experts" giving you hand-wavy reasons as to why it can't work, won't work, etc. I kind of feel like you DO need a PhD just to have enough clout for these kinds of people to trust you.

Re: It takes a PhD to develop that

#304

Post by mwcampbell »

DHowett wrote: post #287
mwcampbell wrote: post #169

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.

As the guy responsible for that comment (and the dev lead for the team! Hi!) I can say it haunts me pretty much weekly. My parenthetical-laden snarky sense of humor, my use of italics to indicate speech-like emphasis and pretty much everything else about that comment has been dissected to parts as small as possible. In the end, though? Yeah, I was completely wrong. I don’t know much about graphics engineering and I’m…

> his group of fans taking every opportunity to slander us

Conversely, I think I went overboard defending you and your team, to the point of making my own over-broad generalization about game devs in another subthread [1]. I'm glad it's practical to get the best of both worlds in this case.

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

Re: It takes a PhD to develop that

#305

Post by phkahler »

Jach wrote: post #170
TeMPOraL wrote: post #67

Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.…

There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming…

>> spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of

I think a good use of the experienced programmer is to write some critical components well. I'm also with you on system level design: These are the important interfaces, you write this piece and you write that one.

Another example, I have an Oculus Quest 2 VR headset. It was fantastic when I got it in March. Now they've got some glitches where the rendering STOPs for a brief instant and the view is not updated with motion. I'm wondering if this is because John Carmack is no longer full time there and someone compromised some design principle in order to implement something. Once the glitches are in, they're going to be very hard to get back out as time goes on.

Re: It takes a PhD to develop that

#306

Post by svat »

lbayes wrote: post #196
TeMPOraL wrote: post #101

Earlier quoted context omitted.

Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…

I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil." I have encountered far too many people who interpret that to mean, "thou shall not even even consider performance until a user, PM or executive complains about it."

The irony is that the very paragraph in which Knuth made that statement (and the paper, and Knuth's programming style in general) is very much pro-optimization. He used that statement in the sense of "Sure, I agree with those who say that blind optimization everywhere is bad, but where it matters…".

Here's the quote in context:

> There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.…

( https://pic.plover.com/knuth-GOTO.pdf , http://www.kohala.com/start/papers.others/knuth.dec74.html For fun, see also the thread around https://twitter.com/pervognsen/status/1252736617510350848)

And from the same paper, an explicit statement of his attitude:

> The improvement in speed from Example 2 to Example 2a [which introduces a couple of goto statements] is only about 12%, and many people would pronounce that insignificant. The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" programs. In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering. Of course I wouldn't bother making such optimizations on a one-shot job, but when it's a question of preparing quality programs, …

Re: It takes a PhD to develop that

#307

Post by withinboredom »

makomk wrote: post #258
withinboredom wrote: post #193

Earlier quoted context omitted.

You can’t use a non-monospace font on a tiled space. Like that literally makes no sense. Of course it won’t look right. This is like asking why you can’t use `out` parameters on an inherent async function.

Whether the font is monospace or not isn't really the problem - that causes some aesthetically ugly spacing, but that's to be expected and it's still readable. The big issue is that the code has completely failed to find a glyph for one of the characters used in something as commonplace as a directory listing from the dir command and people expect better than this from font rendering in modern applications.

If you copy and paste, the characters are there. The problem is that the glyph simply is off the tile.

Re: It takes a PhD to develop that

#308

Post by lentil_soup »

AndrewThrowaway wrote: post #65
holoduke wrote: post #60

Earlier quoted context omitted.

Because a rule of thumb is to not focus too much on performance in the beginning of a project. Better a completed project with some performance issues, than a half product with hyper speed. The key thing with development is to find somekind of balance within all these attributes (stability, performance, loo, reusability etc) In case of FS simulator. Not sure what the motives were. Sure that they had some serious time…

Completely agree on rule of thumb and can't doubt they had their motives. It is no way that simple. Then again isn't it like 101 of game development? Imagine releasing a game that looks stunning, industry agrees that it pushes the limits of modern gaming PC (hence runs poorly on old machines). Fast forward some time - "oh BTW we did it incorrectly (we had our motives), now you can run it on old machine just fine, no…

Because it's never that obvious, it's not really 101 of gamedev to move everything to the GPU.

You know your target specs but where the bottlenecks are and how to solve them will be constantly shifting. At some point the artists might push your lighting or maybe it's physics now, maybe it's IO or maybe networking. Which parts do you move to the GPU?

Also a GPU is not a magic bullet, it's great for parallel computation but not all problems can be solved like that. It's also painful to move memory between the CPU and the GPU and it's a limited resource can't have everything there.

Re: It takes a PhD to develop that

#309

Post by pxc »

zibzab wrote: post #275
jameshart wrote: post #263

Earlier quoted context omitted.

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

Maybe they shouldn't, but...

The 'big picture' he hasn't understood isn't just about text rendering in this instance, though. It's also a picture internal to Microsoft that motivates their commitment to certain libraries. I think the disconnect is to be expected, given that he's not currently at Microsoft. It may also be that some of those commitments are not as well motivated as MS thinks (i.e., maybe the additional maintenance burden of some specialized text rendering libraries for the simplified case of terminals is not so terrible and justified by the performance gains). I don't think this shows that at Microsoft he'd be unable to have a good sense of 'the big picture'.

It's also not clear that any of this shows he isn't a team player. The Windows Terminal developers are colleagues of his in the distant sense of 'fellow developers', but they're not 'his team'. He doesn't have pre-existing relationships with them. And his frustration was in being told 'this cannot be done' in a way that was insufficiently clear and convincing to him and came across as condescending. I think it's reasonable to be frustrated under those circumstances, feeling ignored and maybe also like someone is bullshitting you. I could see the interaction being different if Casey had a different relationship to the other developers and they were more invested in trying to loop him in on their whole suite of platform commitments that ground (or trap) them in the current design, especially if he felt like advocacy for alternative commitments (e.g., to maintaining a separate, simplified stack for rendering text on the terminal) might be reasonably considered.

I'm also sympathetic to some of the MS devs here, because some of Casey's tone could have been taken as suggesting that they weren't really making an effort with respect to performance and that could be insulting. I don't think it was necessarily wrong for them to bring that up. But I don't think Casey was abusive, either, and it doesn't seem like anything that went down in that thread is beyond repair to the point that the people involved in the discussion couldn't work together.

If Casey were interested in working at Microsoft I think it'd be silly to rule him out as a candidate based on what we can see in that thread.

Re: It takes a PhD to develop that

#310

Post by skytreader »

crispyambulance wrote: post #285
gnustop wrote: post #221

Earlier quoted context omitted.

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.

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

Man, if we start taking issue with "Am I missing something?", how can we have productive, good-faith discussions? The only attitude I can associate with that is openness to learn, a genuine curiosity.

How is a yes/no question aggressive? At that point the maintainers had two possible responses:

1. Yes you are missing that ...

2. No that is the complete picture.

But they chose to side channel to a third possibility, "we are put-off by your questioning!". Excuse me what?

Post reply on HN