AI coding was experimental a year ago. It's no longer experimental anymore. The industry standard is that most code changes are AI generated.

>None of them made significant use of the speed—they all managed to control the bicycleusing just the handlebars.

I think is where it refers to it.

What it actually takes is taking the floppy disc out, cleaning any mold on it, putting it back in the case, and then using greaseweazle to image the magnetic flux of the disc.

I feel like virtualization is not the right way to handle things. It adds so much complexity and makes the user experience buggy due to breaking optimizations and features of browsers.

Computers are very powerful these days and have a done of resources that they can use. We should be able to handle large diffs without any crazy tricks.

> I feel like virtualization is not the right way to handle things.

How would you handle it?

Keep things as simple as possible and put the whole thing in the DOM. Then if there are performance problems address the scaling problems themselves instead of trying to avoid scaling. For example things like only rendering what is visible should be handled by the browser and not by messing with the DOM. The DOM is not synchronized with the browser's renderer so it will always end up hacky.

OK but thats simply doesn't perform.

You can't say "only rendering what is visible should be handled by the browser" and call that a solution unless you have a magic wand to make Chrome/other browsers do this.

The browser doesn't do this, and so you can either do what you say and have your browser freeze when you load up a million line diff, or you can fix things within your control which is what the author is doing.

Would love to see a website that makes everything DiffsHub does without making any of the work necessary. Making it all obsolete would be a huge step forward for the web. We support diffs that exceed 36 million lines, with syntax highlighting, comments, bundled into a reusable library for anyone to use.

Also this works in all browsers, fixing blink doesn’t help move the web forward.

Glad we solved glitchy scrolling for now (the title of this blog post was “on rendering diffs”, not “searching diffs”). Browser search on a 36 million line diff would not by great, but it’s something we hope to have a solution for. One step at a time.

If the solution for searching big pages was built into the browser then it would be fixed for every site instead of requiring each site to use a library or fix it themselves.

I would prefer that $0 for cleaning gets taken out of my deposit.

So just make every game free to play and then require a paying to unlock the actual game.

As ever it will come down to judicial discretion whether trivial word games are allowed to nullify the law or not.

That'd IMO count as a monetary consideration, and thus not be excempt.

I wonder if making the game free to play before shut down would allow them to skirt the law?

I doubt it, as that'd not nullify the contract established by people who bought the game before it went FTP.

That will negatively affect shareholders which is the opposite of the employees' job. Maximizing the value of the stock to shareholders over time.

I hope you tip your earnings back to corporate and organize your peers to suppress your wages

I do a personal stock buy back which applies upward pressure to the stock price. I don't organize to suppress wages due to wanting to avoid the secondary effects of driving away good talent.

Doesn't sound like the talent is very good if they are not so mission-driven to donate their wages to shareholders.

You want to surround yourself with peers who negotiate for as high pay as the market will bear? That sounds like a sacrifice of shareholder value for selfish cause. Just because workers have leverage doesn't mean they should use it against shareholders.

Are you implying the only differentiator between good and bad developers is the aesthetic of the code itself? And not the actual computation the code does? Wild take honestly.

As counterintuitive as it sounds, it turns out video game consumers don't care much about the actual computation either. Most games are riddled with bugs, and it has next to no impact on sales. Rather, having weird, even embarrassing bugs can make players look at the game more fondly. Skyrim is one of the best selling games ever. Ostensibly it's about fighting dragons. But "Skyrim moment" does not mean an epic battle with a dragon. It means said dragon flying through a goddamn castle, then getting stuck on a single tree and disappearing into the ground, and still hitting you with fire breath somehow.

People care about stories.

Buggy games have destroyed franchises. Gothic 3 being a prime example. Contrary to the memes skyrim is not even close to the worst offenders in terms of bugs. Besides bad code does not only lead to bugs. It can lead to bad gameplay, bad performance, missing features, slipped deadlines. A things users care a lot about.

Gothic has always been a niche franchise, and G3 was poorly received not because of bugs, but because of bad worldbuilding (orcs speaking human language, magic runes disappearing, a powerful kingdom getting wholly conquered in basically no time, pretty small open world) and uninteresting story compared to previous titles. Sure it did have bugs, but so did G1 and G2. And that one AssCreed game where people's heads disappeared leaving just eyeballs behind, which still sold crazy numbers. Or the famously bad Cyberpunk 2077 launch, where bad means millions of copies sold in first 2 weeks, not even counting preorders. Or countless other examples.

Most players care about performance even less than they care about bugs. Basically every AAA game nowadays is criticized for piss poor performance and not having the looks to justify it. They're still massive successes.

Usually, it's good code that leads to missed deadlines, not bad code. It literally takes more time and effort to write good code. Gamedev lives on 3-year cycle, that's not enough time for code debt to start causing problems.

Bad gameplay... yes, that can be actual problem. But it's rarely due to a single bad line of code, or even ten thousand bad lines of code. In most games, gameplay is bad because it was designed to be bad. As in, they had a certain way of playing in mind, and they made the game exactly how they wanted, it's just most players don't find that way of playing fun. No amount of code quality can fix that.

> Gothic has always been a niche franchise, and G3 was poorly received not because of bugs, but because of bad worldbuilding (orcs speaking human language, magic runes disappearing, a powerful kingdom getting wholly conquered in basically no time, pretty small open world) and uninteresting story compared to previous titles.

This is just not true. Gothic 3 is still pretty alive in terms of modding and improvement precisely because the base underneath the bugginess was good. You don't have a good community after 20 years if you have bad bodybuilding and uninteresting story.

> Most players care about performance even less than they care about bugs. Basically every AAA game nowadays is criticized for piss poor performance and not having the looks to justify it. They're still massive successes.

You equal success meaning that players don't get care about bad things in a game. That's just a way to reductive view. You can literally read everywhere how people complain about the bad performance of games. Performance is a standard staple in game reviews.

> Usually, it's good code that leads to missed deadlines, not bad code. It literally takes more time and effort to write good code. Gamedev lives on 3-year cycle, that's not enough time for code debt to start causing problems.

Nice trying to put words in my mouth. This is about good and bad developers. Good developers write better code in the same or less time it would take bad developers. that's literally why they are good developers. Bad developers compound on bad code making progress exponentially slower compared to if you had good developers from the start. The question was never the same developer writing good vs bad code.

> Bad gameplay... yes, that can be actual problem. But it's rarely due to a single bad line of code, or even ten thousand bad lines of code. In most games, gameplay is bad because it was designed to be bad. As in, they had a certain way of playing in mind, and they made the game exactly how they wanted, it's just most players don't find that way of playing fun. No amount of code quality can fix that.

I think you really underestimate how much a gameplay programmer can influence the gameplay. Not every millisecond of latency is specified in game design docs. Most of gameplay is designed by feeling. If your developer is not capable of producing good gameplay your game designers can do nothing.

> Gothic 3 is still pretty alive in terms of modding

A fraction of G2's modding scene. And the reason is even after all the bugfixes and community patches, people still overwhelmingly prefer G2 over G3.

> You equal success meaning that players don't get care about bad things in a game. That's just a way to reductive view.

I equal success to financial success, because we're talking why game programmers are paid less, and the reason is (partly) because code quality has next to no impact on sales. If people still buy your hame despite the bad things about it, then it's a financial success, and game studios exploit this fact to the extreme.

> Nice trying to put words in my mouth. This is about good and bad developers.

I was replying to this part: "Besides bad code does not only lead to bugs. It can lead to bad gameplay, bad performance, missing features, slipped deadlines." My intention was that no, generally it's not true that bad code leads to missed deadlines. Slow coding, yes. Bad coding, no. Good programmers are valuable to game studios not because they can write good code, but because they write bad code faster. Which is reflected in lower salaries compared to other software products where writing good code actually matters and where salaries are higher.

> Not every millisecond of latency is specified in game design docs. Most of gameplay is designed by feeling.

Not every millisecond matters for the feeling (unless you're making a fighting game but that's why I said rarely, not never). Usually performance issues in gameplay can be masked by increasing timing windows or by the eternal excuse of git gud (usually, not always). In general, the gameplay of the vast majority of games is simple enough that with modern tools, any half decent programmer can implement any feeling the designer aims for, with varying amounts of noticable issues. Sure, there are exceptions, but exceptions don't shape salary trends.

There are plenty of examples of engine being bad, but gameplay being fun.

Working for the amount of money one agrees to is not exploitation.

That would be true if there weren't a power and information imbalance.

What would be the downside of all salaries in all corporations being pseudonymously public?

"Agrees" is doing a lot of work in that sentence. Agreeing to $100/hour because you think it's fair and agreeing to $1/hour because you're starving may both qualify, but they're quite different.

It would be prudent if you would dig a bit deeper into how unions came to be. Long story short, capitalism can easily create situations where you agree to be exploited to some degree, to avoid being exploited to another, worse, degree.

That's how local laws work. The higher jurisdiction always takes precedence over the more local one.

I'm saying that T&Cs are not like any kind of law but like a contract and they are not treated like "local law" in court.

Laws work like that because there's a hierarchy in the legal system too but that's about it for commonality.