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

101–110 of 429 posts

Re: It takes a PhD to develop that

#101

Post by TeMPOraL »

Hnus wrote: post #84
mwcampbell wrote: post #56

Earlier quoted context omitted.

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…

When I saw this mentioned on HN I immediately knew this kind of comment would be there because something along the lines and I am paraphrasing "its probably fast because its not enterprise enough" was repeated in every place the refterm was shared by different people even multiple times even after showing all the proof in the world that its in fact the opposite they almost refused to believe that software can be that…

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" counterarguments. That happens, but people too often forget you can design software to avoid or minimize the time spent waiting on IO. And I don't mean just "use async" - I mean design its whole structure and UX alike to manage waits better.)

--

[0] - Or HFT, or browser engine development, few other performance-mindful areas of software.

Re: It takes a PhD to develop that

#102

Post by forgotpwd16 »

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

Maybe that's what usually happens but doesn't apply in that case.

Re: It takes a PhD to develop that

#103

Post by thom »

Hnus wrote: post #84
mwcampbell wrote: post #56

Earlier quoted context omitted.

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…

When I saw this mentioned on HN I immediately knew this kind of comment would be there because something along the lines and I am paraphrasing "its probably fast because its not enterprise enough" was repeated in every place the refterm was shared by different people even multiple times even after showing all the proof in the world that its in fact the opposite they almost refused to believe that software can be that…

Worth bearing in mind that Casey has a long history of unsuccessfully trying to nudge Microsoft to care about performance and the fact that he's still being constructive about it is to his credit.

Re: It takes a PhD to develop that

#104

Post by avereveard »

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…

I just launched "dir"

https://i.imgur.com/lkbOR3i.png

can't even print properly the decimal separator.

maybe it wasn't that easy.

Re: It takes a PhD to develop that

#105

Post by GuB-42 »

choeger wrote: post #10

Counter argument: If the experienced programmers stay where they are, software development will forever remain craftsmanship. A single developer can only tutor so many juniors. In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got…

Good software development can't be anything but craftsmanship, or art if you think of "art" as in "artisan".

Think of what a developer is, and what a computer is. A computer is a dumb machine, it lacks creativity, it is only good at executing orders, but that, it does it very well, and very fast. A programmer is a human, creative and able to see the big picture, his task is to inject his human qualities into the dumb machine, so that the machine can do things that are useful for humans.

So, programming is the opposite of applying recipes, if there is a well defined recipe, that's for the machine, not for the human. If programming is not an at least a little bit of an art form, it means the programmer is doing the job of the computer, which is a waste of valuable human time on something the machine can do better.

Re: It takes a PhD to develop that

#106

Post by j_barbossa »

On the one hand you have idealists who think the most important thing in the world is getting the last bit of performance out of every program. On the other side you have businesses who don't care too much about performance of their applications (especially when no money can be made out of it) as long as 80% of use cases are covered.

Whichever side you sympathize with, it's pretty arrogant to think the other side is completely wrong.

Re: It takes a PhD to develop that

#107

Post by CogitoCogito »

masswerk wrote: post #63
CogitoCogito wrote: post #29

Earlier quoted context omitted.

> Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear to you. This is very different from how software problems should be approached. I don't really agree. Being good at mathematical research requires recognizing the "core organization structure of a system" and solving the "core problem at hand". I'd argue that it's es…

However, there are probably infinite organization structures describing a complex system and there isn't any ontological reality to Occam's razor. Programming is really much about deciding where and at what level to allocate partial structure, which again informs the broader picture of the core organization – and some of this may be even intuitive.

Are we actually in disagreement? I could just as well describe math as "deciding where and at what level to allocate partial structure..." in the same way. Mathematical researchers also build intuition over time allowing them to see certain big picture ideas more easily.

If I really take a step back and re-think this whole thread, I'd say the main different between mathematical researchers and programmers is just incentives. Funding and output are just fundamentally measured differently and the work is done very differently with respect to cooperation with others.

Still I'd say that the thing holding back mathematicians from being good developers is simply that research mathematics does not provide development experience.

Re: It takes a PhD to develop that

#108

Post by Hendrikto »

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

From the refterm README:

refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports:

* Multicolor fonts

* All of Unicode, including combining characters and right-to-left text like Arabic Glyphs that can take up several cells

* Line wrapping

* Reflowing line wrapping on terminal resize

* Large scrollback buffer

* VT codes for setting colors and cursor positions, as well as strikethrough, underline, blink, reverse video, etc.

Re: It takes a PhD to develop that

#109

Post by flohofwoe »

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

A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality se…

It may sound oversimplified, but IME PC games are only optimized to the point where it runs well on the development teams beefy PCs (or in the best case some artificial 'minimal requirement PC with graphics details turned to low', but this minimal requirement setup usually isn't taken very seriously by the development team).

When porting to a game console you can't simply define some random 'minimal requirement' hardware, because the game console is that hardware. So you start looking for more optimization opportunities to make the game run smoothly on the new target hardware, and some of those optimizations may also make the PC version better.

Post reply on HN