Because 256 is exactly one byte. If you want to add a 257th member, you need a whole second byte just for that one person. That’s a waste of memory, unless you want to go to the 64k barrier of users per chat.
If each user is assigned a number as to where they’re placed in the group, I guess. But what happens when people are added and removed? If #145 leaves a full group, does #146 and beyond get decremented to make room for the new #256? (or #255 if zero-indexed). It just doesn’t seem like something you’d actually see in code not designed by a first semester CS student.
Also, more importantly, memory is cheap AF now 🤷♂️
There would be no need to decrement later people because they’re definitely referred to using pointers. You’d just need to update the previous person’s pointer to the new next person.
If it’s a numeric ID (0-255) assigned to each person in the group, you’d either need to decrement later people or assign based on some kind of lowest available method, in which case you’d get kinda funny UX when new-member-Jerry can be #3 on the list because he’s taking over for old-member-Gerry, or he can be #255 because that’s the last spot.
If we’re talking about pointers, I assume you mean a collection with up to 256 of them. In which case, there are plenty of collection data structures out there that wouldn’t really have a hard limit (and if you go with a basic array, wouldn’t that have a size limit of far more than 256 natively on pretty much any language?)
Memory and network stop being cheap AF when you multiply it by a billion users.
And Whatsapp is a mobile app that’s expected to work on the crappiest of networks and connections.
Because 256 is exactly one byte. If you want to add a 257th member, you need a whole second byte just for that one person. That’s a waste of memory, unless you want to go to the 64k barrier of users per chat.
If each user is assigned a number as to where they’re placed in the group, I guess. But what happens when people are added and removed? If #145 leaves a full group, does #146 and beyond get decremented to make room for the new #256? (or #255 if zero-indexed). It just doesn’t seem like something you’d actually see in code not designed by a first semester CS student.
Also, more importantly, memory is cheap AF now 🤷♂️
While I completely agree with the sentiment, snorting too much “memory is cheap AF” could lead to terminal cases of Electron.
There would be no need to decrement later people because they’re definitely referred to using pointers. You’d just need to update the previous person’s pointer to the new next person.
If it’s a numeric ID (0-255) assigned to each person in the group, you’d either need to decrement later people or assign based on some kind of lowest available method, in which case you’d get kinda funny UX when new-member-Jerry can be #3 on the list because he’s taking over for old-member-Gerry, or he can be #255 because that’s the last spot.
If we’re talking about pointers, I assume you mean a collection with up to 256 of them. In which case, there are plenty of collection data structures out there that wouldn’t really have a hard limit (and if you go with a basic array, wouldn’t that have a size limit of far more than 256 natively on pretty much any language?)
Memory and network stop being cheap AF when you multiply it by a billion users. And Whatsapp is a mobile app that’s expected to work on the crappiest of networks and connections.
It is also used to transmit data including video. I don’t think an additional byte is noticeable on that kind of scale