Not necessarily closures, but it involved many dynamically generated lists of lambdas passed around through many layers of abstraction.

True. However, in this case I believe this guy just had a weird admiration for complexity.

In my project there has been this guy who produced more lines of code than most other. All of his code is a terribly convoluted mess no one can work with. Also buggy and slow as hell. It’s been many years since he left the company, and the negative effects are still seen today.

Luckily we’ve been able to detach ourselves from the worst parts.

Excessive deduplication is an anti pattern.

The point about removing duplicates is to make the maintaining of the code easier. If it makes it harder, then it’s the wrong abstraction.

More code = more things that must be maintained = more things that can break. It’s natural that development slows down over time. Doesn’t necessarily mean there’s technical debt.

This is the most excited I’ve been about a hardware announcement in a great while.

I think it’s days in home computers are numbered.

Most of the things an average person needs can be done through the web browser. You only need a Chromebook, phone or tablet.

Linux has suddenly become a viable option for gaming. This has been the one thing that kept many away from using Linux.

I don’t really see why anyone would want to use Windows for their home PC, other than familiarity. It doesn’t offer anything you can’t find better elsewhere.

It’s not DNS

There’s no way it’s DNS

It was DNS

There are two main use-cases you want your color theme to address:

1. Look at something and tell what it is by its color (you can tell by reading text, yes, but why do you need syntax highlighting then?)
2. Search for something. You want to know what to look for (which color).

I disagree. I want syntax highlighting because I think it’s easier to read. I don’t care much about which color everything is, just that different things have different colors. I don’t remember any color mappings, and I’m never thrown off guard if the color mapping change.

When I read var count = 0L, I want to know that var is syntactically different from count, and count is different from 0L. That’s it.

Dedicate yourself with a more long term project (1+ months). I think the best way to learn is through the pain that comes with larger code bases.

Start small. Add more and more features. If there’s something you don’t know how to make, find a tutorial or a guide and make it work with your project.

Eventually you’ll discover pain points in your project. The feature you want to make doesn’t fit well with your current code. This is good time to learn from your previous mistakes and adapt your old code for the better (refactoring).

Over time you’ll learn more and more techniques to write code that can grow. You’ll see for yourself why some coding styles are considered bad and why some are better. This is difficult to see just by working with short term weekend scripts.

Don’t worry about failing. No one writes ”perfect” code. You’ll learn from your mistakes.

”Perfect representation” only works if everyone votes. Blue can win with 3 votes against 20 votes.

What I like with squash on merge is I don’t need to worry about shit my coworkers make. My coworkers can have terrible git disciplines, and the master branch is still clean.

I think this is dependent on context. Linus is working with a very public repository. Private repositories shared with a small team have different conditions.

What works in my smallish team at my company is:

• Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.
• You can do whatever shit you want on your own branch. It’s going to be squashed anyway.
• Don’t base your work on some other team member’s branch, unless agreed upon. That’s their work. You should only depend on the master branch.
• Never rewrite what has already been committed to the master branch.

It’s too early to judge. Seems like it’s a solo dev hobby project. I wouldn’t hold my hopes up to ever see this language production ready.

deleted by creator

It’s easy.

Just be Swedish.

LLMs are shoehorned into products for share value reasons, not for usability reasons. Shareholders don’t care if it makes any sense. They want their companies to jump to all the latest trends.

This is why I rarely use AI for coding. How to put my thoughts into code is not my main concern. My main concern is that another person should understand my thoughts when reading the code.

I would buy it if the excuse was they wanted an actor that could do voice as well as motion capture, and maybe David Hayter wasn’t cut to do both at the same time. In some promo it sounded like they wanted someone who could do both. In the age of motion capture, it’s going to be jarring to record voice lines in a booth separately. Particularly if multiple actors interact with each other in a scene.

But no. There was barely any interesting acting at all from Snake. Most of the acting was carried by the other characters, while Snake was just grunting doing nothing in particular.

I’d rather take MGS4 Snake any day.

I don’t think more expensive games is going to cause a crash. If demand decreases, then the prices will follow.

What could potentially cause a crash (among the big guys) is the massive betting on landing the next big Fortnite goldmine. Sony is investing massively on live service titles like Concord, Marathon and Fairgames. Microsoft has struggled equally. They couldn’t even get Halo right.