Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Volte: Oct 4, 2004; woosh woosh

pokeyman posted:

The post I quoted was describing how Unity null checks are not compatible with regular C#. Assuming it's accurate, Unity already made their own bespoke version. Maybe they should fix it instead of begging Microsoft.

It's just an overridden Equals method on UnityEngine.Object, you can do the same in your C# code base

# ? May 7, 2022 03:07

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 21:46

Jazerus: May 24, 2011

the real horror question here is this: can you override unity's method override into something sane, or does the entire engine break if you do

# ? May 7, 2022 03:12

dwazegek: Feb 11, 2005; WE CAN USE THIS

pokeyman posted:

Wait, so Unity uses C# but is not able (allowed? willing?) to make any changes to the compiler or language or runtime? That's so weird. Fork it you cowards.

Going from memory here, but it wasn't so much that they wanted to fork the compiler or anything like that. They wanted the actual c# spec to be changed to allow for their weirdness.

That said, even if they created their own compiler, they'd then potentially have to recompile the entire .NET runtime and all 3rd party packages in order for it to actually work. Take something like this:

code:

public static void DoSomethingIfNotNull(IDoSomething x)
{
  x?.DoSomething();
}

If that method was compiled using any compiler that followed the c# spec, `DoSomething` would only be called on `x` if `x` is an actual, for real, null reference (i.e. object.ReferenceEquals(x, null) returns true). They could write their own compiler that would have that code work using their incorrect interpretation of null-ness. However if that method lives in an assembly they didn't compile, it would still do the correct thing, rather than what they want.

As a side note, if their goal was to simplify checks for valid objects, they could've just written an extension method on `UnityEngine.Object` that does both, e.g.

code:

public static bool IsValid(this UnityEngine.Object obj)
{
  return obj != null && !obj.IsDestroyed();
}

As far as I can tell, this would've side-stepped basically every major problem their equality implementation has.

# ? May 7, 2022 08:50

Xarn: Jun 26, 2015

Making a stupid design decision and then being forced to keep it due to backcompat is classic language design thing, so I can't be really mad.

# ? May 7, 2022 09:27

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

Here's their reasoning for keeping it: https://blog.unity.com/technology/custom-operator-should-we-keep-it

They also let you implicitly cast UnityObjects to bools to make your C# code positively C-like:

code:

GameObject obj;
if (obj)
{
	...
}

# ? May 7, 2022 09:36

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Ranzear posted:

Unity considers it normal behavior to not be checking, and so do I for shifted casts and doing weird bit twiddlng stuff that does come up in gamedev contexts, but the context was someone using float-to-int casts as a way to truncate which may have been compound horror. I always called it the NaN Plague in javascript, where everything at least stays NaN to make it obvious, but C# has the same NaN propagation issues and then this weird cast behavior can hide it.

checked as a block is neat though. I don't see it being too different from an overt NaN check, but it's something at least. There's a compiler directive to force it everywhere and apparently unchecked is a thing, which would be a much more verbose and intentional approach, but there claims to be some small performance penalty with it too (~5%).

I'm truly willing to admit my opinion of C# is entirely colored by Unity's bastardization of it, but to be fair it's also a classic Microsofting of some nice features with a lot of really bad features. Mono getting quietly bought up by MS through a half dozen umbrella transactions to kill the indie side of it is a red flag too. My personal opinion of C# is that it's the perfect language for people who don't know any better or care enough to be convinced why they should. It's the Charcoal Gray V8 SUV Daily Commuter of programming languages (and go figure the morning horde of those mostly take the SR 520 East exit).

Also, Godot adopting C# seemed like desperation to me, trying some 'how do you do fellow devs' to drag some attention over from Unity.

I don't do game development so I guess I don't really have a common perspective with you on this stuff.

I've been doing C# on and off for 8 years and your post was the first time I learned that (int)double.NaN results in int.MinValue. I guess I don't understand why the language designers decided that behaviour should be dependent on whether you're in a checked or an unchecked context, and yet integer division by zero should result in an exception in either context. That said I also don't understand why you wouldn't be checking for NaN or for infinities if you are being given a floating-point number of unknown provenance (but it's of more lasting importance for the language designers to make good decisions than it is for Johnny Q. Gamedev or Jimmy R. Enterprisedeveloper to do it).

I don't write code where performance is of crucial importance so that isn't something I consider; I think at my work we should probably be requiring checked arithmetic by default in all the projects we do, however we don't. The only time I ever write checked or unchecked is when implementing GetHashCode(), that's the main use of unchecked as far as my experience of the language is concerned.

As to C# being a great language for people who don't know better... I guess I don't know better then?

It is, in my experience a lot more difficult to shoot yourself in the foot than either C++ or Python* and is a lot more "batteries included" than the former... particularly if you write line-of-business software.

* the set of ways in which you can easily shoot yourself in the foot in C++ but not C#, and the set of ways in which you can easily shoot yourself in the foot in Python but not C#, are almost entirely disjoint

SupSuper posted:

Here's their reasoning for keeping it: https://blog.unity.com/technology/custom-operator-should-we-keep-it

They also let you implicitly cast UnityObjects to bools to make your C# code positively C-like:
code:
GameObject obj;
if (obj)
{
	...
}

That's not at all an idiomatic thing to do in C# world so I don't think it's much of a plus.

# ? May 7, 2022 13:28

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Jabor posted:

Also they've managed to end up with an == implementation that isn't transitive, so that's really fun to have to reason about.

that's interesting but as someone whose understanding of the issue is limited to what's been explained in the last couple of pages of this thread it's not obvious to me. can you go into more detail? I would like an example of an x, y and z such that x == y && y == z && x != z

# ? May 7, 2022 13:31

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Suppose x and y are two different objects, both of which have had their underlying native object destroyed.

then x == null, and null == y, but x != y.

# ? May 7, 2022 13:34

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Oh, ok. I guess I assumed that if two objects were both destroyed/invalidated/whatever it is, they would compare equal to one another. But that's not how it works, comparison to null is a special case.

# ? May 7, 2022 13:42

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

But that's not something that's happened recently, then.

There was a post saying how they've increasingly over time recognized that the decision to treat null specially has had bad consequences, as the language has sprouted new features like ?? and ?.

But the non-transitive == is something that was in there from day one and should have been enough on its own to make them realise "actually, that's a bad idea, let's not do that".

I always write "x is null" not "x == null" in the C# I write these days anyway.

# ? May 7, 2022 13:50

hyphz: Aug 5, 2003; Number 1 Nerd Tear Farmer 2022.

Keep it up, champ.

Also you're a skeleton warrior now. Kree.; Unlockable Ben

Weird thing I found in Unity is that you can replace the compiler .exe with any compiler that outputs CIL and it won�t care what�s in your scripts. So you can stick the Oxygene/Silver compiler in there and code Unity in that.

# ? May 7, 2022 16:10

Ranzear: Jul 25, 2013

Hammerite posted:

As to C# being a great language for people who don't know better... I guess I don't know better then?

Maybe, but you're also perfectly aware of the parts that aren't great. Also you (likely) get paid to do it, versus novice/indie game devs who are just approaching their first "real" language after finishing a few python tutorials :smug:

(partly a joke, partly witness to someone's actual unironic perspective)

Unity-integrated C# is fine in the same way that PHP is fine. There are trappings and bullshit and nonsense galore but those who know their way around the jank can do cool stuff just the same as any other language.

hyphz posted:

Weird thing I found in Unity is that you can replace the compiler .exe with any compiler that outputs CIL and it won�t care what�s in your scripts. So you can stick the Oxygene/Silver compiler in there and code Unity in that.

I think this was something required for getting Photon builds out of the Linux Unity editor. Also I submit to the thread: Photon, the multiplayer server for Unity that apparently only runs in a Windows GUI. There is 'allegedly' a headless option but it requires some build script they email to you on ask?

# ? May 8, 2022 00:53

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

Ranzear posted:

Mono getting quietly bought up by MS through a half dozen umbrella transactions to kill the indie side of it is a red flag too.

Unless I'm missing something here, It was one transaction, Xamarin. And that wasn't quiet, it was well known at the time what they bought.

And while the Mono repo itself (as a standalone project) is now mostly on ice, all of that code got merged back into .NET proper. https://github.com/dotnet/runtime/tree/main/src/mono. So I wouldn't say it "killed the indie side" unless you really don't want to run something with the Microsoft name.

# ? May 9, 2022 04:16

Volte: Oct 4, 2004; woosh woosh

The need for Mono in general (as an open source .NET implementation) was kind of mitigated by the introduction of .NET Core, and Unity supports Roslyn as a backend compiler (via IL2CPP) now so Mono isn't even strictly necessary there in most cases. In any case, Unity uses their own fork of Mono, which is of course open source, so Microsoft can't in fact buy Mono and kill anything about it. What they did buy is Xamarin, the company that was primarily developing Mono and its commercial implementations for iOS and Android. And for what it's worth, they made those implementations free when they bought it when they used to be very expensive licenses, so "killing the indie side" seems like the exact opposite of what they did.

# ? May 9, 2022 04:54

ExcessBLarg!: Sep 1, 2001

I'm not particularly into C# or Microsoft technology stacks, but my impression of the Xamarin purchase and .NET Core is that it was C#'s "OpenJDK moment", which is to say it'll all a good thing.

# ? May 9, 2022 14:20

BigPaddy: Jun 30, 2008; That night we performed the rite and opened the gate.
Halfway through, I went to fix us both a coke float.
By the time I got back, he'd gone insane.
Plus, he'd left the gate open and there was evil everywhere.

I spent a few years doing C# dev a while ago and it was fine. The problem with the project I was on was the lead developer just abstracted things out to insane levels, like 7/8 deep at times and also was trying to run a windows server with the Sitecore CMS on a VM with 2 CPUs and 4GB of memory. He eventually left and we had to deal with the abstraction distractions but I was able to get the processors and memory bumped up on the VMs as well as pointing out that you need your load balanced edge servers to be able to cover 100% of the load one server would get so if one failed you would not get service degradation. Lots of �why do we need to pay for machines that are only working at 45% capacity?� Going on.

# ? May 9, 2022 14:27

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

Volte posted:

The need for Mono in general (as an open source .NET implementation) was kind of mitigated by the introduction of .NET Core, and Unity supports Roslyn as a backend compiler (via IL2CPP) now so Mono isn't even strictly necessary there in most cases. In any case, Unity uses their own fork of Mono, which is of course open source, so Microsoft can't in fact buy Mono and kill anything about it. What they did buy is Xamarin, the company that was primarily developing Mono and its commercial implementations for iOS and Android. And for what it's worth, they made those implementations free when they bought it when they used to be very expensive licenses, so "killing the indie side" seems like the exact opposite of what they did.

It's been awhile now, but the original release of .NET Core was also a break from Framework and removed a bunch of APIs from it. That effort started before Xamarin was acquired. After it was, many on the Mono team said that "you can't break like that and expect people to port." so 2.0+ started adding back APIs and takebacks from 1.0 and started the process of merging the Mono VM directly into the runtime to support things CoreCLR can't (Like WASM and Mobile). Also remember that once Xamarin was acquired, those were all made open source too! Before, you had to pay.

# ? May 9, 2022 16:04

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

BigPaddy posted:

I spent a few years doing C# dev a while ago and it was fine. The problem with the project I was on was the lead developer just abstracted things out to insane levels, like 7/8 deep at times and also was trying to run a windows server with the Sitecore CMS on a VM with 2 CPUs and 4GB of memory. He eventually left and we had to deal with the abstraction distractions but I was able to get the processors and memory bumped up on the VMs as well as pointing out that you need your load balanced edge servers to be able to cover 100% of the load one server would get so if one failed you would not get service degradation. Lots of �why do we need to pay for machines that are only working at 45% capacity?� Going on.

You can write bad code in any language and you can write good code in any language. The question is whether the language helps or hinders you in the objective of writing good code. I'd argue that C# is pretty good about avoiding footguns, and they implement new language features in a more or less sane way that avoids breaking changes. Although it certainly means there is keyword over-reuse, since they don't want to break existing code by introducing new keywords.

# ? May 9, 2022 16:24

D34THROW: Jan 29, 2012; RETAIL RETAIL LISTEN TO ME BITCH ABOUT RETAIL

I want to see what's considered "good code" in brainfuck :allears:

# ? May 9, 2022 16:26

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

D34THROW posted:

I want to see what's considered "good code" in brainfuck

My personal favorite is J, although J is used by code golfers a lot. But it genuinely looks like a cat walked across a keyboard, yet it generates correct results.

quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

...ok, sure

# ? May 9, 2022 16:29

Macichne Leainig: Jul 26, 2012; by VG

Gesundheit

# ? May 9, 2022 16:38

BigPaddy: Jun 30, 2008; That night we performed the rite and opened the gate.
Halfway through, I went to fix us both a coke float.
By the time I got back, he'd gone insane.
Plus, he'd left the gate open and there was evil everywhere.

New Yorp New Yorp posted:

You can write bad code in any language and you can write good code in any language. The question is whether the language helps or hinders you in the objective of writing good code.

I agree and would add that using the correct language for the job it was designed for is also important. However since the most commonly used languages are fairly similar in functionality but there are still times you would want to say use Clojure for certain tasks rather than doing it in JavaScript.

# ? May 9, 2022 16:39

Doom Mathematic: Sep 2, 2008

This is a few years old apparently but I didn't know about it until it showed up on Twitter the other day.

https://twitter.com/chordbug/status/1523016806348304385

https://www.youtube.com/watch?v=bydMm4cJDeU

# ? May 9, 2022 18:53

chglcu: May 17, 2007; I'm so bored with the USA.

New Yorp New Yorp posted:

You can write bad code in any language and you can write good code in any language. The question is whether the language helps or hinders you in the objective of writing good code. I'd argue that C# is pretty good about avoiding footguns, and they implement new language features in a more or less sane way that avoids breaking changes. Although it certainly means there is keyword over-reuse, since they don't want to break existing code by introducing new keywords.

Going back to Unity - I think that's still why we're talking about C# - I think the language, coupled with some specifics of Unity's implementation, is actually a hinderance to writing good game code.

For one thing, you have to be very careful about generating garbage, or else you're going to have hitches due to their crappy GC. They've done some work on this recently, but I'm not sure how much it alleviates the problem. In my experience, it means you can't write C# like you normally would in an application since so many things perform heap allocations.

Also, the split between reference types and value types makes writing cache friendly code difficult. This is more important for games dealing with large numbers of things to process, but being unable to control allocation patterns of reference types means using classes can be problematic. If you instead use structs, you run into various problems due to gotchas when working with structs in the language. Unity's ECS and DOTS stuff is intended as a fix for this, but that's been in dev hell for a while, and still was last time I checked. It's also a very unnatural way to write C#.

I would personally prefer Unity using something like C++, since controlling memory is fairly important to writing high performance games, but C# is also one of their big selling points and the lack of support for the language is also something complain about when trying to use Unreal.

# ? May 9, 2022 18:55

Rottbott: Jul 27, 2006; DMC

I normally prefer C++ to C#, but I find Unreal's crummy version of it miserable to use. I'd rather use Unity's weird C# over that crap.

# ? May 9, 2022 20:07

more falafel please: Feb 26, 2005; forums poster

Rottbott posted:

I normally prefer C++ to C#, but I find Unreal's crummy version of it miserable to use. I'd rather use Unity's weird C# over that crap.

The key to UE4 is to fully embrace the weird Unreal C++ stuff. It's so much better than it was in UE3.

# ? May 9, 2022 20:22

BigPaddy: Jun 30, 2008; That night we performed the rite and opened the gate.
Halfway through, I went to fix us both a coke float.
By the time I got back, he'd gone insane.
Plus, he'd left the gate open and there was evil everywhere.

I am guessing all the comments about Cryengine will turn up eventually but is currently lagging out due to the net code.

# ? May 9, 2022 20:25

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Doom Mathematic posted:

https://twitter.com/chordbug/status/1523017201670045696

# ? May 9, 2022 20:52

CPColin: Sep 9, 2003; Big ol' smile.

This algorithm is not a place of honor

# ? May 9, 2022 20:57

D34THROW: Jan 29, 2012; RETAIL RETAIL LISTEN TO ME BITCH ABOUT RETAIL

The Something Awful Forums � Discussion � Serious Hardware/Software Crap � The Cavern of COBOL � Coding Horrors: This algorithm is not a place of honor

# ? May 9, 2022 21:06

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

D34THROW posted:

The Something Awful Forums � Discussion � Serious Hardware/Software Crap � The Cavern of COBOL � Coding Horrors: This algorithm is not a place of honor

# ? May 9, 2022 21:08

Doom Mathematic: Sep 2, 2008

It does at least work in place, and has predictable worst-case running time.

# ? May 9, 2022 22:08

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

ultrafilter posted:

https://twitter.com/chordbug/status/1523017201670045696

write a failing test first ✅

# ? May 9, 2022 22:43

lifg: Dec 4, 2000; <this tag left blank>; Muldoon

I like when science is about asking �how can this be worse?�

# ? May 9, 2022 23:25

Rottbott: Jul 27, 2006; DMC

ultrafilter posted:

https://twitter.com/chordbug/status/1523017201670045696

This is bubble sort with some missing boolean and break logic, on first glance. It's just doing the 'worst case behavior' all the time.

# ? May 10, 2022 02:04

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Look at the actual comparison it's doing. It isn't actually bubble sort.

# ? May 10, 2022 02:07

Ranzear: Jul 25, 2013

I meant to quote the video because that's more what I glanced at. After coffee: Yeah, I'm dumb. It's not really.

The operator direction doesn't look too weird to me because the 'hot' side of the comparison is the outer loop instead of the inner, if that makes sense?

# ? May 10, 2022 02:35

Volte: Oct 4, 2004; woosh woosh

I guess if it does a swap in a 'wrong' direction at (i, j) then (j, i) will eventually come back up and undo it, so it's like a really stupid bubble sort that can undo its own mistakes.

# ? May 10, 2022 02:35

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 21:46

Ranzear: Jul 25, 2013

Yeah, my thinking is still that it's doing bubble sort in a weird inverted way, where the carried value is getting swapped every time and happens to be left in a correct place when a new carry is found.

# ? May 10, 2022 02:37

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »