Hacker News Reader

Comment by joe-collins | Hacker News Reader

Even if someone doesn't need to work at a sufficiently low level as to need that information regularly, not knowing that suggests a severe lack of fundamentals and hints at trouble on the horizon. Someone could play at chemist and work with raw materials and follow recipes without knowing about electron orbitals, but without that understanding they may make disastrous choices if given insufficient oversight and their capacity for problem solving is limited.

View on HN

> not knowing that suggests a severe lack of fundamentals and hints at trouble on the horizon

Exactly this. Strictly speaking you really don't need to know how many bits are in a byte, but it'd be difficult not to have picked up this kind of information having spent any time in the field. The absence of this knowledge is a strong indicator of shallow expertise.

I knew the answer, but that's because I learned it as a kid. I've never seen bits or bytes mentioned in resources for learning high level languages, nor has the topic ever come up in a professional setting.

For a professional dev in a high level language, this basically is a useless piece of trivia. It doesn't hint at trouble, because my code runs on machines that measure memory in gigabytes or at least hundreds of megabytes. Gatekeeping.

I'm sorry to disappoint you, but the so called high level languages like Python or Java are perfectly capable of working with bits and bytes, and countless developers have done so.

The gatekeeping card won't fly here. This is not some obscure implementation detail of C/C++.

I know they can work with bits and bytes, but your average web dev often doesn't get into that kind of stuff. I don't need the bitshift operator to put a button on a webpage or expose an endpoint.

Why is so fundamental about the fact that a byte is 8 bits? The fact that a byte is 8 bits is more for historical reasons. Likewise, an int is traditionally 32 bits, but Javascript and Python programmers don't need to worry about that. If a programmer doesn't know that a byte is 8 bits, they probably just forgot it since it wasn't necessary for them to know.

A byte is the smallest addressable unit on a given architecture.

Depending on the hardware that byte can be 8, 12, 24, 32, or 64 bits (in my own experience over the years).

It's sad so many here are claiming that there are always and only 8 bits to a byte.

I've already replied to one person who quoted an ISO standard, that they clearly had not read, in support of this misconception.

I have known what a byte was for, um, let's see, about 46 years now.

In the days when I learned what it was, it was fairly common for machines to have addressable units larger than a byte. We said that these machines "did not address to the byte". That is literally something you would say. Because a BYTE WAS NOT THE SAME THING AS AN ADDRESSABLE UNIT.

A word isn't the same thing as an addressable unit, either; your machine's word size is the number of bits it transfers over its main bus at one time and/or the number of bits it can work on in one operation. Which is maybe a bit fuzzy nowadays.

If I recall correctly, I read somewhere, back in the 1970s, that the word "byte" was originally used to mean the size of a text character. But in any common usage, even by the time I learned about it, it had settled down to just meaning 8 bits, period.

> A byte is the smallest addressable unit on a given architecture.

That’s normally called a word. I’ve seen casual usage of “byte” in that context but formal documentation has always used word.

There's historically been sloppy overlap between "byte" and "word", even today formal documentation doesn't clarify a difference.

This stems from architectures that had both a both a minimal and maximal addressable "atomic chunk" via segmented architecture.

Conversations about this varied between Intel, Motorola, TI chipset users, PDP v Cyber programmers, etc.

From a Standard C Programming (as portable assembly) viewpoint Char and Byte are interchangable and are the smallest atomic type .. with the number of bits defined by a header constant.

[1] https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v1:en

No, a word is data size they work with as a unit. Modern 64-bit computers have 64-bit words, but they're still 8-bit addressable, so they have 8-bit bytes.

I've also seen "word" used more often. Though maybe some older literature does use "byte" sometimes?

Words and Bytes are different things. As are (genuinely) Nibbles and Chunks.

It's my understanding that the word byte is a contraction of the two words:by eight. Also (fun fact) a half a byte, 4 bits, is called a nibble. May be I'm out of touch but I have never seen a word referred to as a byte outside of an 8 bit processor, words are composed of bytes.

In elder days, there were many systems with 6-bit and 7-bit bytes. It took a while to standardize on 8 bits.

So no, it's not a contraction of "by eight". It's just a different spelling for "bite", as a pun on "a bite of bits".

I've always spelled it "nybble".

But I've seen "byte" used to refer to other numbers of bits lots of times, although primarily in the old days. Not so much anymore. I think the meaning has changed with time and has become fixed on "8 bits", but it was not always so.

In theory bytes can be a different size, and 8 bits is an octet. But any modern computer, at least those most people will ever come into contact with or hear of, have 8-bit bytes. So while 8 bits = 1 byte should be common knowledge, knowing about other byte sizes is esoteric knowledge.

What systems are there with such large bytes?

The Texas Instrument TMS DSP family from 1980 through until today all have large bytes and lack octet addressing (and bit masking and such).

They are fiends for pipelined throughput and have low level ASM statements that modular index through vector calculations per clock cycle (increment pointers, multiply and add arguments, store results, etc) but are built for the float | double numerical domain grunt work with no ground given for bithack twiddling.

There are other examples but that should suffice.

You're confusing a byte (8 bits) with a C `char` (the smallest addressable unit of memory that's at least 8 bits). Usually the smallest addressable unit regardless of size is a "word", some early machines had 6-bit words.

A unit that is consistently 8 bits is properly an "octet", as found in many RFCs. Bytes can and do (or rather did) have any number of bits in them.

This is surprising to me. We measure bandwidth in bytes per second, and I'm not aware of that measurement being qualified by architecture. Are talking about the same "byte"?

Au contraire, mon ami... We measure bandwidth in bits per second, we say 100 Mbps or 1 Gbps, if you want to know the bytes per second you have to divide by 8, to know MBps or GBps

And it's the 'divide by 8' that I find interesting.

Network protocol specifications generally talk of "octets" rather than "bytes" for this exact reason.

A software engineer that forgets that there are 8 bits in a byte is like a surgeon that forgets where the heart is in an human being, in my view... One might argue that it would be fine because as an orthopaedic surgeon specialised in hands they didn't need to care about the heart area but really you wouldn't let them near a patient because it's such basic knowledge that not knowing raises a massive red flag and the basic competency of the person is called into question.

Well, I would be slightly worried if a carpenter forgot how many centimeters go into a meter. (Or how many feet go into a yard?).

"Sure", you say, "but they don't need to know it by heart. The carpenter can always look that up if they really need it."

This is true. You are 100% correct.

But think of this:

Said conversion is pretty common in Carpentry, so each time our Carpenter forgets, they're going to end up looking it up again really quickly.

You would think that after having looked it up umpteen times, the Carpenter would effectively end up memorizing the conversion by accident. Right?

So while I suppose it's not strictly necessary, it would definitely be a bit funny to encounter a Professional Carpenter who doesn't have centimeters<->meters memorized.

This analogy assumes that JS/Python devs work with byte-level measurements all the time like how carpenters work with measurements centimeter-level measurements, which is very debatable.

JavaScript and Python need to calculate filesysizes, measure network bandwidth and track memory usage just like every one else. There's also of course bit shift operations and byte arrays. Heck byte size is relevant to floating point even.

Two things:

As the saying goes: if all you have is a hammer, every problem resembles a nail. You can validly say "I've never actually needed a screwdriver", even if the screwdriver might have been more useful for the job at hand.

It also depends on what domain you're working in. I just happen to have been working on a Python/JS GUI to operate a Robot this past month. Interfacing with the Robot did require use of bits and bytes. Fortunately both Python and Javascript do support those operations for just those kinds of situations.

So while I do agree that some jobs can be done in javascript and python where you can avoid needing bits and bytes, that's my two answers:

1) Bits and bytes sure can come in handy at times. They might be the best tool for some jobs.

and

2) For some jobs you really do need to manipulate bits and bytes. You can't avoid them forever.

So if you like writing a lot of different kinds of programs for a lot of different kinds of things, you're almost certain to end up using bits and bytes sooner or later. Do that often enough and it does tend to stick. That includes Python and Javascript.

I could say the same about CSS though. Eventually, many developers end up working with CSS some way or another. But I still wouldn't consider flexbox a CS fundamental

But you do need to worry about that in almost every other language.

Javascript is currently the most popular language, and many developers get exposed to it sooner or later. Should we be regarding it as part of "CS fundamentals" now? We didn't even learn it in my school.

Point being, the stack has grown larger, and just like we don't expect programmers to know electrical engineering, I don't think we should require front-end devs to know low-level knowledge (just like I wouldn't require backend devs to know CSS)

Reply on news.ycombinator.com