My company hired a number of PhDs. They were all smart and well educated but for some reason couldn’t turn that knowledge into working software. So they were all fired in less that a year.
It takes a PhD to develop that
421–429 of 429 posts
Re: It takes a PhD to develop that
#422Earlier quoted context omitted.
> My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To clarify, in practice, what you use 90% of the time are plain arrays and indices / pointers. Occasionally you'll use a hashmap to lookup (distributed) or cache something. This doesn't make any sense. It sounds like you're implying that algorithms are not... using plain…
No need to get condescending. > It sounds like you're implying that algorithms are not... using plain arrays and pointers? Ok, but no, I did not mean to imply that. What I mean is that most programs are either straightforward linear scans over whole arrays, or working on data that was specifically requested by some index requested by a separate entity. Using a hashmap to lookup items faster is almost at the ceiling o…
> No need to get condescending.
I apologize.
> Ok, but no, I did not mean to imply that. What I mean is that most programs are either straightforward linear scans over whole arrays, or working on data that was specifically requested by some index requested by a separate entity. Using a hashmap to lookup items faster is almost at the ceiling of complexity of most real-world programs.
Ok, now I see what you mean. I mean, I disagree with you, but I understand your point now.
> And really, that's sufficient to do most things at max speed. "Algorithms" (meaning stuff like interval trees, Fenwick trees, LCA computation, square root decomposition...) is irrelevant academic exercise for the vast majority of applications (including kernels and games).
Yes, all of the examples you provided are irrelevant for your average project. I don't mean that your average project would run into a need to optimize range queries with Fenwick trees. I mean your average project will run into situations where someone needs to write a simple O(n) list traversal, and they somehow manage to write it as O(n^2) because they have no understanding or interest towards algorithms. If the organization has staffed at least some people who care and have algorithm skills, they will spot these "low hanging fruit inefficiencies" and fix them.
Re: It takes a PhD to develop that
#423A 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'…
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
That's not unfortunate. Having people who work on competing Free Software is a good thing. It would be even better if Microsoft adopted this code and complied with the terms of the GPL license. Then we won't have to deal with problems like these because they'd be nipped in the bud. And we would set the precedent to take care of lot of other problems like the malware, telemetry, abuse of users' freedoms.
Re: It takes a PhD to develop that
#424Earlier quoted context omitted.
> 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.
Blanket policy to prevent claims of "you looked at our code and stole $importantDetail": only let people look at code you can safely admit to using in your product.
Re: It takes a PhD to develop that
#425PhDs often make the worst possible developers. People with PhDs (especially in Mathematics) are often lacking the most critical characteristic of a good developer; they don't know why they do things. 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. This is very different from how software problems should be approach…
I have a PhD (physics), and I worked in a quant team with maths, physics, engineering and comp sci PhDs, and I can assure you the bell curve demographic is identical there as it is in a department of non PhDs. There are some very good developers, the odd mythical "10x" developer (in this case, someone that really just writes repeatedly same thing in every job to be honest), and some very poor developers. > The PhD di…
My point is that, on average, in my experience, they are more interested in big complex theories and hypotheticals than in reality and all its tedious subtleties. They can miss the point that all these tedious subtleties add up in terms of complexity and shouldn't be scoffed at.
This infatuation with complexity is itself a big problem. I've observed a lot of PhDs neglect the cost of complexity. Choosing complex solutions with significant practical drawbacks over simpler ones in order to get some tiny gains in performance (for example) or to get some specific characteristics which they feel is important but which the average user doesn't care about at all.
Re: It takes a PhD to develop that
#426Earlier quoted context omitted.
> I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil." Except that line was written in a book (Volume 1: Art of Computer Programming) that was entirely written from the ground up in Assembly language. Its been a while since I read the quote in context. But IIRC: it was the question about saving 1 instruction between a for-loop that counts up vs a fo…
> Except that line was written in a book I recall it being from his response to the debates over GOTO, and some googling seems to agree. Not that that takes away from your overall point.
In the office today with my copy of Literate Programming (which contains the essay in question) I can confirm that the sentence does appear in "Structured Programming with goto Statements" (it appears on page 28 of my copy). Here it is in a general context, not pertaining to a single particular example.
In support of your overall point, though, having just said "[w]e should forget about small efficiencies, about 97% of the time", the next paragraph opens: "Yet we should not pass up our opportunities in that critical 3%."
Re: It takes a PhD to develop that
#427Earlier quoted context omitted.
> But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.
Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be". The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsical…
Agreed. It doesn't seem like it is relevant. My comment was more addressing that it _is_ an edge-case, albeit a very unlikely one.
Re: It takes a PhD to develop that
#428This reflects a lot of what goes on in Academia as well. Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career. "Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.…
Some professors are humble though. I had a Physics 101 professor who gave a test that had a problem involving blowing a fan into a sailboat sail. The answer to the question was supposed to be that the sailboat doesn't move anywhere because of Newton's 3rd law, but one guy in the class spent close to the entire exam on that one problem showing that it would slowly move forward using a conservation-of-momentum-based ap…
Interesting story :-)
I wonder if they sorted out the differences between the maths approaches, so the professor could agree also math theory wise
Re: It takes a PhD to develop that
#429Earlier quoted context omitted.
If Microsoft embedded the GPLv2 terminal into Windows, Windows would have to release as GPLv2 (or compatible license). I assume they don't want that. They can alternatively buy a commercial license, as another user said below.
You should read up on the "mere aggregation" clause of the GPLv2. It allows an OS to include a GPLv2 program without having to put the entire OS under the GPLv2. If the GPLv2 did function the way you seem to think it does, then almost every Linux distro would be in violation, too.
Thanks, I think this is a very important point that I totally missed.