Re:Aztec monks with 1/55 HP no longer die when picking up or...
by bombolo on Saturday April 15, 2023 @05:33AM
(#35579030)
Because you can't make your own types that work better.
[ Parent
| on HN ]
Re:Aztec monks with 1/55 HP no longer die when picking up or...
by hgsgm on Saturday April 15, 2023 @07:22AM
(#35579586)
Of course you can. You just can't use operators for them.
Unless you go Haskell where anything can be an operator name, operators are just a minor convenience hack .
Re:Aztec monks with 1/55 HP no longer die when picking up or...
by bombolo on Saturday April 15, 2023 @11:03AM
(#35581248)
So you can but you need to rewrite everything instead of just changing a type, and the code will look completely impossible to read.
Re:Aztec monks with 1/55 HP no longer die when picking up or...
by DaiPlusPlus on Sunday April 16, 2023 @12:23AM
(#35587252)
And now all your simple scalar values need to exist on the heap as class object instances - and will incur plenty of runtime allocation costs for every arithmetic operation - or try to risk it with non-immutable heap-allocated objects, but that’s a recipe for disaster: no-one should ever think mutable shared state is a good first-design.
A lot of Java/JVM’s design decisions made sense in the mid-1990s, such as not supporting user-defined stack-allocated value-types and only supporting GC-managed objects - as main-memory was fast-enough compared to CPU registers - and many/most Java targets didn’t have any kind of CPU data cache - the idea of using the heap for basically everything wasn’t a bad design… back then. But now it is: high-perf code for the CLR means eliminating unnecessary GC allocation wherever possible - but in the JVM that isn’t possible.