The Little Printf (什么是真正的程序员)

本文探讨了程序员在追求技术卓越的过程中,往往忽视了工作的人性化方面。通过一系列虚构的对话和场景,文章揭示了不同类型的程序员角色,包括专家、自学者、早期采用者等,他们各自面临的挑战和局限。文章强调了在解决问题时关注人的因素的重要性,认为这才是真正的满足感来源。

原文地址:The Little Printf
中文翻译:什么是真正的程序员

“My bad opinions”

This text is a transcript of a presentation I have given on October 9, 2015, at the CityCode conference in Chicago. This content is also available in video, and as a PDF Document better suited for printing.

在这里插入图片描述

Chapter 1

I’ve been lucky enough to have been born before computers and video games were ubiquitous. I had the luck to play outdoors with friends and my brother, and of inventing our own games.

We could be our own heroes, use a twig that would instantly become a bow, a gun, a sword, or a telescope. It could be anything, except maybe a boomerang because once you throw the stick away, you have to go fetch it back.

在这里插入图片描述
At some point I grew up, and it became embarrassing to play that way. You can’t treat a pinecone as a grenade and pretend to have magical powers when other kids think being an adult is cool. You just don’t fit in anymore. You eventually get pressured into growing up. Still, that’s a very lucky childhood.

At some point I got the chance to play video games, and to use computers. There could be the imaginary world you had wanted all this time, materialized in front of you. It’s consuming you, and for a moment you live a different life.

But there’s something particular about most video games: you don’t create, you react, you consume. I eventually did improvisational theatre as a teenager. Then, again, it was okay to be with people and create and pretend out of nothing.

在这里插入图片描述
Of course, improvisational theatre in Quebec is different; there’s an ice rink in there — everything’s hockey.

When I got to a vocational college to study multimedia from 2005 to 2008, I eventually tripped into programming work. I found it amazing! Creativity was there again, and it could get me money! I then designed the mechanism of my first game, and it blew my mind.

在这里插入图片描述
“That’s not a real video game,” I was told. “That’s just an HTML form. You should have used an array for the text and options it would have been better. The code needs cleaning up.”

I was a bit disheartened; the game was really about the 11 pages of text I had written for the “choose your adventure” aspect of it. But I realized that if I wanted to make stuff more people thought was good, I’d have to learn a lot.

I’d have to learn “real programming”. Move from JScript in a GUI toolkit to something better, like PHP. So I learned that, along with Javascript. Then eventually I was told to learn how to do real programming again; PHP is terrible. I was told to maybe try Python, which I then learned.

But real programmers knew fancier stuff, and python’s lambdas didn’t cut it, object-oriented programming was not where you wanted to be. Reading SICP would be the next good step, I was told, because it was like the bible of computer science.

在这里插入图片描述
That got me to Scheme. And I got the K&R book because real programmers in the real world did C, and I registered for part time classes at my local university while juggling them with work, because real programmers knew data structures and math, which I learned to some extent. I started reading papers and books, because real programmers stayed up to date and knew fancy algorithms.

Somewhere through that I picked up Erlang and started making a career out of it. I wrote a book on it. Curiously enough, nobody ever questioned if I were a real author, or a real writer, or a real illustrator. Hell, I got a job teaching Erlang without ever having used it in a production system.

Chapter 2

So I lived my life flying around the world, telling people how to do things I had sometimes never done myself, while everyone suddenly seemed to believe I was a real programmer because of things I did that were mostly not related to programming in the first place.

One day, I was stuck in an airport coming back from a conference, furiously typing at a terminal, when an odd, gentle voice asked me:

“If you please, design me a system!”

“What?!”

“Design me a system!”

I looked up from my screen, surprised by the request. I looked around and saw this kid who aspired to be a developer and wanted me to call him “printf”, which I felt was very stupid and gimmicky. He looked a bit like this:

在这里插入图片描述
“I don’t know computers much yet, but it seems you do. I want to write programs and blog about them and have people use and read them. Please, design me a system!”

Now that was a surprising request, and I had been awake for 20 hours by then, not too sure I fully understood or felt like it. I told him systems were hard. I didn’t know what he wanted to do, how he wanted it to fail, how many readers it should support, where he’d want to host it, and I could therefore not design a proper system with so little information.

“That doesn’t matter. Design me a system.”

So I made the following architecture diagram:

在这里插入图片描述
He looked at it and said “No, this system is not good enough. Make me another.”

So I did:

在这里插入图片描述
and I gave him a rundown of how it would work.

My new friend smiled politely. “That is not what I want, it’s way too complex and does a lot of stuff I don’t need”

I felt a bit insulted, having considered redundancy, monitoring, backups, caches and other mechanisms to reduce load, external payment processor for legal protection, failovers, easy deployment, and so on. I could have charged decent money as a consulting fee for that! Out of patience, I just drew this:

在这里插入图片描述

And I added: “this is your design. The system you want is inside the black box,” hoping this shitty answer would have him leave me alone. But I was surprised to hear back:

“That is exactly the way I wanted it!”

And that is how I made the acquaintance of the little printf.

Chapter 3

I soon learned of this little guy’s portfolio. In his repositories were only small programs, simple web pages with forms, trivial command line utils. They would be unspectacular, would come into being, and no sooner disappear.

Then at some point, he started working on a bigger program, that used multiple modules. It needed sockets, accessed the disk, talked to an actual database. When it first built and ran properly, little printf was amazed. But the program was not enough yet.

It needed refactorings, better tests, documentation, linting and analysis. The program would run for a while, and one morning, it crashed.

And it crashed again, and again.

The configurations were wrong, the logs would not rotate, the disk had unpredictable speed, the network would get the hiccups, bugs would show up, the encodings would be confused, the database needed vacuuming, transactions would hang, certificates would expire, CVEs would keep coming, and the metrics would remain silent.

在这里插入图片描述

It kept turning to Spaghetti.

He told me: “the fact is I didn’t know anything! I ought to have judged by my needs. I got the hubris of writing a fancy system, and I spent so much time fixing it, it felt like it cancelled the time it saved me. Still, I should have known what a wonderful thing it was.”

One morning, he decided to leave his office. “Goodbye”, he said to a blinkenlight that seemed to have burnt out. He left to see what the world of software had to offer aside from his messy little server.

The logs would keep accumulating, until the hard drive would fill no more.

Chapter 4

在这里插入图片描述
He went to a workspace, looking for experienced developers from whom to get tips and help.

The first one he met was a very proud senior engineer who seemed to feel rather superior.

在这里插入图片描述
“Ah, here comes a learner! Welcome to my domain, of which I am the expert” he said.

“An expert?” Little printf asked. “Does this mean you can program anything and everything?”

“Yes!” the expert answered. He added “Well almost; I only program programs that are worth programming. I don’t lose my time on trivialities. Many programs I have never written but could write with all the ease in the world.”

“Ah, so could you help me with my system?” As soon as the little printf started explaining his business, the domain expert interrupted him:

“I’m sorry, but I don’t really see the point of doing that.”

“Why not?”

“Experience. I am good at programming the things I program, and I program things I am good at. By getting better at this fairly restricted set of things I’m already good at, I make sure I’m more valuable than ever at it. Call it job security, call it survival of the fittest, but that’s how I roll.”

“And why can’t you help me?”

“Well you see, taking my time away to help you means I divert important self-investment into furthering the progress of others — that’s a losing strategy for me. The best way to learn for you is the way I took myself: struggle very hard and figure it out yourself. It helps forge character.”

“That doesn’t seem very efficient…”

“Well you can go to school and learn, or you can learn on your own. Really what it does is weed out the lazy people who just want it easy, and forces everyone who stays here to be those who really deserve it. The moment we let moochers in, the very value of the work I produce goes down with it.”

“Do you not think cooperation or colleagues could help you?”

“Not really. I work best when left alone and not being distracted. Every time I end up forced working with others, it’s nigh impossible to get our stuff working together. Out of exasperation, I grab their work and rewrite most of it in a sane way; then it works right.”

Little printf was surprised to meet an expert who seemed so disinterested in helping others, yet so annoyed by their perceived lack of skill. It was a bit sad that this man narrowed his vision of himself to just the one area he knew, to the point where he didn’t do anything else than create problems for himself to fix!

“I see… well I guess I’m happy you won’t give me your help”, said my little friend

“What do you mean?” asked the meritocratic man, whose value seemed suddenly downgraded. “Don’t you think the work I do is interesting?”

“Oh that I do. It just seems like you would see me as a hindrance and annoyance more than anything else, and what I am looking for is help, not affliction.”

And little printf left swiftly, leaving the expert to realize he had made himself untouchable in more ways than just his job security.

Chapter 5

在这里插入图片描述On his way, little printf went in front of the door to an office occupied by a man surrounded by thick hardcover books, with fancy images on them like wizards and dragons and fractals and mathematical patterns.

“Nice books, sir”, said printf

“Thanks. I think they’re essential material for programmers. If you don’t have them, you’re not really a pro”

“I guess I’m not a pro then”, said little printf. “Which one is your favorite?”

“Oh, well I haven’t read most of them.”

“Are you not a good programmer then?”

“No, I am not.” The developer proudly added: “In fact, I’m a terrible programmer.”

“That’s a shame”, said little printf, who continued: “I’m getting better myself.”

“Have you heard of the Dunning-Kruger effect?”, asked the man.

“No, what is it?”

“It’s a cognitive bias thing. It basically says that people who are less competent tend to overestimate their qualifications, and people who are competent tend to systemically underestimate theirs.”

“So if I think I’m getting better, I’m probably not great”

“Yeah, exactly. You’re probably bad. On the other hand, I openly say I’m a terrible programmer. But according to Dunning-Kruger, I’m probably underestimating myself, and that makes me a good developer, don’t you see?”

“I guess?”

“That’s because self-deprecation is a vital tool of the developer. The moment you feel you’re good, you relax and stop improving.”

“Doesn’t this mean that the moment you feel good about yourself, you’re on your way to failure and then you should feel bad?”

“yes. But the way to go about this is to say that everything is terrible, even if you have no solutions to offer. That way you look smart, but don’t have much to contribute.”

“What do you mean?”

“Say I go online and see a project I dislike. The trick is to point out everything that is wrong, give no more information than that. You can probably subtly point ways in which the person who did the thing is an idiot and get away with it.”

“And how is anyone better for this?”

“Well I like to think they are better for knowing they’re on the wrong track, and I’m better off for showing them that. It’s a bit of smoke and mirrors. Nobody knows what they’re doing but that way it looks like I do.”

“And what happens when you are asked for help and can’t do anything about it?”

“That’s when you go back to saying everything is terrible; you have too much yak shaving to do, improving other things, and being overly pessimistic. They’re on their own.”

“So this is all posturing? You’re gaming your way through? You’re the person who pretends to be incompetent at things they know, which makes people who actually know nothing there feel even worse, and you’re the person who pretends to be competent at things you don’t know, so that people trying to improve there also feel bad.”

“In any case, competence has very little to do with it. Reputation is pretty important though. People hire friends, and people who aren’t liked and non-essential get fired first; try to change the system and you become disliked. It’s all a very social game. It’s how it works in the industry, and probably in academia too, though I wouldn’t know, now would I? It’s all about who you know, selling yourself, your own personal brand you know? That’s how you get jobs in the business.”

“If this is how things are and that you must feel bad and make others feel bad to do well, maybe I don’t want a job in the business”, said little printf, before walking out.

Chapter 6

在这里插入图片描述
During the time that would have been lunch break, Printf interrupted a person who had seemingly forgotten to eat their lunch, a sandwich growing cold by the minute, while sitting at their desk and looking at their screen.

That seemed like quite a busy person who might have known what they were doing. Printf asked:

“If a primary database can fail, can the follower fail too?”

“Everything you run”, the person said, “can and will sooner or later fail.”

“Even the things telling you things have failed?”

“Yes, even these ones. All large systems are in some state of partial failure at any given time.”

“Then, trying to make reliable systems, what use is it?”

The person did not know, for at that moment, they were trying to answer a page for the sky falling out onto their head due to a broken cloud, wondering the same thing.

“Then making reliable systems, what use is it?” pressed little Printf again

Upset as the person was dealing with a production issue, with this kid not letting go and a sandwich going to waste, the person impatiently shot back:

“It’s of no use at all. Programming is all shit anyway.”

“oh!”, he gasped.

Then there was a moment of complete silence.

在这里插入图片描述

The little guy responded, with a hint of resent:

“I don’t believe you. Programs are fragile, but programmers can make good efforts and make things better and useful.”

No answer came back. At that point the person had opened the document explaining how to boot a new copy of the whole cluster from scratch, and things seemed to go from bad to worse.

“And you actually believe good reliable prog-”

“Oh no!” the person said. “No no no! I don’t believe in good or reliable programs! Not anymore! They’re all terrible! I just told you the first thing that came to my head because I’m dealing with one of these shitty systems right now. Don’t you see I’m trying to keep this stuff running? This shit is actually of consequence.”

Printf stared back, with a shocked expression.

“Actually of consequence? You talk just like a ‘real programmer’.”

He added:

“You mix everything up, confuse everything. There’s been millions of programs, and for years they’ve been running and failing just the same. And people have used them and needed them. And I know of some programs that run nowhere but on a single laptop, and in a single mistake could destroy entire communities, without even noticing. And you think that this is not important?”

The person remained silent.

Chapter 7

在这里插入图片描述
The fourth workspace my friend visited had a man whose computer was covered in so many stickers nobody could tell what brand it was.

“motor-mvc, quadrangular JS, GoQuery, cometeor, some japanese soundy thing, …”

“Hi,” interrupted printf. “What are you doing?”

“alchemist, bongodb, mochascript, walktime.js, portasql, …”, the man kept going

“What are you doing?”, he asked again, louder this time.

“Oh, I’m trying out new frameworks, tools, databases, languages.”

“Whoa, you seem to be going fast, maybe as fast as 10 programmers put together!”

“yes! well, the industry moves so very fast!”, he looked at his phone for a second, and added “there! the cardboard.io framework came up with version 3.5 which broke compatibility with 3.4 and this yielded 4 forks in the community! I have to try them all to know which to choose!”

“and what do you do learning all of these?”

“I’m an early adopter. If you don’t stay up to date you get stuck writing COBOL or MUMPS for a living. You want to find the next big thing, and ride the wave to the top!”

“Has it ever worked?”

“Oh yes! I found out about Rails before it got big, and I figured out node.js before it was popular, and I was on the first beta copies of redis and mongodb and riak! I was the first one to use vagrant and then I got us to switch to docker but of course now it’s all about unikernels…”

“Cool, and all these things you were at the forefront of, how did it pay off?”

“oh it didn’t; by the time rails became huge I had moved on to the next big thing so I didn’t get left behind. Similarly for the other ones. Here’s hoping for unikernels though”

“I see”, added little printf, pensively. “What problems do you solve with all of these frameworks?”

“Oh, I make sure we don’t use something that is not going to be big, so that this company doesn’t get to bet on technologies that have no future. It’s very important work, because if you don’t do that, you can’t find anyone to hire except old grey beards behind the times, and you want self-motivated go-getters, who are also early adopters.”, said the man.

“That is funny”, chimed our friend.

“It is very hard! in the startup world, if you want a-players, you need good technology to bring them in! Otherwise you’re stuck with inflexible laggards. Nobody wants to be an inflexible laggard.”

The little printf interjected: “No, that’s not what I mean,” and he then added “I mean it’s funny that tools are meant to solve problems for us, but for you, the tools themselves have become a problem.”

And while the man stood there in silence (on his new cool treadmill desk), little printf hopped out of the room.

Chapter 8

在这里插入图片描述
In the next office over sat a tired employee, with dozens of empty coffee cups, slouched over, typing angrily.

“Hi,” said little printf.

The woman didn’t stop what she was doing. She kept typing furiously.

“Hello?” he asked again.

The woman stopped at once, got a flask out of a drawer in her desk, and took a swig.

“I have a terrible job,” she said. “I do devops. It started okay, where I’d mostly develop and then sometimes debug stuff, but as time moved on, it got worse and worse. I started fighting fires in our stack, and then more fires kept happening. I got rid of most of them, pulling small miracles here and there to then meet the deadlines on dev stuff I also had to do”

“And did they hire anyone to help?”

“No, that’s the thing. Small fires kept happening here and there, and because of the time I took to fight them, I couldn’t be as careful as before with the dev stuff, so I created more fires all the time. Now I’m fighting fires all day and all night and I hate my job”

“Why doesn’t your employer do anything?”

“I’m good at my job, and I managed to keep things under control long enough that everyone got used to it. When you make a habit of small miracles, people get used to it. Then you’re stuck doing miracles all the time or they will think you won’t do your job at all.”

“That sounds very sad”

“It is; and because you’re the most familiar person with these fires, you get to only work on them more and more, until your employer hires someone else to cover your old job, the one you loved. If you care hard enough about your work to be the one doing the stuff everyone else hates, you’re thanked by doing more and more of that work you don’t like, until that’s all you do. And then there’s nothing left for you to enjoy.”

“Then you’re unlucky”, said little printf.

And her pager went off again.

“That woman,” said little printf to himself, as he continued farther on his journey, “that woman would be scorned by all the others: by the senior expert, by the rockstar developer, by the serial early adopter. Nevertheless she is the only one of them all who seems helpful. Perhaps that is because she is thinking of something else besides herself.”

Chapter 9

在这里插入图片描述
At the corner of the building, printf found a large office with big windows giving a stunning view of the area. In it sat an old gentleman with reams of documentation on his desk.

“Ah, here comes a developer” exclaimed the man, as printf stood in the doorway. “Come in!”

Looking through the windows, little printf noticed that they were full of writing. With the help of a dry-erase pen, the view to the outside world was masked by tons of circles, arrows, cylinders, and clouds. While it was curious the man needed clouds drawn where real ones could be seen outdoors, the whole ensemble was more intriguing.

“What is this?”, asked our friend, pointing at the windows.

“Oh this? This is our production system!” Said the man, not once thinking the question was about the outside world. “I am a software architect.”

“What’s a software architect?”

“Mostly, it’s someone who knows how to best structure and coordinates the components of a large system so they all fit together well. It’s someone who has to know about databases, languages, frameworks, editors, serialization formats, protocols, and concepts like encapsulation and separation of concerns.”

“That is very interesting!” said little printf, “here is someone who can answer all my questions!” He glanced at the architecture diagrams. “Your system is very impressive. Is it running very fast?”

“I couldn’t tell you,” said the architect. “It should, though”

“How’s the code then, is it good?”

“I couldn’t tell you”

“Are the users happy about it?”

“I couldn’t tell you either, I’m afraid”

“But you’re a software architect!”

“Exactly! But I am not a developer. It is not the architect who goes and writes the modules and classes, combines the libraries. The software architect is much too important to go around touching code. But he talks with programmers and developers, asks them questions, provides them guidance. And if the problem is looking interesting enough, the architect takes over the planning.”

“And why is that?”

“Because we are more experienced. We know more about systems and what works or not. Developers can then be an extension of our knowledge to produce great systems!”

“But how do you know if things are going well without getting involved with code?”

“We trust the developers”

“So you trust them to implement your ideas correctly, but not enough to come up with their own ideas?”

The software architect was visibly shaken by this comment. “I guess I might have been a bit disconnected”, he finally admitted. “The problem is that after a while you are asked to work with ideas so much you don’t have a good way to get them tested or verified…” he stared down, pensively. “Sometimes a software architect does neither software nor architecture, it seems.”

Little printf left the room, and being done with his visit, exited the building.

Chapter 10

在这里插入图片描述

Little printf, once outside, met a man collecting money for some charity.

“Hi,” said the man. “how would you feel about helping someone today?”

“It would probably make me feel better,” said little printf back. “I have been in this office all day, and now I’m more confused than ever.”

“Ah I see. These people are all developers. They are not really helpful, are they? What they love to say is that they’re changing the world, and they pretty much succeed at that, in fact.”

“Why does it feel so awkward, then?” Asked little printf.

“Well, the best they do is often help convert some people’s jobs into programs, or make everyone’s leisure more leisurely. Software is eating the world and that changes its face for sure… but deep down it’s the same old world, with a mangled face. The reason it feels awkward is that changing in that way doesn’t mean things are getting any better. We have the same flaws and problems we always had, the same holes to fill deep down inside.”

“So how can I feel better?” Little Printf was visibly anxious.

The man thought for a while, and offered printf to come help him help others, as this was this man’s way of feeling better. During the afternoon, printf told the man about his problems and his adventure. After a long silence, the man said:

“The games people play, the roles and reputations they chase and entertain, the fleeting pleasure they derive from solving intricate problems, is all fun for a while. Ultimately though, if you do not solve anything worthwhile, if you forget about the people involved, it’s never gonna be truly fulfilling.”

“And that may be fine, and it might not be, and you may or may not get that from somewhere else than your workplace when you grow up. Work can be work; it can be for the money, it can be for the fun of it. That’s okay. As long as you manage to get that fulfillment somewhere in your life.”

“In the end though, it is only when you solve problems with a human face that you can feel truly right; What is essential is invisible to the computer.”

“It is the time you have spent on your system that makes it so important”, the man added, “and when you lost sight of why it made sense to spend time on it, when it became a game of pride, it caused more grief than relief.”

“Developers have often forgotten this truth; If you lose sight of things, working on your system becomes its own problem, and the most effective solution is to get rid of the system, given it’s the problem.”

“It is only when you solve problems with a human face that you can feel truly right”, repeated little printf to himself, so he would remember.

Chapter 11

在这里插入图片描述Printf, who’s now sitting right in front of me, is on his way home. Talking with him made me realize how much of what I do flies in the face of what I liked, what I started programming for. Each of the people Printf met are roles I see myself taking one day or another over time. I was encouraged by them to become them, and probably encouraged people to do the same.

Where I got dragged in the game of trying to become a real programmer, Printf didn’t. He said he was okay with not being a real programmer, that he preferred to be a programmer with a human face.

Today I’m stuck in the situation where I look back, and have to figure out if I can, too, become a programmer with a human face; or if everything I do is just a job. There doesn’t seem to be too much that’s worthwhile in-between.

In any case, where printf felt he didn’t need to be a real programmer, I think I feel the same now.

<think>首先,用户的问题是关于大端模式和小端模式的定义与区别。我需要基于提供的引用内容来构建回答。 从引用中提取关键点: - 引用[1]: 大端模式和小端模式的区别必须从系统的角度理解,包括指令集、寄存器和数据总线。 - 引用[2]: 大端模式是高位字节存储在低地址,低位字节存储在高地址;小端模式是低位字节存储在低地址,高位字节存储在高地址。 - 引用[3]: 在网络上传输数据时,必须采用大端模式(网络字节顺序)。 - 引用[4]: 小端模式:低字节数据在内存低地址处,高字节数据在高地址处;大端模式:高字节数据在低地址处,低字节数据在高地址处。基于X86的PC机是小端,有些嵌入式平台是大端。网络传输时需转换字节顺序。 用户的问题:"我想理解大端模式和小端模式的概念及其区别 请问大端模式和小端模式的定义与区别" 所以,我需要清晰地定义大端模式和小端模式,并解释它们的区别。 回答结构: 1. **定义**:明确解释大端模式和小端模式。 2. **区别**:对比两者的存储方式。 3. **实际例子**:给出一个例子来说明。 4. **系统级理解**:从系统角度解释,如指令集、寄存器。 5. **网络应用**:提到网络字节顺序。 6. **常见平台**:指出哪些平台使用哪种模式。 7. **如何判断**:简要提到如何判断机器的字节序(可选,因为引用中提到)。 使用中文回答,确保语言清晰。 在回答中,引用段落末尾自然地添加引用标识,例如[^1]。所以,我需要引用来源。 相关引用: - 定义:引用[2]和[4]提供定义。 - 区别:引用[4]对比。 - 系统角度:引用[1]强调。 - 网络:引用[3]和[4]。 生成相关问题: - 在回答结束后,添加"§§相关问题§§"部分,列出相关问题。 格式要求: - 行内数学表达式用$...$,但这里可能不需要数学表达式。 - 独立公式用$$...$$,但这里可能没有公式。 - LaTeX语法正确。 - 回答结构清晰。 最终回答结构: 1. 引言:简要介绍概念。 2. 定义:解释大端和小端。 3. 区别:详细对比。 4. 例子:给出一个数字的存储示例。 5. 系统角度:为什么重要。 6. 网络字节顺序。 7. 常见平台。 8. 如何判断(可选)。 9. 总结。 10. 相关问题。 现在,撰写内容。 定义: - 大端模式(Big-Endian):高位字节存储在内存的低地址处,低位字节存储在高地址处。 - 小端模式(Little-Endian):低位字节存储在内存的低地址处,高位字节存储在高地址处。 例子:假设一个32位整数0x12345678(十六进制)。 - 在内存中,地址从低到高: - 大端模式:12 34 56 78(高位字节12在低地址) - 小端模式:78 56 34 12(低位字节78在低地址) 区别: - 存储顺序不同。 - 影响数据读取和写入。 系统角度:从指令集、寄存器和数据总线理解。大小端模式影响CPU如何解释内存中的数据。 网络:TCP/IP使用大端模式作为网络字节顺序。传输数据时需转换。 常见平台:X86 PC是小端;ARM等嵌入式可能大端或小端。 如何判断:可以通过编写程序检查。 添加引用: - 例如,在解释定义时引用[2]和[4]。 - 系统角度引用[1]。 - 网络引用[3]。 相关问题: 1. 如何判断一个系统是大端还是小端模式? 2. 为什么网络传输使用大端模式? 3. 大小端模式在编程中如何处理? 4. 大小端模式对性能有什么影响? 5. 在实际应用中,大小端模式如何影响数据存储? 确保回答真实可靠。</think>### 大端模式和小端模式的定义与区别 大端模式(Big-Endian)和小端模式(Little-Endian)是计算机系统中用于描述多字节数据(如整数、浮点数)在内存中存储顺序的两种不同方式。这种区别源于硬件设计,影响数据如何从内存读取和写入,对于系统开发、网络通信和嵌入式编程至关重要。下面我将逐步解释其定义、区别、实际例子及相关系统级影响。 #### 1. **定义** - **大端模式**:高位字节(Most Significant Byte, MSB)存储在内存的低地址处,低位字节(Least Significant Byte, LSB)存储在高地址处。简单来说,数据的高位部分优先存放在内存起始位置。 *例如,一个32位整数 `0x12345678`(十六进制),在大端模式下存储为:地址0处为 `0x12`,地址1处为 `0x34`,地址2处为 `0x56`,地址3处为 `0x78`。[^2][^4]* - **小端模式**:低位字节(LSB)存储在内存的低地址处,高位字节(MSB)存储在高地址处。数据的低位部分优先存放在内存起始位置。 *例如,同一个32位整数 `0x12345678`,在小端模式下存储为:地址0处为 `0x78`,地址1处为 `0x56`,地址2处为 `0x34`,地址3处为 `0x12`。[^2][^4]* #### 2. **核心区别** 两者的主要区别在于字节的存储顺序,这影响了数据在内存中的布局: - **存储顺序**: - 大端模式:类似于人类阅读数字的顺序(从左到右,高位在前)。 - 小端模式:类似于数字计算的顺序(从右到左,低位在前),便于CPU快速处理算术运算。 - **地址与字节关系**: - 在大端模式下,内存低地址对应数据的高位部分。 - 在小端模式下,内存低地址对应数据的低位部分。 - **影响范围**:这种区别不仅限于内存存储,还涉及寄存器、数据总线和指令集的设计。例如,CPU在读取数据时,会根据端模式解释内存中的字节序列,从而影响程序的行为。[^1][^4] #### 3. **实际例子** 以32位整数 `0xAABBCCDD` 为例,其在内存中的存储方式(地址从低到高): - **大端模式**:`AA BB CC DD`(高位 `AA` 在地址0)。 - **小端模式**:`DD CC BB AA`(低位 `DD` 在地址0)。 这种差异在跨平台数据交换时尤为明显。例如,在PC(小端)和嵌入式设备(可能大端)之间传输数据时,如果不转换字节顺序,会导致数据解析错误。[^4] #### 4. **系统级理解** 从系统角度(指令集、寄存器和数据总线)看,大小端模式的区别源于硬件架构: - **指令集**:CPU的指令集设计决定了端模式。例如,大端模式的CPU在读取内存时,会优先处理高地址字节;小端模式的CPU则相反。 - **寄存器**:当数据加载到寄存器时,端模式影响如何填充寄存器位。小端模式允许直接处理低位字节,减少移位操作,提升效率。 - **数据总线**:在数据传输过程中,总线协议必须匹配端模式。否则,会导致数据错位或错误。 *单纯从软件层面理解不够,必须结合硬件设计才能真正掌握端模式的区别。[^1]* #### 5. **网络字节顺序** 在网络通信中,TCP/IP协议规定使用大端模式作为标准网络字节顺序(Network Byte Order)。这是因为: - 网络设备可能来自不同平台(如小端的PC和大端的服务器),大端模式提供统一标准。 - 数据传输前,发送方需将主机字节顺序转换为大端模式;接收方再转换回自己的主机顺序。 - 注意:char类型数据(单字节)不受影响,但多字节数据(如int、uint16)必须转换。[^3][^4] #### 6. **常见平台** - **小端模式**:主流PC(基于x86/x64架构,如Intel和AMD处理器)、Android和iOS设备。 - **大端模式**:部分嵌入式系统(如PowerPC、某些ARM变体)、网络设备和旧式服务器。 *在实际开发中,程序员需检测平台端模式,以避免兼容性问题。[^4] #### 7. **如何判断端模式** 可以通过简单程序判断机器的字节序(例如,用C语言检查一个整数的内存布局): ```c #include <stdio.h> int main() { int num = 1; char *p = (char*)# if (*p == 1) { printf("小端模式\n"); // 低位字节在低地址 } else { printf("大端模式\n"); // 高位字节在低地址 } return 0; } ``` #### 总结 大端模式和小端模式的核心区别在于多字节数据的存储顺序:大端模式以高位字节优先,小端模式以低位字节优先。这种差异源于硬件设计,影响系统性能、数据解析和网络通信。理解端模式需从系统层面入手,包括指令集、寄存器和总线交互。在网络环境中,大端模式作为标准,确保跨平台兼容性。[^1][^3][^4]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值