Negitivefrags

I think the reason is much more simple.

It's very hard to improve something that you don't understand yourself. All the tiny decisions you make as you create a product are informed by the experience you have.

So it's seems obvious to me that a product created by software engineers would be better at software engineering. A programmer knows what a programmer needs.

To improve another industry successfully, you would really need people from that industry to be involved in a deep level in the design of the product.

And if you thought that was ridiculous, consider that the "best" implementation is the SQL database it wrote in PHP.

All that info is out there. The one that thrusts backwards is 200 litres at 10,000 PSI and takes up all your boot space.

https://cdn.discordapp.com/attachments/691843612950003743/15...

The one that thrusts downwards removes the front passenger seat for another 400 litre tank. I don't think there are any pictures of that though.

I personally would find it scary sitting next to a huge 10,000 PSI pressure vessel but there you go.

They will not attempt to make it legal to use on normal roads, but intend to try and certify it to be in a road legal car but only usable while not on the road.

It also takes like 6 hours to fill and can be used one time per fill for a single use. It's a party trick for sure.

You can’t just yolo an MMO with unreal engines server. Not unless you want your MMO to have a max of about 60 players in the world.

You need to write you own version of all that stuff and effectively just use UE as the graphics engine.

People may be different, but that doesn’t mean we should accept it all the time.

I hate exercise. Like I really really really hate it.

Should I just accept this and live a life without it?

I don’t think it’s such a stretch to say that socialisation is similar.

You might have delivered 10x more code, but did you deliver 10x more value?

Or put another way, are you making 10x more money?

It's easy to spend excess productivity effectively wasting time. Most companies did it before AI, and will continue doing it after.

It's easy to believe you are not wasting time because you have more bugs fixed or more features delivered, but if it doesn't move the bottom line, what is the point?

I suspect that the conditions the textile workers lived in when western countries were creating textiles is not so different in absolute terms from the condition that they live in now.

It's just that the western world moved on.

Almost all economies that have developed have started with textiles. This is the starting point on the ladder. Eventually, we will run out of poor countries that haven't had a textile industry yet, and at that point, either it will be entirely automated, or we will no longer have cheap textiles!

But I'm betting on the automation.

I'm really bothered by the mindset of the people against this. People act like induced demand is evil.

In reality, if more people were able to go wherever they wanted to go, that's actually a good thing regardless of if the existing people didn't get to go somewhere faster.

If you look at the actual source linked in the article it contridicts you.

"Other" in that document means custom game engines.

This is not what the “exception that proves the rule” means.

If a sign says “No parking on saturdays”, that is an exception that can be used to infer the rule “parking here is okay the rest of the time”.

This has been the case for software since the very beginning. And people have been complaining about it since the beginning. See the Free Software Foundation.

I am not a fan of this take.

It's possible to not make an engine, or use a 3rd party engine. You just make a game. Use SDL or something. It's honestly easier and more fun. Definately don't use Rust.

It doesn't take two years.

The more you focus on making gameplay, and not making an engine the better. Which sounds like similar advice to "use an existing engine", but it's not, because using existing engines is also a pretty sad time. You can waste just as much time farting around in Unreal as you do making your own engine.

At the end of the day, most people are just not serious about making a game. Using someone elses engine, building from scratch, both will work if you are actually making a game and not just wasting time.

When the author said “bringing work home” they didn’t mean literally working at home.

They meant that they spend a huge amount of time feeling stressed about work situations at home.

I get the sentiment, but it's possible to go too far with the "It's always the process's fault" direction.

It's trendy in buisness culture right now to erase the individual. Zero accountability can also mean zero growth. I don't think it's honestly the most enjoyable situation to be in.

> The way this position conforms to the interests of the capital class, and conflicts with those of the labor class, is a red flag.

If being in the office conforms to the interest of the capital class, it implies that WFH is inherently less efficient.

This is one of those things that I often find strange with work from home advocates. They seem to imply that business owners just want employees to suffer as a goal in itself.

People haven’t responded to your very first point, and I want to really stress it because I don’t think most people really get it.

Margins.

Game development doesn’t pay more because game development companies can’t afford to pay more.

Sure, an individual game dev company may make a lot due to the hit driven nature of the field, but the totality of the market simply makes less money per developer than big tech does.

In order for that to change, the market has to increase in size by appealing to a more casual audience, or existing gamers have to pay more. Not something I think most gamers would like. And these are the people who the workforce of game developers form from.

> But most employers don't go around reducing previously-hired people's salaries for a variety of reasons.

The main reason being that it's illegal in NZ. The employee would have to agree.

> I guess the question is, since we know these things can happen, however unlikely, what mitigations should be in place that are commensurate with the harms that might result?

This isn't a defence of using LLMs like this, but this statement taken at face value is a source of a lot of terrible things in the world.

This is the kind of stuff that leads to a world where kids are no longer able to play outside.

Yes, there are a large number of ways to fall into traps that cause you to do a different series of operations when you didn't realise that you did. But that's still ultimately what all your examples are. (Except the NaN thing!)

I still think it's important to fight the misinformation.

Programmers have been conditioned to be so afraid of floats that many believe that doing a + b has an essentially random outcome when it doesn't work that way at all. It leads people to spend a bunch of effort on things that they don't need to be doing.

This is the kind of misinformation that makes people more wary of floats than they should be.

The same series of operations with the same input will always produce exactly the same floating point results. Every time. No exceptions.

Hardware doesn't matter. Breed of CPU doesn't matter. Threads don't matter. Scheduling doesn't matter. IEEE floating point is a standard. Everyone follows the standard. Anything not producing indentical results for the same series of operations is *broken*.

What you are referring to is the result of different compilers doing a different series of operations than each other. In particular, if you are using the x87 fp unit, MSVC will round 80-bit floating point down to 32/64 bits before doing a comparison, and GCC will not by default.

Compliers doesn't even use 80-bit FP by default when compiling for 64 bit targets, so this is not a concern anymore, and hasn't been for a very long time.

Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.

This is true for any kind of transformative technology. Marketing and lobbying can only get you so far. If something has enough utility, it will be used regardless of what people say they want.

That is a way better syntax. I wonder why C++ didn't adopt it.

We use floating point operations with deterministic lockstep with a server compiled on GCC in Linux a windows client compiled with MSVC in windows, and an iOS client running on ARM which I believe is compiled with clang.

Works fine.

This is a not a small code base, and no particular care has been taken with the floating point operations used.

I’m curious how you would respond to the arguments in this video.

https://youtu.be/9KJTWmRrneo?si=I9mvSPfDnhkckb9n

Can we get an Amen quicksort now?

I've written a lot of code using that method, and never had any portability issues. You use types with number of bits in them.

Hell, I've slung C structs across the network between 3 CPU architectures. And I didn't even use htons!

Maybe it's not portable to some ancient architecture, but none that I have experienced.

If there is undefined behavior, it's certainly never been a problem either.

And I've seen a lot of talk about TLB shootdown, so I tried to reproduce those problems but even with over 32 threads, mmap was still faster than fread into memory in the tests I ran.

Look, obviously there are use cases for libraries like that, but a lot of the time you just need something simple, and writing some structs to disk can go a long way.

Why is it such a terrible idea?

No need to add complexity, dependancies and reduced performance by using these libraries.

Well our game runs faster in DX12 under Proton than Vulkan under Proton.

Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.

I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.

Support for DX12 under Proton in linux is incredibly good. Some games actually run faster under DX12 in Proton than the native versions do.

The reason you use DX12 in a new project is so that you can get good linux support.

I'm making a joke, but it's also true.