@loke Ohhh that is interesting, lemme have a read about it~

@lanodan
> And to really hammer that nail, endianness conversion is a thing I wish programmers would get the hell out of their minds because it's pretty much responsible for byte-swap crap being written.

And how am I supposed to encode/decode data in a portable way without ever byteswapping anything?

@chjara @clacke

@lanodan @chjara @clacke But yea parser generator would be okay too, I'd support anything that would make defining canonical endianness on datastreams easy and error-free :cirnouwu:

@lanodan @chjara @clacke I'd like that to be a type error, yes, and I don't really mean it in an OOP way?

> Would you have cycles eaten away with endian-conversion at each usage?
Maybe? Endianness conversion is really just one instruction ( or zero if you are on SPARCv9 and making use of those fun load/store ASI tags :02smile: ) and languages that have that facility (e.g Ada) seem to be doing fine, performance-wise?

@clacke Some of the applications I mentioned are webapps... which is written in JavaScript...

Dunno what they are doing that they managed to expose machine endiannes but it's wild :notlikemiya:

@lanodan @chjara @clacke Eh I'd like to see it for other sequence-of-bytes <-> multibyte scalar types too honestly...

Or if your language has rich types you can define the wrapper container by yourself (e.g with generic classes or somesuch) - I'm not saying that it has to be hardcoded inside the lanugage :02lurk:

@lanodan @chjara @clacke In short, I'd like for the conversion routines to be only written in *one* place and then I can simply declare new variables without needing to remember to convert that variable again in the parser/serializer

e.g if I have a struct like:
struct a {
BigEndian<uint32_t> c1;
}

And I want to add another data into it, like:
struct a {
BigEndian<uint32_t> c1;
BigEndian<uint32_t> c2;
}

I don't want to have to not forget to add conversion calls when handling c2 :02lurk:

@clacke @lanodan @chjara And the way he does it is also misguided; the language should provide numerical types with explicit endianness tags instead of having to remember to shift-shift before parsing or whatever :02smile:

@lanodan @chjara And then you need to exchange data between the two systems and the encoding happens to use the native endianness and... :02lurk:

@yarmo aaaaa I hate that everything is going the content influenza way :notlikemiya:

Rather than "cloud-based application", say "cloudy application".
Rather than "cloud-based database", say "cloudy database".
Do that too with other cloudy services, I think it conveys the opaque, hard-to-understand nature of those things in a much, much better way~