In an algorithm class, professor introduced us to some simple search algorithms (bubble sort, selection sort, insertion sort, shell sort). He did a quite decent job and most of the students were able to grasp the code and understand the differences in those algorithms. But then he spoiled his whole lecture with one additional slide. There he proposed an optimization: Instead of using a temporary swap variable, we just could use the first array element (or the zeroth element, respectively: the one ad index 0) for doing all the swapping. We just had to document that, so that the caller would "leave the first position of the array empty", resulting in "cleaner code". And he did that in the same class where he used Big-O notation to argue about runtime complexity. But having the caller to resize the array and to shift all the elements by one position did not matter to him at all, because it was "not part of the actual algorithm".

FUCK ME IN MY INDICES.
FUCK THE GPUS IN THEIR INDICES.

I mean... I understand (roughly) why the meshes are sent to gpu in this form, but at the same time...
...there's a reason why first thing I did when I was coding my procedural geometry generation library, was abstracting away all of that stuff...

...sadly, as many useful things, when I was looking for that lib on the start of this contract, I couldn't find it. and I was like "doesn't matter, this is a simple thing, using the library would be just a lazy overkill anyway".

well, fuck.
two hours of playing around with two fucking triangles, trying to figure out which indexes are pointing to the correct vertices in a list containing FOUR outline paths.
(lower inner, upper inner, lower outer, upper outer, exacly in this order).

i mean, yeah, it's actually pretty straightforward stuff... for someone not as dumb as me =D
you just have two offsets, one that jumps you to start of the upper path, another that jumps you to the start of the outer path, then it's just
0 + upOffset to get the vertex extruded upwards from the zeroth of the inner path, or
0 + outOffset to get the zeroth from the outer outline, or
0 + outOffset + upOffset, to get the one extruded from zeroth outer vertex...

and so on.
simple stuff, then you just replace the zero with loop control var, put them in the right order, and voilá! walls!
except... whatever, why am I describing in such detail, not necessary, you're not my rubber duck =D

in short, figuring out which fuckin vertex is which, when the list contains ...well, any number of points, and you need to plug the gap between last and first points of the paths, where you need to wrap around the list...

...has proven to be surprisingly hard for me.

funny how much I love doing these things with meshes, despite how bad I am at doing them, which makes me hate doing them despite loving it =D

So to give you a feel for what evil, clusterfuck code it was in: this projects largest part was coded by a maniac, witty physicist confined in the factory for a month, intended as a 'provisional' solution of course it ran for years. The style was like C with a bit of classes.. and a big chunk of shared memory as a global mud of storage, communication and catastrophe. Optimistic or no locking of the memory between process barriers, arrays with self implemented boundary checks that would give you the zeroth element on failure and write an error log of which there were often dozens in the log. But if that sounds terrifying already, it is only baseline uneasyness which was largely surpassed by the shear mass of code, special units, undocumented madness. And I had like three month to write a simulator of the physical factory and sensors to feed that behemoth with the 'right' inputs. Still I don't know how I stood it through, but I resigned little time afterwards.

Well, lastly to the bug: there was some central map in that shared memory that hold like view of the central customer data. And somehow - maybe not that surprisingly giving the surrounding codebase - it sometimes got corrupted. Once in a month or two times a day. Tried to put in logging, more checks - but never really could pinpoint the problem... Till today I still get the haunting feeling of a luring memory corruption beneath my feet, if I get closer to the metal core of pure C.

i can't explain why, but hearing the term 'zeroth' in english really fucks with my head.

like, yeah, i'm quite used to 0-based indexing in my line of work obviously. but stuffs[0] == "the first element of stuffs" and that's what I would say when communicating verbally to the person looking at the code with me.

but like, take a use case where you are actually referring to something that precedes the first in a series, such as the number of updates on an original thing. then zeroth is indeed an accurate description, but still just rings such discord in my ear upon hearing it.

kinda like they say about 'moist' describing anything but a cake.

"Our project got cancelled."