(they/he/she)
When I was doing more remoting into servers, having tmux was great. These days it’s all local dev, so it’s far less important to me. Plus, I had gotten to a place where my tiling WM, tmux, terminal tabs, and vim tabs were all competing for keyboard shortcuts, and it was driving me crazy.
I prefer to use my WM and a lightweight terminal instead of term tabs or tmux. If another window is going to be short-lived, I won’t bother, but for longer tasks I’ll move to a new workspace, often opening new terminals and file managers, as needed.
Yeah, it’s basically a tiling window manager that lets you expand each workspace horizontally and scroll left and right through it. The value for me is that I often want each window in a workspace to be a certain size. For example, my browser is fullscreen, and my password manager is half a screen off to one side. My terminals are usually half a screen, sometimes stacked if they’re just for monitoring or something, and my IDE is fullscreen all the way to the right of them.
If you want to improve your problem solving skills, I’d suggest solving actual problems. Data structures and algorithms can be very satisfying in their own right, but the real value is in taking a real-world problem and translating it into code.
It also depends what you want to do with your knowledge. There are domains that are deeply technical and require a lot of the things you’ve mentioned, but they also tend to be pretty hard to break into. A lot of software is not so deep. Any software project will have need for good domain modeling, architecture, and maintainability. Again, these are things best learned through practice.
Hmm… I admit I didn’t follow the video and who was speaking very well and didn’t notice hostility that others seem to pick up on. I’ve worked with plenty of people who turn childish when a technical discussion doesn’t go their way, and I’ve had the luxury of mostly ignoring them, I guess.
It sounded like he was asking for deeper specification than others were willing or able to provide. That’s a constant stalemate in software development. He’s right to push for better specs, but if there aren’t any then they have to work with what they’ve got.
My first response here was responding to the direct comparison of languages, which is kind of apples and oranges in this context, and I guess the languages involved aren’t even really the issue.
I think most people would agree with you, but that isn’t really the issue. Rather the question is where the threshold for rewriting in Rust vs maintaining in C lies. Rewriting in any language is costly and error-prone, so at what point do the benefits outweigh that cost and risk? For a legacy, battle-tested codebase (possibly one of the most widely tested codebases out there), the benefit is probably on the lower side.
I think your quantifier of “any other language” is the issue. There are certainly languages with far more powerful type systems than Rust, such as Coq or Lean.
This is my perspective on a lot of art and music. If something is universally hated, I want to know why it is and if I can find any redeeming qualities. A lot of my favorite things have that characteristic of doing something very specific extremely well but being generally unlikeable.
I appreciate the swords-into-ploughshares mindset
One serving of peanut butter