Earlier quoted context omitted.
I just launched "dir" https://i.imgur.com/lkbOR3i.png can't even print properly the decimal separator. maybe it wasn't that easy.
The font, m8, the font. Use monospcae font and it works like a charm.
[deleted]
It takes a PhD to develop that
151–160 of 429 posts
Re: It takes a PhD to develop that
#152Earlier 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.
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, Windows Terminal should simply implement it. Is this dignity or what? Are you not engineers? Should you not prioritise software quality above everything else?
EDIT: Remove argument about ease of development, because refterm is easy.
This bugs me every time. "Wow, this software works so good, but we are not gonna make our software like that, no, we'll stick to our shite implementation."
Re: It takes a PhD to develop that
#153cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below). Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that…
> Expected Behavior
Whether this is interpreted as unfriendly depends on the stance of the reader. I can easily make this sound somewhere between "celebratory" or "intriguing" when I read it. If I were the author and performance/bug-reports somehow meant negative consequences for me, then it would sound hostile.
Re: It takes a PhD to develop that
#154I feel this is missing the elephant in the room, which is that experts are not interchangeable. They have typically specialized in whatever they have spent lots on time doing, and so developers in different sectors develop a lot of different skills that are typically not very useful for developers in different sectors.
A result from that is that what may be trivial for people in one sector is hard for people in a different sector, and vice versa. Often people will not know enough about sectors different from the one they operate in to know what is hard or not in other sectors.
Re: It takes a PhD to develop that
#155Earlier 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…
> The "complaining developer" produced a proof of concept in just two weekends... That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side. Instead of both sides asserting (or "proving") that they're "right" could they not have collabo…
It’s often easier to put together something from scratch, if you’re trying to prove a point, than it is to fix a fundamentally broken architecture.
Re: It takes a PhD to develop that
#156Earlier 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…
I actually have a lot of respect for old school game programmers because they have two traits that many of us who develop mainstream commercial software often lack: a) they care about performance and not in the abstract, but performance as evaluated by an actual human (latency issues in a messaging app are tolerable, a game with latency issues is simply not fun to play) and b) they can sit down without much fuss and quickly write the damn code (the ability that slowly atrophies as one works on a multi-year-old codebase where every change is a bit of a PITA). Sure, the constraints are different, but a lot of it is simply learned helplessness.
Re: It takes a PhD to develop that
#157A 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'…
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).
Re: It takes a PhD to develop that
#158Earlier quoted context omitted.
> SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable. Software engineering can never be anything but an art form! A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone els…
If you look closer everybody who create something on work, like every craftsman, is a kind of an artist. But it pays very badly, so even for people who like the job, are forced to step up into the office, because of the better pay. That is part if the reason, why you almost can't find a good plumber or electrician. If you can count to 2, you are forced out of the job. As you long, as you write software by yourself, y…
> As you long, as you write software by yourself, you are not much different than a plumber .. you work with your hands.
There is one small difference - a plumber needs to design some piping and then execute it which takes more time than designing. After writing code, programmer just presses a button and results are made by computer. Otherwise, there is some overlap. There are many programmers, who are not more skilled than a skilled plumber or whose job is not more crative than that of a plumber, but we call them "juniors".
Re: It takes a PhD to develop that
#159Earlier quoted context omitted.
> The "complaining developer" produced a proof of concept in just two weekends... That developer also was rather brusque in the github issue and could use a bit more humility and emotional intelligence. Which, by the way, isn't on the OP blog post's chart of a "programmers lifecycle". The same could be said of the MS side. Instead of both sides asserting (or "proving") that they're "right" could they not have collabo…
> could they not have collaborated to put together an improvement in Windows Terminal? My experience with people that want to collaborate instead of just recognizing and following good advice is that you spend a tremendous amount of effort just to convince them to get their ass moving, then find out they were not capable of solving the problem in the first place, and it’s frankly just not worth it. Much more fun to j…
Haha I just saw the youtube video with the developer demoing his project and the text in his terminal literally reads in Hindi "you can wake up someone who is asleep, but how do you wake up someone who is just closing his eyes and pretending to be asleep?"
The developer surely was having a tonne of fun at the expense of Microsoft. Perhaps a little too much fun imo.