(they/he/she)
Herndon and Dryhurst are frequent collaborators, and xhairymutantx is their work. So they didn’t just prompt an LLM to make the image, they trained the model themselves. And they specifically trained the model on pictures of Herndon (who has distinctive red, braided hair).
I’m personally a really big fan of their work (which I don’t expect everyone to be), but the picture that’s being circulated in articles and apparently sold at auction without context is pretty uninspiring.
Modal editing for just raw text input would actually be slower, because you also enter and leave Insert Mode. I find it’s very fast and powerful for navigating around the text, which you probably do a lot more than actually editing it. And when it does come to editing, there are a lot of higher-level tools (at least in Vim) for accomplishing things more quickly, like the ‘s’ command and ‘q’ macros.
I think getting into a mental “flow” state is really valuable, and muscle memory is important for being able to stay there. If your muscle memory is to navigate around using the mouse, that’s great, but Vim feels faster to me.
Acronyms, backronyms, portmanteaus, and puns
https://www.swi-prolog.org/pldoc/doc_for?object=%23>%3D+%2F+2
It’s a better replacement for the built-in =
predicate.
Yeah, you would get a runtime error calling that member without checking that it exists.
Javascript and not Coq?
I actually like it better this way, as I wouldn’t have to reach in as far to turn it on. I think having controls there and the spigot on the corner on the left would be best, though.
One serving of peanut butter
Every day in standup
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.
Armed Bear in the same vein
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.
Having tasted a few dog foods and treats, I agree.
I’m guessing the pumpkin spice isn’t too strong either, but dried pumpkin is the first “flavorful” ingredient, at least.
But these do have pumpkin in them.
My dog goes nuts for pumpkin puree, but hates greenies, so I dunno
YMMV but switching to vertical tabs might be an improvement. Especially with such a wide screen, and since most websites (especially articles) only use a narrow column in the center, it’s been great for me.