▲ 70 points
back
84 comments
Have a look at the date of the document... although the content is serious, the way it's discussed might be a bit in the line of these: https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C...
Who needs CSS for justified text when you can just do it 1980-style monospaced justification? This makes me happy, and I have no idea why.
Read it from a tiny screen, you will realise why it is a bad idea.
Reading from a tiny screen being the root bad idea.
I remember using physical screens that only had 64 or even 40 columns. (A printout was more practical for reading anyway. Just tolerate a few minutes of dot-matrix noise.)
It wasn't meant to be read from a screen. (A browser doesn't show the Form Feed character at each page number.)
I think that more than the font being monospace it is that the font is a good font with high contrast rather than whatever thin and light gray font that many sites use to look fancy.
For +90% of web sites I read I only need a "fix font" for the body text and not a full "reader" version of the page.
This tom7 video might also make you happy then: https://www.youtube.com/watch?v=Y65FRxE7uMc
Probably because it just works, simply. Whereas with the complexity we have today we can barely align things consistently; it's almost comedy
Tip for those with mobile issues: rotate to landscape and the words get bigger ;)
I hate it so much, full of wrong linebreaks. I don't need typewriter or dot matrix compatibility.
> Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. —SKB
That reads like an XKCD alt-text.
(That would've been RM; SKB is Stan Kelly-Bootle)
It's actually somewhat of a reality in some image processing code, and some people feel really passionate about whether the topleft corner pixel is located at (0.5,0.5) or (0,0).
Direct3D made this a thing. Trying to draw unscaled 2D elements you often end up with blurry images as it bilinearly filters with the neighbouring pixels.
This is because of a mess with where it considered pixels located, where texture samples are considered located, and where, when rasterizing an included pixel, the texture coordinates sampled. See detail at [0].
If your graphics API was blurring all your images, you'd be passionate about that half-pixel offset too.
[0] https://www.gamedev.net/blogs/entry/1848486-understanding-ha...
The center of the pixel is at 0.5 but the top left of the pixel at the top left is 0. And the bottom right of the top left pixel is at 1.
Pixels are point samples, they do not have corners, they are not little squares. [1]
Funnily enough, I actually wrote code that does that very thing this morning.
xkcd did reference it in https://xkcd.com/394/
To this day I think that article mixed up the terms, causing confusion ever since.
"Little-endian" to me implies that the least significant byte of a word is at the end of a byte sequence, but it's the other way round.
I understand that it's from Gulliver's Travels where it's about which end to start breaking an egg from - but without knowing this you can easily end up getting this wrong.
Natural languages...
The word "End" can also mean any "extremity" and not just the opposite of "beginning". Otherwise phrases "on both ends of the spectrum" wouldn't make sense.
Thus, a positional encoding of a number has one side (end) where the impact of digits is much higher (big) than the other side (end) where the impact is lower (little).
Little end: the side with lower "weight" Big end: the side with higher "weight"
Being "little endian" is a property of the encoding or architecture, not the property of the word. The word is not "little endian", i.e. its "end" is not "little". The encoding is little endian in that it starts with the little end of the word. You're rightly confused because the fact we're now suddenly talking about the start of the word is implicit and based on the assumption that the reader knows Gulliver's tale.
You're doubling down on the ambiguity and thereby proving the point.
If end means start, then why use this word?
Little endian is in reality little startian and big endian is big startian.
In fact, we could simplify this even further and just call big endian, startian and little endian, just endian.
You're right it's ambiguous. It's a playful reference to a piece of literature.
It's also quite an old terminology which is not going to change.
If we could come up with a new terminology from the start we could find better options.
For example:
* Least/Most Significant First (LSF / MSF) * Low/High Address Least Significant (LALS/HALS)
Etc
It was / is a very straightforward question. Given this C fragment:
u16 x = 1;
u8 * px = (u8 *)&x;
int* x; // x is an int-pointer
int *y; // dereferencing y gives an int
int * z; // int multiplied by z
(For the record, the second way is the universal and objective truth.)
But when you say "the second way" are you counting from zero or from one?
Given the context, you've got to wonder if the ambiguous terminology was deliberate.
While I prefer to crack my eggs from the little end, I insist on big-endian byte order. Sadly, modern CPUs are mostly made by barbarians (i.e. Little-Endians).
I actually did a writeup on this: https://www.technicalsourcery.net/posts/on-endianness/
TLDR: Little endian is better for most data situations (and incidentally is a more natural ordering for humans), so it's good that it won out in the end.
The writeup does not convey a consistent message on "naturalness"... The normal way numbers are written in most or all of the world is big-endian so obviously that is the one that would be found "natural" to most people, regardless of whatever perceived advantages going little-endian has. Furthermore, number names in every language I know of start with the biggest units. The direction of writing does not matter so much as the direction of reading. Anything other than big-endian would require readers to skip around in text to actually say the name of a number in a sentence.
What we consider "natural" now is not what was originally considered "natural" during the early centuries of the Hindu-Arabic numerals' journey.
In fact, we can still see the vestiges of the "low order digits first" convention in some languages even today (for example, in German). Even Greek numbers underwent reversals in the early years (earliest known evidence circa 4th century BC).
That still doesn't imply "naturalness". Quite the opposite. It implies that both are natural since both are adopted and both have been switched to after previously adopting the other.
Remember, too, that most people consider every system that they learn first as "natural". Like it's equally true that historically people did not select base 10 very often. Base 12 and base 60 were both popular as well if they're even using positional numbering at all. Nevermind how long we went in positional numbering without a zero. Is zero then unnatural? I think it must be. Is "naturalness" even virtuous then?
Well, the bits jump around.. bytes are ordered, but the bits aren't, with LE (between bytes) so there's always room for a never-ending discussion about what's best ("Are you a bit person? Or a byte person? Then your preferences may differ"). The best argument for LE would be that a processor like e.g. the 6502 could start processing the least significant byte while fetching the most significant byte, and that on a VAX you could pass a 4-byte integer to a Fortran function expecting a 2-byte integer and it would actually work (as long as the value was > 65536). That was actually done a lot back in the day.. and created problems when recompiling the Fortran code for a BE architecture.
I had another look at the actual article/RFC: This is more than just the little endian/big endian byte order, it's about the bit order of serial messages, where, unlike bytes, the bit order could actually be different (for bytes stored in memory the bits of each individual byte in modern / semi-modern computers are always stored in the same order whether it's a LE or a BE memory architecture). In a serial protocol you could send the most significant bit of the stream first, or the least significant bit first, and that's what's at first discussed in that RFC.
LE is easier to handle, BE is easier to read.
Brilliant write up!
I do not really understand the "Sorting unknown uint-struct blobs" point.
Could you give an example or explain in more detail, what a "unknown uint-struct blob" is?
The odd/even advantage could be put even stronger, because every additional bit you know from the little end gives additional information about the number's divisibility. For example, one bit tells divisibility by two (aka ofd/even), two bits tell divisibility by four, and so on.
For example, if you had a file that comprised the following struct:
struct someblob {
uint64_t timestamp;
uint64_t checksum;
uint32_t item_count;
struct something items[0];
};
It's a very minor benefit (of dubious real-world utility), but I wanted to be comprehensive :P
Silly aside: I didn't read the book and was very confused for a long time since I assumed endian meant the specified byte goes last.
Little End In (first) == little endian.
It may be a handy mnemonic, but it's not the etymology (you may know this, but I can't resist the pedantic opportunity!)
It comes from Swift's satire about egg eaters. The end in question was the small or large end of the egg and Big Endians broke the big end with the spoon - i.e. it went into the egg cup small end down.
The -ian suffix here is analogous to Christ-ian or Keynes-ian and has nothing to do with "in".
I think most industry wire protocols are still big endian.
Yes, the so-called "network byte order". Now that big-endian has lost on all other fronts, it is time to switch to little-endian in all future network protocols. We could call it the krowten byte order.
Lmao, this has raw actual-ANSI-control-code 000C <control> = FORM FEED (FF) in the text.
^L is still normal as a separator in Emacs Lisp code files!
TECO (and thus Emacs) supported a commands like "read page" which turned into movement by page in Emacs, which is why ^L shows up in Emacs Lisp (and sometimes similar vintage code)