I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.
C# 9, but with some hacks you can bump it up to C# 10 - actually works and surprisingly stable. Can't wait for them to finally migrate to CoreCLR, though.
Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc.
I always wonder whether C++ syntax ever becomes readable when you sink more time into it, and if so - how much brain rewiring we would observe on a functional MRI.
I do have an inner monologue, but I do make many decisions non-verbally. I often visualize actions and their consequences, in the context of my internal state. When I’m thirsty I consider the drinks available nearby and imagine their taste. In the morning coffee feels most tempting, unless I’ve already had a few cups - in that case drinking more would leave me feeling worse, not better. After a workout, a glass of water is the most expedient way to quench the thirst. It is similar when I write a piece of code or design a graphic. I look at the code and consider various possible transformations and additions, and prefer ones that move me closer to my goal, or at least make any sort of improvement. It’s basically a weighing of imagined possible world-states (and self-states), not a discussion.
I struggle to imagine how people can find the time to consider all of these trivial choices verbally - in my case it all happens almost instantaneously and the whole process is easy to miss. I also don’t see what the monologue adds to the process - just skip this part and make the decision!
That said, I do use an inner voice when writing, preparing what to say to someone, etc. and I feel like I struggle with this way of thinking much more.
> Oh yeah and if the interface removed a method and you didn’t realise you might be dragging that useless methods for a long while. Then again it’s not like your Java-style interface is any different.
In C# I usually use explicit interface implementations. (They're inconvenient to type, but Rider has a macro for it.) When the interface changes or disappears, my code won't compile.
As a game developer, I definitely distinguish high-risk and low-risk parts of the code base.
There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.)
The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny.
Such is the reality of working on complex systems (or simple object-oriented programs ;))
Funny coincidence, my subscription ends today. I’m switching to self employment and won’t be able to afford the service for a while. I wish it were more affordable, because the freeing feeling of not having to rely on google is irreplaceable.
I shipped mine to a friend who forwarded the package to me. They figured out what I'm doing, and I got an e-mail warning me that they'll ship the laptop, but I won't get warranty outside of the country they're shipping to, so not sure I'd recommend doing this.
It’s an extraordinary feature that is only intended for optimization of edge cases. Making the feature verbose and somewhat ugly to use seems like an intentional choice. This way if a beginner comes across this “confusing/weird looking” code they can look up the attribute and see what it does, whereas a more convenient/native syntax would be less recognizable and noticeable. This is similar to the idea that you should make ugly APIs ugly to use (to avoid giving users a false sense of security).
Worked for me at the start of my programming career. I had a few Stack Overflow answers (few hundred karma) and a fairly barebones GitHub profile.
I applied to a large local IT corporation. The person interviewing me (who was a team lead) simply assumed I have the skills necessary for an entry position and we pretty much skipped the technical part of the interview. (I ended up in a fairly fantastic team full of great engineers and coworkers. Turns out the guy who interviewed me was awesome at hiring.)