magic_lobster_party

I agree with the first point. Always go for clarity over cleverness.

I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.

Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.

From a professional perspective I’d say: don’t rewrite if you’re unsure about it. Rewrite if there’s a particular problem you need to solve and a rewrite is the only way to do it.

For example, you need to make major changes in the tech stack. Like switching from PHP to NodeJS. This is difficult to do without a complete rewrite.

Rewrite for the sake of rewrite is usually a waste of time, and it’s not certain that the code will turn out better in the end. You might end up with a similarly convoluted system either way. And the worst part is: now you have two systems to maintain at the same time.

Likewise, refactor if there’s a particular problem you want to solve. Don’t refactor just for the sake of refactoring. If you don’t have a clear goal, then you’re just scrambling the code around.

From a hobbyist perspective: do whatever you feel like. A complete rewrite can be a good learning experience.

It’s a hyped language because it solves many problems that has persisted with C and C++ - without having to rely on garbage collection.

If anything, it’s underused. Not that I believe everything should be rewritten in Rust. That’s just stupid.

Shadow of the Erdtree would be my pick. Mostly because I haven’t played that many other games from 2024.

And I think it deserves to be nominated even if it’s DLC. The amount of new content is more than most games.

I’m at the point where I think I can engineer anything. But I also know that it takes effort and I ain’t gonna do that unless there’s a paycheck.

Java with Spark.

Although I feel like I’m doing less of data science and more of data processing.

I don’t really know how to describe him. I guess Casey is proof that one can be skilled in programming, but still have a fundamental lack of understanding in software engineering.

This is just so wrong. He’s too nostalgic of the Amiga days.

First, he has no concrete proof that many lines of code is bad. He’s just saying “I feel like things are worse now and here’s a graph that correlates with my feelings”.

And then he shows a graph of the number of lines in the Linux kernel. Yeah, Linux grew in size mid 90s because that was when people wanted to make it work on computers other than Torvald’s own!

Secondly, no one wants to plug in an USB and grant whatever is in it full machine access. It’s a major security concern, and people want multitasking. What if I want to listen to Spotify while I play my game?

The USB thing is likely not going to work either way because it can’t take into account for all possible configurations. Too bad, this program doesn’t recognize your specific WiFi card. You have to survive without internet.

Unless someone manages to perfectly standardize everything that can possibly happen in a computer. That ain’t going to happen.

When they started with episode 3 they’ve already worked on Half Life 2 for more than 8 years. Most good ideas had already been explored, and they struggled to come up with new ones.

At that point it’s easier to start with something fresh where they’re not confined with the expectations of what a Half Life 2 should be.

Some that come into my mind:

Sekiro Devil May Cry 1 & 3 Wonderful 101 Armored Core 6

I think these games are better on the subsequent playthroughs. Sekiro also has that itch no other game is able to scratch.

I think it shows that Valve has built a strong culture for creativity that’s hard to replicate. Their approach to play testing. The “flat” company structure.

What’s evident from the HL2 documentary is that there’s no single mastermind behind the game. There’s no Hideo Kojima or Will Wright. It’s the creative output of many individuals.

I watched the full documentary now. It’s clear they were burned out of Half Life when they started with Episode 3. The idea to deliver a new episode every 12 months wasn’t creatively sustainable. So they put it on hold while they worked on L4D and other projects.

They hoped the episodic delivery of games would be the future. Especially alongside a digital distribution platform like Steam. I suspect they realized episodes wasn’t the way after the release of Orange Box, so they moved on from that.

Math skills can occasionally be useful, but I don’t see it as a dealbreaker.

The good thing about being good with math is that it usually means you’re a good problem solver, and problem solving is an important skill for programming. But the reverse isn’t necessarily true. You can be good at problem solving but still be bad at math.

I would say if you’re struggling with the programming courses, then maybe look somewhere else. Otherwise, go ahead.

Python is truly a mess when Docker is considered a solution.

Nothing comes close to Perl’s abuse of global variables. Oh you called this function? Take a guess which global variables it will use.

Do you know why?

The type is dynamic. It can be whatever you wish.

From the original document:

Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026.

My interpretation is that smart pointers are allowed, as long it’s systematically enforced. Switching to a memory safe language is just one example.

Apparently it’s super successful. Has made $3 billion within a year.