arendjr

I thought we were talking about gamers and Linux users? :p

I have a Framework laptop (Intel GPU) with Arch and KDE, and while I’ve never seen all windows crash when connecting an external monitor, I wouldn’t call it out of the ordinary for one or two to crash after I connect one, especially if I try to drag one to a new position right after.

This is the real reason we have linters.

I absolutely agree with you. If I can avoid NPM I will indeed do so. Sometimes that means using Deno, but sometimes it can be a valid reason to avoid using the language altogether. And sometimes we have to suck it up 🤷‍♂️

As much as people like to make fun of JS/TS, I think you’re right, especially compared to the languages you mentioned. It’s my second-favorite language after Rust.

I think I would put Swift above it as well, except I don’t really use it since it’s too domain-specific in practice.

If you just have one or two required fields, with the rest being optional, it can also be a good middle ground to just pass the required fields to new() and use methods like in your example for the optionals.

PS.: A common convention for these methods is to prefix them with with_, like with_max_depth(max_depth: usize) -> Self.

Nah, more senior devs often also advocate for the quick fix, for the simple reason that the economics of a “proper” fix simply don’t add up, especially when you don’t know how much value such a fix would bring anyway. If you’re always looking to create “proper” solutions in hopes of someone in the future thanking you for it, it most likely means your priorities aren’t where they should be and it’s very unlikely someone will thank you for it.

I even wrote a blog on this topic: https://arendjr.nl/blog/2023/04/mvp-the-most-valuable-programmer/

Sorry, I don’t understand. Do you mean there have to be 6 digits of Pi in there, or the sixth character must be π? I’m down either way.

Sure! The other day someone called it emergent architecture. I guess it goes by multiple names :)

I would suggest indirection is one of the forms of abstraction? Making abstractions to “defer” architecture seems quite counter-intuitive to me, since the thing you’re deferring is implementation. But the architectural part — the abstraction — gets front-loaded. The idea that an abstraction can truly abstract the “how” of user persistence is very much the kind of fallacy I warned against when it comes to leaky abstractions. Do you want to use async methods for persistence or not? Do you want to persist is batches or not? How will you be notified of completion or errors? The answers depend very much on actual architectural implementation, and if you had created an upfront abstraction you may very well find it won’t suffice if any of these variables changes. So no, I don’t think that really defers architecture at all, it merely solidifies your current assumptions about how your architecture will probably look like in the future. If any of these assumptions turn out wrong or simply undesirable later, you’ve made things harder for yourself. So if that’s the risk anyway, it’s fine to just stick with a simple concrete solution when you can.

I do agree pure functions are harder to do in impure languages, but it’s not as bad as your example of C. Rust is very much an impure language, but its borrow-checker helps you to enforce purity constraints. In fact, using pure functions there is a great way to avoid getting into fights with the borrow-checker. If you use TypeScript you can use Immer to aid you, which is also included in the Redux Toolkit.

Can’t it be both? :)

Ah, fair :) then yeah, I’d say it’s pretty aligned with emerging architecture, just that I’m trying to define the values (and in the next post, technical guidelines based on those values) to (hopefully!) help you make the right decisions as you’re working on an emerging architecture.