English

The history of Computer Science is not best understood as a sequence of machines, languages, or products. It is better understood as a sequence of changing problem regimes. In each period, a different difficulty became central: first the definition of computation, then the physical realization of computation, then programming abstraction, software complexity, resource limits, shared systems, persistent data, networking, human usability, and adversarial security. Each new period did not replace the earlier problems. It added another layer of constraint.

The deepest movement is from pure formal possibility toward real-world reliability. Early CS asked whether a problem could be computed at all. Later CS asked whether it could be computed efficiently, expressed clearly, implemented safely, shared among users, stored persistently, communicated across networks, secured against attackers, and made usable by ordinary people. This is why CS should not be reduced to programming. Programming is one expression of a larger discipline concerned with representation, transformation, abstraction, resource control, failure, uncertainty, and trust.

1930s–1950s: The Formalization of Computation

The first foundational problem of CS was not how to build a computer. It was more abstract and more radical: what does it mean for something to be mechanically computable? Before modern electronic computers existed, logicians and mathematicians were already trying to understand whether reasoning itself could be formalized. They wanted to know whether there could be a fixed procedure for deciding mathematical truth, whether calculation could be described without relying on human intuition, and whether every meaningful mathematical problem could in principle be solved by symbolic manipulation.

This period belongs to the history of logic as much as to the history of computing. The central object was not yet the physical computer, but the formal procedure. Words such as “algorithm,” “effective method,” and “mechanical process” were in use, but they needed precise meaning. The challenge was to convert the intuitive image of a human following rules into a mathematical model that could itself be studied.

The major breakthrough was the creation of formal models of computation, especially the Turing machine and the lambda calculus. These models were not important because real machines literally look like them. They were important because they made computation mathematically discussable. A Turing machine showed how computation could be represented as symbolic manipulation through states and transitions. The lambda calculus showed how computation could be represented through function abstraction and reduction. Together with other equivalent models, they gave a precise answer to the question: what counts as an effective procedure?

Once computation had a formal model, CS could ask deeper questions. Can one formal system simulate another? Are all reasonable models of computation equivalent in power? What kinds of problems can no procedure solve? The discovery of undecidable problems, especially the halting problem, established one of the first great limits of the field. Some problems are not merely difficult. They are impossible to solve by any general mechanical method.

The methodological style of this period was formal modeling. One defines a model, specifies its allowed operations, and then proves what it can and cannot do. This remains one of the central methods of theoretical CS. It appears later in automata theory, programming language semantics, verification, cryptography, and complexity theory. The enduring lesson is that CS begins not with machinery, but with the formal structure of procedures.

1940s–1960s: From Formal Procedure to Physical Machine

Once computation had been formalized, the next problem was how to realize it physically. A formal procedure is an abstract object; a working computer is a material system built from circuits, memory, input-output devices, and control mechanisms. The core question became: how can abstract computation be embodied in a machine that operates reliably and usefully under physical constraints?

Early computers were expensive, fragile, specialized, and difficult to program. They had limited memory, limited speed, unreliable components, and awkward interfaces. Programs were often tied closely to the hardware. Computation was not yet the flexible, general-purpose activity that later became familiar. It was still partly a matter of configuring a machine for a particular task.

The decisive idea was the stored-program computer. If instructions and data could both be stored in memory, then the same physical machine could execute many different procedures. This created a powerful conceptual shift: a program could be treated as data that controls computation. The implications were enormous. Compilers, interpreters, operating systems, virtual machines, loaders, and later self-hosting software systems all depend on this idea.

This period also made abstraction layers necessary. At the lowest level, there are electrical and physical processes. Above them are circuits, memory cells, machine instructions, assembly languages, and eventually high-level languages. No human can reason comfortably from electrons to applications. The growth of computing therefore required layered abstractions that hide lower-level detail while preserving enough structure for correctness and performance.

The method of the field changed accordingly. CS could no longer be only formal logic, and it could not be only electrical engineering. It became a discipline located between formal abstraction and physical realization. Every real computer system has this dual character. It executes formal procedures, but it does so through hardware that has timing, memory, cost, heat, failure, and physical limits. The lasting lesson of this period is that a computer is not just a machine. It is a stack of abstractions built over physical constraints.

1950s–1970s: From Machine Control to Programming Abstraction

As computers became more capable, the main bottleneck shifted from machine construction to human expression. The core problem became: how can humans describe complex computation without being overwhelmed by machine detail? Early programming required close attention to memory locations, registers, jumps, and hardware-specific operations. This made programs difficult to write, difficult to read, and difficult to maintain.

The central tension was between machine efficiency and human intelligibility. A machine can execute low-level instructions, but humans need higher-level structures. They need names, procedures, data types, modules, and control constructs. Without these, programs become long chains of operations whose meaning is hard to recover.

High-level programming languages and compilers were the major response. Languages such as Fortran, Lisp, Algol, COBOL, and later C did more than simplify syntax. They changed the level at which programmers could think. Fortran made numerical computation more natural. Lisp made symbolic computation and recursive structure central. Algol influenced block structure and language design. COBOL reflected business data processing. C exposed a powerful model close enough to hardware to support systems programming, but abstract enough to write portable software.

A compiler became a crucial bridge between human expression and machine execution. It translated high-level constructs into lower-level instructions while preserving meaning. This made programming increasingly a matter of designing abstractions rather than merely issuing commands to hardware. Different languages embodied different theories of computation: numerical, symbolic, procedural, functional, imperative, structured, object-oriented, and later declarative or logic-based.

This period also showed that notation is not superficial. A programming language shapes how problems are represented, decomposed, and solved. The question “what language should we use?” is often a question about which abstractions should be natural and which errors should be difficult to express. This led toward programming language theory, formal semantics, type systems, compiler optimization, and software engineering. The lesson is that progress in CS often happens when humans acquire a better level of description for computation.

1960s–1970s: The Software Crisis and the Need for Discipline

As programs grew larger, a new problem appeared. The issue was no longer simply how to express computation, but how to build large software systems reliably over time. The core question became: how can complex programs be developed, understood, tested, modified, and maintained by groups of people?

This was the period of the so-called software crisis. Hardware was improving quickly, but software projects often failed. They were late, over budget, unreliable, difficult to maintain, and poorly matched to changing requirements. The problem was not just that programmers made mistakes. The deeper problem was that informal programming practices did not scale with software complexity.

Software is difficult because it is formal, invisible, flexible, and social at the same time. It is formal because the machine follows exact instructions. It is invisible because its structure cannot be inspected the way one inspects a bridge or a machine. It is flexible because almost any structure can be encoded, including bad structures. It is social because large software is written by teams across time, under shifting goals and institutional pressures.

Several responses emerged. Structured programming tried to discipline control flow and make program behavior easier to reason about. Modularity and information hiding argued that systems should be divided into components with stable interfaces and hidden implementation decisions. Software engineering tried to turn software construction into a systematic discipline involving requirements, design, testing, documentation, maintenance, and project organization. Formal methods explored whether programs could be specified and proven correct.

The deeper principle behind these movements was dependency control. Large systems fail when dependencies are hidden, unstable, or uncontrolled. A module should expose what others need and hide what they do not. An interface should protect an invariant. A design should make local reasoning possible. A test should preserve behavior across change. Software engineering therefore became the practical art of making change survivable.

This period changed the meaning of correctness. A small program may be considered correct if it produces the right output for the intended input. A large software system must do more. It must remain understandable, testable, modifiable, portable, and robust under changing conditions. The lasting lesson is that the central enemy of software is uncontrolled complexity.

1960s–1980s: Complexity, Feasibility, and the Limits of Efficient Computation

Computability theory had shown that some problems cannot be solved by any general algorithm. But among the problems that can be solved, another question became central: which problems can be solved efficiently? This distinction changed the field. A problem may be computable in principle but practically impossible because it requires too much time, memory, communication, or energy.

This gave rise to modern complexity theory. CS needed a disciplined way to talk about resource use. It was not enough to say that one program seemed faster than another on a particular machine. The field needed a way to analyze how resource demands grow as input size grows. It also needed a way to compare the difficulty of different problems.

The key concepts were complexity classes and reductions. Problems could be grouped according to the resources required to solve or verify them. Reductions allowed one problem to be transformed into another, creating a map of relative difficulty. The theory of NP-completeness was especially important because it showed that many apparently unrelated problems shared a common form of hardness. If one could efficiently solve any NP-complete problem, one could efficiently solve a vast class of problems.

This made reduction one of the deepest methods in CS. A reduction is not just a way to reuse a solution. It is a way to transfer solvability, hardness, and impossibility. Through reductions, CS builds a dependency graph among problems. This is why complexity theory affects many areas beyond pure theory: algorithms, optimization, cryptography, verification, artificial intelligence, databases, and operations research.

The methodological shift was from local performance measurement to structural resource reasoning. A mature algorithmic analysis asks how a method scales, what assumptions it relies on, what lower bounds are known, whether exact solution is necessary, and whether approximation, randomization, heuristics, or problem relaxation would be more appropriate. This period established one of the most important distinctions in CS: computable is not the same as feasible.

1960s–1980s: Operating Systems and the Governance of Resources

As computers became shared, interactive, and multi-user, the next problem concerned resource governance. A physical machine has processors, memory, storage, and devices. Many programs and users may want to use these resources at the same time. The core question became: how can one machine safely and efficiently serve many programs while preserving isolation, fairness, and control?

Operating systems emerged as the central answer. They introduced abstractions that made a physical machine appear more orderly than it really was. A process gave a program an execution context. Virtual memory gave programs the illusion of private address spaces. File systems gave persistent data a name structure. Schedulers shared CPU time. System calls controlled access to privileged operations. Protection boundaries separated user-level code from kernel authority.

These abstractions were not merely conveniences. They were enforceable contracts. An operating system has to maintain its illusions under pressure: memory must not leak across processes, files must remain coherent, scheduling must prevent one program from monopolizing the machine, and failures must be contained. In this sense, the OS is a practical theory of controlled abstraction.

Operating systems also made concurrency unavoidable. Multiple processes and threads may execute interleaved or in parallel. They may share resources, wait for one another, deadlock, race, or corrupt shared state. This forced CS to develop tools for synchronization, scheduling, mutual exclusion, resource allocation, and later memory models. It also made performance a systems property rather than a property of isolated code.

The lasting lesson of operating systems is that computation is not only execution. It is governance over scarce and privileged resources. This way of thinking later shaped virtualization, containers, cloud platforms, sandboxing, mobile operating systems, and secure execution environments. A good system is one that maintains useful abstractions over limited, shared, and failure-prone machinery.

1970s–1990s: Databases and the Problem of Persistent Truth

As organizations became dependent on digital records, another problem became central: how can data remain reliable, queryable, and consistent over time? Programs compute, but institutions need memory. Banks, hospitals, universities, companies, and governments need systems that preserve facts, support queries, handle concurrent updates, and survive failures.

Before mature database systems, applications often managed persistent data through files and custom formats. This made data access fragile and application-specific. A change in storage layout could force changes in application logic. Different programs could encode related data inconsistently. Concurrency and crash recovery were difficult to manage correctly.

The relational model was a decisive breakthrough because it separated the logical structure of data from its physical representation. Data could be described in terms of relations, and users could ask declarative questions about it. They could specify what they wanted without manually specifying every step of how to retrieve it. This made database systems somewhat analogous to compilers: they translate high-level intentions into efficient execution plans.

Transactions were equally important. A database system had to preserve consistency even when many users acted concurrently and even when machines crashed. The transaction abstraction allowed groups of operations to be treated as coherent units. This made persistent data safer to manipulate and made databases central to institutional computing.

The methodological shift was toward declarative abstraction and consistency guarantees. Database design asks what the logical model is, which invariants must hold, how queries should be optimized, how concurrent operations should interact, and how the system should recover from failure. This joined theory and systems: relational algebra, indexing, query optimization, logging, concurrency control, and recovery all became part of one integrated field.

Databases showed that storage is not the same as information management. A database is not merely a place where bytes are kept. It is a system for preserving structured truth under change, concurrency, and failure. This idea later became central to search engines, analytics systems, distributed storage, data warehouses, and machine learning pipelines.

1970s–1990s: Networking and the Problem of Communication Between Machines

As computers multiplied, the next problem was communication. A single machine can rely on local control and shared hardware. A networked system cannot. Machines may be different, links may fail, messages may be delayed, packets may arrive out of order, and no single machine controls the whole environment. The core question became: how can independent machines communicate reliably across unreliable and heterogeneous networks?

Networking required a new kind of reasoning. It was not enough to send bits from one place to another. Systems needed addressing, routing, retransmission, congestion control, naming, session structure, application protocols, and interoperability across different physical networks. Communication had to work despite partial knowledge. No node could assume that it saw the whole system. No message could be assumed to arrive instantly or reliably.

Packet switching and internetworking were decisive. Instead of reserving a fixed circuit for each communication, data could be divided into packets that travel through a network and are reassembled at the destination. This made networks more flexible and more robust. Layered architecture made the complexity manageable by assigning different responsibilities to different levels: physical transmission, local links, routing, transport reliability, and application semantics.

The Internet model also showed the power of minimal shared standards. A network of networks could grow because heterogeneous systems agreed on enough common protocol structure to interoperate. The end-to-end principle further shaped thinking by suggesting that some functions are best implemented at the endpoints rather than inside the network core.

Networking made failure normal. A message may be lost, duplicated, delayed, reordered, or intercepted. A protocol must therefore define what state is kept, what assumptions are made, what invariants must hold, and how recovery should happen. This style of reasoning later became central to distributed systems, cloud services, peer-to-peer systems, and secure communication.

The lasting lesson is that once computation crosses a network, uncertainty becomes part of the system. Networking does not merely connect computers. It changes the nature of computation by forcing systems to operate without central certainty.

1980s–1990s: Human Interfaces and the Problem of Usability

As computers moved from laboratories and specialized institutions into offices, homes, and schools, another problem became unavoidable: how can computation become usable by people who are not computer specialists? Earlier systems often required command languages, programming knowledge, or institutional training. This limited the social reach of computing.

The difficulty was that humans do not naturally think in machine terms. People perceive visually, act physically, remember imperfectly, make mistakes, learn through feedback, and rely on context. A technically correct system may still be practically unusable if it exposes the wrong abstractions to users.

Graphical user interfaces, pointing devices, direct manipulation, windows, icons, menus, and visual metaphors transformed the relationship between people and computers. They did not make computation less formal. Instead, they created a representational layer between formal machine operations and human action. A user could manipulate visible objects, receive feedback, recover from errors, and form a mental model of the system.

This period expanded CS methodology. Some problems could not be solved only by proof, performance analysis, or formal specification. They required observing users, testing interfaces, studying cognition, designing interactions, and evaluating accessibility. Human-computer interaction therefore brought empirical and design-oriented methods into CS.

The deeper lesson is that an interface is not decoration. It is part of the computational system’s meaning. It determines which actions are visible, which states are understandable, which errors are recoverable, and which users can participate. As computation became more widely used, usability became a core condition of technical success.

1980s–1990s: Security and the Problem of Adversarial Computation

As computers became networked, shared, and institutionally important, accidental failure was no longer the only concern. Some actors would intentionally misuse systems. The core question became: how can computation remain trustworthy under adversarial conditions?

Security introduced a different model of failure. A normal bug may be accidental. A security vulnerability is actively searched for and exploited. Attackers look for gaps between abstractions: between specification and implementation, between protocol and deployment, between user intention and interface behavior, between access control policy and actual enforcement.

Cryptography provided tools for confidentiality, integrity, authentication, signatures, and key exchange. Access control specified who could do what. Secure operating system design emphasized isolation, privilege separation, and trusted computing bases. Network security became essential as communication moved through untrusted environments. Formal protocol analysis showed that even strong cryptographic primitives can be assembled into weak systems if the surrounding assumptions are wrong.

The methodological shift was threat modeling. Instead of asking only whether a system works under intended use, security asks who the adversary is, what they can observe, what they can modify, what resources they have, where the trust boundaries are, and what assumptions the system depends on. Security also forces designers to ask what happens after partial compromise, because perfect prevention is rarely realistic.

This changed the meaning of correctness. A system that behaves correctly for honest users may still be insecure. A protocol that is mathematically elegant may fail because of implementation bugs, bad randomness, side channels, poor key management, or confused user flows. The lesson is that security is a system property, not merely an algorithmic property. A system is not robust unless it is robust against intelligent misuse.

1980s–1990s: Object-Oriented Design, Reuse, and Large Software Organization

As software systems grew larger and more interactive, the problem of long-term evolution became more visible. The core question became: how can software be organized so that it can be extended, reused, and maintained without collapsing under its own dependencies?

Structured programming had helped control local control flow, but large systems needed stronger models for organizing behavior and state. Software did not merely need to run; it needed to change. Requirements changed, teams changed, platforms changed, and users discovered new needs. A design that worked once but resisted modification became a liability.

Object-oriented programming became influential because it offered one way to organize software around units that combine state, behavior, and interface. Classes, objects, encapsulation, inheritance, and polymorphism gave programmers tools for modeling domains and structuring large applications. The deeper importance was not that every system should be object-oriented. It was that software design increasingly focused on encapsulation, substitutability, stable interfaces, local responsibility, and reuse through abstraction.

This period also strengthened interest in design patterns, frameworks, architecture, and component-based organization. Programmers increasingly had to reason about which concepts should become modules, which responsibilities should belong together, which dependencies were acceptable, and which interfaces needed long-term stability.

The methodological shift was toward architectural reasoning. In small programs, one can often think directly about execution. In large programs, one must also think about evolution. The architecture must preserve possibilities for future change while preventing unbounded complexity. This insight later influenced service-oriented architecture, microservices, package ecosystems, API design, and platform engineering.

The lasting lesson is that in large software, the structure of change matters as much as the structure of execution. A system is not well-designed merely because it works now. It is well-designed if it can continue to work as it grows, adapts, and is understood by new people over time.

Toward the Web: From Networked Machines to Global Information Space

By the end of the 1990s, the earlier layers of CS had begun to converge. Formal computation had provided models and limits. Architecture and operating systems had made machines usable as controlled resource environments. Programming languages and software engineering had given humans ways to express and organize complexity. Complexity theory had clarified feasibility. Databases had made persistent information manageable. Networks had connected machines under uncertainty. Security had introduced adversarial reasoning. HCI had made human usability a central design concern.

These developments prepared the ground for a new problem regime. Once machines were networked, usable, programmable, and institutionally embedded, computation could become a global information medium. The next major question was no longer only how one machine computes, how one program is written, or how two machines communicate. It was how billions of documents, users, services, platforms, and eventually models could coexist in a shared computational environment.

That transition leads into the Web, search, internet-scale systems, cloud computing, data infrastructure, deep learning, foundation models, and socio-technical governance.

The rise of the Web changed the center of gravity of Computer Science. Earlier periods had built the foundations: computation had been formalized, machines had been constructed, programming abstractions had matured, operating systems had governed shared resources, databases had preserved persistent state, networks had connected machines, and software engineering had confronted long-term complexity. The Web combined these earlier achievements into a new environment: a global, open, user-facing information system.

The central problem was no longer only how to compute, store, or communicate. It became: how can information be named, linked, discovered, trusted, updated, and used at global scale? This shifted CS from the study of isolated systems toward the study of large-scale computational ecosystems. A web page, a browser, a server, a search engine, a database, a network protocol, and a user interface were no longer separate concerns. They became parts of one expanding information environment.

1990s–2000s: The Web and the Problem of Global Information Access

The Web’s early importance came from a small set of powerful abstractions. A resource could be named by a URL. A client could retrieve it through HTTP. A document could be structured and linked through HTML. A browser could act as a general interface for navigating this space. These abstractions were technically simple compared with many earlier systems, but their social and architectural consequences were enormous.

The Web solved a problem that was partly technical and partly organizational. Before it, networked information existed, but it was fragmented across protocols, institutions, formats, and access systems. The Web made publication and access much easier. Anyone could create a document, link it to other documents, and make it available to others. The system did not require a central authority to approve every new page or connection. This openness allowed the Web to grow quickly.

The key problem became global information access. It was not enough for machines to communicate. Information needed names, addresses, formats, links, and interfaces. Users needed a way to move through a distributed information space without knowing the physical location or internal structure of every server. The browser became a universal client, and the hyperlink became a basic unit of public knowledge architecture.

This period also changed the meaning of software. Software was no longer only something installed on a local machine. Increasingly, it was something accessed through a network. A website could begin as a document, but it could become an application. A browser could begin as a viewer, but it could become a runtime. A server could begin as a file provider, but it could become part of a distributed service. This was the beginning of the long transition from local programs to networked applications and then to cloud services.

The Web showed that a computational system can scale socially when its basic abstractions are simple, stable, and composable. It also showed that openness creates new problems. Once anyone can publish, the system must handle noise, duplication, misinformation, spam, abuse, broken links, security risks, and discoverability. The Web therefore prepared the ground for the next major problem: finding useful information inside an enormous and rapidly changing information space.

Late 1990s–2010s: Search and the Problem of Relevance at Scale

As the Web grew, the central problem shifted from access to discovery. Publishing information was no longer enough. Users needed to find relevant information among billions of documents. The question became: how can a system decide what is useful, authoritative, fresh, and relevant for a particular query?

This was not a simple database lookup problem. A database query usually assumes structured data and clear semantics. Web search had to operate over messy, heterogeneous, constantly changing documents. A page could contain the right words and still be useless. Another page might not match the query exactly but might better satisfy the user’s intent. Queries were short, ambiguous, and context-dependent. The Web also contained manipulation, duplication, spam, and outdated material.

Search therefore became an integrated CS problem. It required crawling the Web, building indexes, ranking documents, understanding queries, fighting manipulation, serving results at low latency, and evaluating whether users were satisfied. The inverted index was central to retrieval, but ranking required more than term matching. Link structure, textual relevance, freshness, user behavior, authority signals, and later machine learning all became part of search.

This period marked a methodological shift toward data-driven evaluation. A search engine could not be judged only by formal correctness, because there was often no single correct result. It had to be judged by relevance, usefulness, and user behavior. This made offline metrics, human evaluation, click logs, and online experiments important. The system improved not only through theoretical analysis but through continuous measurement.

Search changed CS because it made ranking a central computational operation. Earlier systems often returned exact answers from structured data. Search systems returned ordered approximations of relevance. This anticipated many later systems: recommendation engines, social media feeds, advertising platforms, content moderation systems, and AI assistants. In all of these, the system does not simply retrieve a known object. It estimates what should be shown, recommended, hidden, or generated.

The deeper lesson was that at large information scale, computation often becomes inference over imperfect signals. Exact correctness remains important in the infrastructure, but the user-facing result may be probabilistic, ranked, and context-sensitive. This pushed CS further toward statistics, machine learning, experimentation, and human-centered evaluation.

2000s–2010s: Internet-Scale Systems and the Problem of Continuous Operation

Once web services attracted millions and then billions of users, another problem became dominant: how can a system remain fast, reliable, secure, and maintainable under massive scale and constant change?

This was different from building a program that runs correctly once. An internet-scale service is always operating. It receives unpredictable traffic, stores changing data, depends on other services, runs across many machines, undergoes frequent deployment, and faces continuous security threats. It cannot assume that hardware is reliable or that the network is stable. At sufficient scale, failure is not exceptional. It is normal.

This period made distributed systems and operational engineering central to everyday software practice. Large services required replication, sharding, load balancing, distributed storage, caching, asynchronous processing, queueing, monitoring, logging, tracing, deployment automation, rollback strategies, and incident response. Systems had to be designed not only for normal execution but for degraded operation, partial failure, overload, and recovery.

The emergence of cloud computing also changed the economic and architectural basis of software. Organizations no longer needed to own every physical machine they used. Computing, storage, networking, databases, and later machine learning services could be rented through programmable interfaces. Infrastructure became elastic, abstracted, and API-driven. This made it easier to build large systems, but it also created new layers of dependency.

The methodological shift was toward operational systems thinking. A mature service is not defined only by its source code. It is defined by how it behaves in production. Does it recover from failure? Can it be observed? Can it be deployed safely? Can it handle load spikes? Can engineers understand incidents? Can security patches be applied quickly? Can the cost be controlled?

This changed the meaning of reliability. Reliability was no longer a final property added after implementation. It became a continuous discipline. The system had to be measured, operated, repaired, and evolved. Incident reports, service-level objectives, capacity planning, and observability became part of the knowledge structure of modern CS practice.

The lesson of this period is that at internet scale, software becomes a living system. It is never simply “finished.” It is deployed, monitored, updated, defended, and reorganized over time.

2000s–2010s: Platforms and the Problem of Ecosystem Governance

As internet systems matured, some systems became more than applications. They became platforms. A platform is not only a tool used by end users. It is an environment in which other users, developers, businesses, advertisers, creators, institutions, and services act. This changed the central problem again: how can a computational system organize and govern an ecosystem?

Platforms include operating system ecosystems, app stores, social networks, search platforms, cloud platforms, payment systems, development platforms, and content platforms. Their technical architecture determines what other actors can do. APIs define access. Permission systems define authority. Ranking systems define visibility. Moderation systems define acceptable behavior. Identity systems define trust. App review systems define distribution. Logging and analytics define what can be measured.

This period made it harder to separate technical design from institutional design. A platform’s architecture is also a governance structure. A rate limit is not only a performance control; it may shape market access. A permission model is not only a security mechanism; it determines what kinds of applications can exist. A recommendation algorithm is not only an optimization system; it shapes attention and public discourse. A cloud interface is not only an engineering convenience; it changes how organizations build and operate software.

The difficulty of platforms lies in balancing openness and control. If a platform is too closed, it may not attract developers or users. If it is too open, it may enable abuse, fraud, privacy violations, spam, malware, or ecosystem instability. This made trust boundaries, policy enforcement, developer relations, security review, and abuse detection central to platform design.

The methodological shift was toward architecture as governance. In earlier software, architecture mainly organized complexity. In platforms, architecture also organizes power. The design of interfaces, permissions, policies, and defaults determines what actors can do and what harms become likely.

This is one reason modern CS increasingly intersects with law, economics, sociology, political theory, and ethics. Platforms are computational systems, but their effects are social. They mediate communication, commerce, labor, creativity, knowledge, and institutional authority. The lesson is that large software systems do not merely process information. They structure environments in which people act.

2010s: Mobile and Ubiquitous Computing and the Problem of Context

The rise of smartphones moved computation from desks into pockets, homes, streets, vehicles, and bodies. The central problem became: how can computation adapt to the user’s context while respecting constraints of battery, privacy, attention, connectivity, and physical movement?

Mobile devices were not simply smaller personal computers. They had sensors, cameras, microphones, touchscreens, GPS, accelerometers, wireless radios, biometric mechanisms, and constant network connections. They moved with users and collected contextual data. Applications could respond to location, motion, contacts, time, notifications, and personal habits.

This made mobile computing both powerful and risky. A mobile device could help with navigation, communication, payment, photography, health tracking, language learning, and work. But it could also expose location, behavior, identity, contacts, and private content. The same context-awareness that made applications useful also increased privacy sensitivity.

Mobile systems required integration across many CS areas: operating systems, networking, HCI, security, databases, distributed services, cloud synchronization, sensor processing, and machine learning. The smartphone became a client in a larger distributed system. Many mobile applications were only partly local; they depended on cloud services, identity systems, maps, search, recommendation, push notification, and remote storage.

The methodological shift was toward context-aware design. Designers had to ask not only what the software does, but where it is used, when it interrupts, what data it senses, what it can do offline, what permissions it requests, what latency is tolerable, and what risks it creates. This made user experience, privacy, and systems design tightly connected.

Mobile computing also intensified the social presence of computation. It entered attention, movement, memory, social relationships, health, commerce, and everyday decision-making. The lesson is that when computation becomes ubiquitous, context becomes part of the system. A system is no longer defined only by its code and data. It is also defined by when, where, how, and by whom it is used.

2010s: Deep Learning and the Problem of Learned Representation

A major transformation of the 2010s was the success of deep learning. The central problem became: can systems learn useful representations from data instead of relying mainly on human-designed rules and features?

Earlier AI had included symbolic reasoning, search, planning, expert systems, probabilistic models, and statistical learning. Deep learning intensified the statistical and representation-learning approach. Many tasks were difficult to solve by explicit rule writing: image recognition, speech recognition, translation, recommendation, game playing, and natural language understanding. Humans could perform these tasks, but it was difficult to describe the necessary rules precisely.

Deep learning reframed the problem. Instead of manually specifying all features, engineers trained models that could learn internal representations through optimization. This required large datasets, powerful hardware, differentiable architectures, better training methods, and software frameworks. When these conditions aligned, deep learning produced large improvements in vision, speech, language, and reinforcement learning.

This changed the role of programming. In traditional programming, the developer writes explicit behavior. In machine learning, the developer designs the data pipeline, model class, objective function, training procedure, evaluation metric, and deployment environment. The final behavior is not written line by line. It is induced from data through optimization.

This also changed debugging. A learned system may fail because of biased data, label noise, distribution shift, objective mismatch, overfitting, leakage, poor evaluation, or deployment drift. The error may not be localized in one function. It may be distributed across data, model, training process, and environment.

The methodological shift was from rule design to data-objective-evaluation design. This did not remove the need for CS foundations. It increased the need for them. Deep learning systems require algorithms, numerical computing, statistics, distributed systems, hardware acceleration, software engineering, data management, and security. The model is only one part of a larger system.

The lesson is that learning systems do not eliminate programming. They relocate programming into representation, data, objectives, optimization, and evaluation.

2010s–2020s: Data Infrastructure and the Problem of the Data Lifecycle

As machine learning and analytics became central, CS had to confront a less glamorous but fundamental problem: how can data be collected, cleaned, transformed, governed, versioned, and used reliably over time?

Models depend on data, but data is not a natural substance that simply exists. It is produced by instruments, users, institutions, platforms, sensors, logs, labels, and historical decisions. It may be incomplete, biased, duplicated, stale, noisy, private, or legally restricted. Its meaning depends on schemas, collection processes, definitions, and context.

This made data engineering a central part of modern computing. A reliable data system needs extraction, transformation, loading, validation, lineage tracking, access control, schema management, quality monitoring, privacy controls, and reproducibility. In machine learning, the data lifecycle also includes labeling, feature construction, training set construction, evaluation set design, drift detection, and model monitoring.

The main shift was from treating data as input to treating data as infrastructure. In a mature organization, data is not merely stored. It is governed. People need to know where it came from, who can use it, how it was transformed, whether it is fresh, whether definitions have changed, whether it contains sensitive information, and whether analyses can be reproduced.

This period also revealed that many AI failures are data failures. A model may perform poorly because the training data is unrepresentative. A metric may mislead because labels are flawed. A dashboard may be wrong because definitions changed. A deployed model may degrade because the world changed after training. The quality of computation increasingly depends on the integrity of the data lifecycle.

The lesson is that modern CS is not only algorithm-centered. It is also pipeline-centered. Trustworthy computation requires trustworthy data processes.

2020s: Foundation Models and the Problem of General-Purpose Learned Capability

In the 2020s, the focus shifted from task-specific models to large, general-purpose learned systems. The central problem became: how can broad models trained on massive data be adapted, controlled, evaluated, and integrated into real systems?

Foundation models changed the interface between users and computation. Earlier software usually exposed specific functions. A foundation model exposes flexible capabilities: writing, summarizing, translating, coding, classifying, explaining, generating images, answering questions, using tools, and transforming information across modalities. The same base model may support many tasks through prompting, fine-tuning, retrieval, tool use, or system integration.

This created new power and new instability. A model may produce fluent language without being truthful. It may solve one task well and fail unexpectedly on another. It may encode bias, leak memorized information, follow misleading instructions, or be manipulated by adversarial prompts. Its behavior is probabilistic and context-sensitive. It may be difficult to specify all intended and unintended uses in advance.

The major breakthrough came from the combination of transformer architectures, large-scale pretraining, large datasets, massive compute, instruction tuning, reinforcement from human feedback, retrieval augmentation, multimodal modeling, and deployment through APIs and products. But the deeper change was architectural. A model became a reusable capability layer inside larger systems.

This shifted design practice toward model-centered system design. Engineers now ask what context the model receives, what tools it can call, what data it may access, what outputs require verification, where deterministic code should be used, where human review is necessary, how failures are detected, and how risks vary by domain. A foundation-model application is not just a model. It is a system involving retrieval, prompts, policies, interfaces, logging, evaluation, permissions, and fallback behavior.

Foundation models also changed programming education and software work. AI-assisted programming can accelerate coding, but it can also conceal misunderstanding. The developer still needs to understand requirements, architecture, testing, security, performance, and maintainability. The model can produce code, but it cannot remove the need for judgment.

The lesson is that foundation models do not make CS foundations obsolete. They make them more important, because more behavior becomes indirect, learned, probabilistic, and difficult to inspect.

2020s: AI Evaluation, Safety, and the Problem of Trustworthy Learned Behavior

As AI systems became more capable and more widely deployed, the next problem became: how can learned systems be evaluated, constrained, monitored, and governed when their behavior cannot be fully specified in advance?

Traditional software often begins with a specification. One can write tests for expected behavior. AI systems complicate this because their outputs are probabilistic, open-ended, and context-sensitive. A model may pass benchmarks and still fail in deployment. It may perform well on average while failing badly in rare or high-stakes cases. It may be useful for one population and harmful for another. It may appear confident when wrong.

This made AI evaluation a central discipline. Evaluation now includes benchmarks, human review, red teaming, adversarial testing, robustness analysis, calibration, interpretability work, monitoring, misuse analysis, and post-deployment auditing. The challenge is not simply to maximize performance. It is to understand the relationship between capability and risk.

This period shifted method from performance optimization to capability-risk assessment. A powerful system is not automatically a good system. Its value depends on where it is used, who is affected, what errors cost, whether users understand its limits, whether outputs can be verified, whether misuse is likely, and whether there is accountability.

AI safety also forces CS to confront incomplete specifications. In many domains, the desired behavior is not purely technical. It involves human values, institutional norms, legal constraints, and contextual judgment. This does not mean abandoning technical rigor. It means expanding the set of constraints that technical design must respect.

The lesson is that for powerful learned systems, success means more than high capability. It means controlled, evaluated, accountable behavior under realistic conditions.

2020s: Privacy, Security, and the Problem of Computation Over Sensitive Data

As digital systems collected more data and AI systems required more data, privacy became a central problem of CS. The question became: how can useful computation happen without creating unacceptable exposure, surveillance, or inference power?

Earlier security often focused on protecting systems from unauthorized access and malicious modification. Privacy adds a different concern. Even authorized data use can be harmful if data is aggregated, retained, inferred from, or repurposed. Removing names is not enough. Location traces, search histories, social graphs, biometric signals, writing patterns, and behavioral logs can reveal sensitive information. Different datasets can be combined to produce new forms of identification and prediction.

This changed the technical meaning of privacy. Privacy is not only secrecy. It is also control over inference. A system may never reveal a raw record and still expose information through aggregate statistics, model outputs, metadata, or access patterns. Machine learning adds another layer because models can memorize, leak, or encode sensitive information from training data.

Several technical approaches became more important: differential privacy, federated learning, secure multi-party computation, homomorphic encryption, trusted execution environments, access controls, data minimization, and privacy-preserving analytics. None of these is a universal solution. Each offers a way to reduce certain kinds of exposure under certain assumptions.

The methodological shift was toward privacy by design. A mature system asks whether data is needed at all, whether less data can be collected, whether computation can happen locally, whether data can be aggregated safely, whether retention can be limited, whether users can understand the data flow, and whether sensitive inference is possible even when direct identifiers are removed.

The lesson is that privacy is a system property. It depends on architecture, data flows, incentives, interfaces, law, and institutional practice. In modern CS, protecting data means protecting people from harmful inference and unequal power.

2020s: Cyber-Physical and Edge Systems and the Problem of Computation in the World

Computation has also moved more deeply into the physical environment. The central problem became: how can systems sense, decide, and act safely under physical constraints?

This includes robotics, autonomous vehicles, drones, smart homes, industrial control, medical devices, wearables, sensor networks, and edge AI. These systems differ from ordinary software because they act in the world. A failure may not merely produce a wrong output. It may cause physical damage, injury, privacy loss, or environmental disruption.

Cyber-physical systems must handle noisy sensors, uncertain environments, real-time constraints, limited energy, intermittent connectivity, hardware failure, and human unpredictability. They combine embedded systems, operating systems, networking, control theory, signal processing, computer vision, machine learning, safety engineering, and hardware-software co-design.

Edge computing became important because not all computation can or should happen in the cloud. Some tasks require low latency, local reliability, privacy protection, or reduced bandwidth. A device may need to make decisions even when disconnected. This creates a new balance between local computation and centralized infrastructure.

The methodological shift was toward real-time and safety-aware design. Designers must ask what happens if a sensor fails, if a network connection disappears, if a model is uncertain, if an actuator behaves unexpectedly, or if a human intervenes. The system must often have safe fallback states. Timing becomes part of correctness.

The lesson is that when computation acts in the physical world, abstraction cannot ignore embodiment. Latency, energy, uncertainty, and safety become first-class constraints.

2020s and Beyond: Socio-Technical Computing and the Problem of Governance

The most recent expansion of CS concerns governance. Computational systems now shape communication, education, labor, law, finance, medicine, culture, public administration, and political life. The central question becomes: how should computational systems be designed and governed when they organize social reality?

This is not separate from technical CS. Ranking systems, recommendation systems, search engines, identity systems, moderation tools, fraud detectors, hiring algorithms, educational platforms, risk models, and AI assistants are technical systems. But their effects are social. They affect what people see, what opportunities they receive, how institutions make decisions, and how power is distributed.

This creates problems that cannot be solved only through better algorithms. One must ask who benefits, who is harmed, who can appeal, who understands the system, who audits it, who controls the data, which errors are tolerable, and which values are embedded in the design. A technically accurate system may still be unjust, illegitimate, inaccessible, or harmful in context.

The methodology of CS therefore expands again. It must include fairness evaluation, interpretability, transparency, accountability, privacy, human-in-the-loop review, legal compliance, institutional design, and public-interest analysis. This does not mean technical rigor becomes less important. It means technical rigor must operate within a wider account of social consequence.

Socio-technical computing also changes the meaning of responsibility. A system’s effect is not determined only by its code. It is shaped by deployment context, incentives, users, institutions, feedback loops, and governance structures. A recommendation algorithm may change what people produce. A moderation system may change speech norms. An AI assistant may change how people learn or work. A risk model may change access to resources.

The lesson is that modern CS is no longer only about computation inside machines. It is also about computation inside society. This is why ethics, law, policy, and institutional analysis are not external decorations. They become part of understanding what computational systems actually do.

The Long Arc: CS as Expanding Constraint Management

Across its history, CS has repeatedly expanded the set of constraints it must handle. The earliest question was formal possibility: what can be computed at all? Then came physical realization: how can computation run on machines? Then human expression: how can people describe computation? Then software complexity: how can large systems be maintained? Then resource feasibility: what can be done efficiently? Then shared infrastructure: how can resources, data, and networks be governed? Then global scale: how can systems serve billions of users? Then learning: how can systems acquire behavior from data? Now trust and governance: how can computational systems remain safe, accountable, and legitimate inside society?

Each era adds a new layer without removing the old ones. Modern AI systems still depend on algorithms, data structures, operating systems, databases, networks, distributed systems, programming languages, security, and software engineering. Cloud systems still depend on resource management, abstraction, isolation, observability, and failure recovery. Platform governance still depends on APIs, permissions, identity, ranking, and enforcement mechanisms. Socio-technical responsibility still depends on technical understanding.

The most coherent way to understand the history of CS is therefore not as a replacement of old topics by new ones, but as an accumulation of problem pressures. The field begins with representation and state transition. It then adds abstraction, composition, reduction, invariants, resource bounds, failure, uncertainty, adversaries, scale, learning, and governance.

That is also why a CS roadmap should not be organized only as a list of courses. It should show how each area arose as a response to a core problem. Algorithms respond to feasibility. Operating systems respond to shared resources. Databases respond to persistent truth. Networks respond to communication under uncertainty. Security responds to adversarial behavior. HCI responds to human usability. Distributed systems respond to partial failure. Machine learning responds to behavior too complex to specify manually. AI safety responds to powerful learned systems whose behavior must be constrained and evaluated. Socio-technical computing responds to the fact that computation now shapes institutions and public life.

The deepest continuity is this: Computer Science is the discipline of building reliable structures of computation under expanding constraints.

中文

计算机科学的历史，最好不要理解为一连串机器、语言或产品的更替。更好的理解方式是：它是一连串问题范式的变化。在每个时期，都会有一种不同的困难成为中心：最初是计算的定义，然后是计算的物理实现，接着是编程抽象、软件复杂性、资源限制、共享系统、持久数据、网络、人类可用性，以及对抗性安全。每个新时期都没有取代早期问题，而是在其上增加了一层新的约束。

最深层的运动，是从纯粹的形式可能性走向现实世界中的可靠性。早期 CS 问的是：一个问题究竟能不能被计算。后来 CS 问的是：它能不能被高效计算，能不能被清楚表达，能不能被安全实现，能不能被多个用户共享，能不能被持久存储，能不能跨网络通信，能不能抵御攻击者，能不能被普通人使用。这就是为什么不能把 CS 简化为编程。编程只是这门更大纪律的一种表达；这门学科关心的是表示、变换、抽象、资源控制、失败、不确定性和信任。

1930s–1950s：计算的形式化

CS 的第一个基础问题并不是如何建造一台计算机。它更加抽象，也更加激进：某个东西“可以被机械计算”到底是什么意思？ 在现代电子计算机出现之前，逻辑学家和数学家就已经在尝试理解推理本身能否被形式化。他们想知道，是否存在一种固定程序可以判定数学真理，计算能否在不依赖人类直觉的情况下被描述，以及每一个有意义的数学问题原则上是否都能通过符号操作来解决。

这个时期既属于计算史，也属于逻辑史。此时的核心对象还不是物理计算机，而是形式程序。像 “algorithm”“effective method”“mechanical process” 这样的词已经在使用，但它们还需要精确含义。挑战在于：把“一个人按照规则行事”的直观图像，转化成一个自身可以被研究的数学模型。

重大突破是形式计算模型的建立，尤其是图灵机和 lambda 演算。这些模型的重要性并不在于真实机器字面上长得像它们。它们重要，是因为它们让“计算”变成可以进行数学讨论的对象。图灵机展示了如何把计算表示为通过状态和转移进行的符号操作。lambda 演算则展示了如何把计算表示为函数抽象和归约。它们和其他等价模型一起，对“什么算是有效程序”给出了精确回答。

一旦计算有了形式模型，CS 就可以提出更深的问题。一个形式系统能否模拟另一个形式系统？所有合理的计算模型在能力上是否等价？哪些问题没有任何程序可以解决？不可判定问题的发现，尤其是停机问题，确立了这个领域最早的重大限制之一。有些问题不只是困难。它们不可能被任何通用机械方法解决。

这个时期的方法论风格是形式建模。先定义一个模型，规定它允许哪些操作，然后证明它能做什么、不能做什么。这仍然是理论 CS 的核心方法之一。它后来出现在自动机理论、编程语言语义、验证、密码学和复杂性理论中。它留下的持久教训是：CS 的起点不是机器，而是程序的形式结构。

1940s–1960s：从形式程序到物理机器

一旦计算被形式化，下一个问题就是如何在物理上实现它。形式程序是抽象对象；一台可工作的计算机则是由电路、内存、输入输出设备和控制机制组成的物质系统。核心问题变成：抽象计算如何体现为一台能在物理约束下可靠、有用地运行的机器？

早期计算机昂贵、脆弱、专用，而且难以编程。它们内存有限、速度有限、组件不可靠、接口笨拙。程序常常与硬件紧密绑定。计算还没有成为后来那种灵活的通用活动。它仍然在一定程度上是在为某个特定任务配置一台机器。

决定性思想是存储程序计算机。如果指令和数据都可以存储在内存中，那么同一台物理机器就可以执行许多不同程序。这带来了强大的概念转变：程序可以被视为控制计算的数据。其影响极其巨大。编译器、解释器、操作系统、虚拟机、加载器，以及后来自举的软件系统，都依赖这一思想。

这个时期也使抽象层变得必要。在最底层，是电气和物理过程。在其上，是电路、存储单元、机器指令、汇编语言，最终是高级语言。没有人能舒服地从电子一直推理到应用程序。因此，计算的发展需要分层抽象：它们隐藏底层细节，同时保留足够结构以保证正确性和性能。

这个领域的方法也随之改变。CS 不能再只是形式逻辑，也不能只是电子工程。它变成了一门位于形式抽象与物理实现之间的学科。每一个真实计算机系统都有这种双重性。它执行形式程序，但执行过程发生在有时间、内存、成本、热量、故障和物理限制的硬件之上。这个时期留下的教训是：计算机不只是一台机器。它是在物理约束之上构建起来的一套抽象栈。

1950s–1970s：从机器控制到编程抽象

随着计算机能力增强，主要瓶颈从机器制造转移到了人类表达。核心问题变成：人类如何描述复杂计算，而不被机器细节淹没？ 早期编程要求密切关注内存地址、寄存器、跳转和硬件特定操作。这使程序难写、难读，也难维护。

核心张力存在于机器效率和人类可理解性之间。机器可以执行低级指令，但人类需要更高级的结构。他们需要名称、过程、数据类型、模块和控制结构。没有这些，程序就会变成一长串操作，其意义很难恢复。

高级编程语言和编译器是主要回应。Fortran、Lisp、Algol、COBOL，以及后来的 C，并不只是简化了语法。它们改变了程序员能够思考的层次。Fortran 让数值计算更自然。Lisp 让符号计算和递归结构成为中心。Algol 影响了块结构和语言设计。COBOL 反映了商业数据处理。C 暴露出一种足够接近硬件、可以支持系统编程的强大模型，同时又足够抽象，可以编写可移植软件。

编译器成为人类表达与机器执行之间的关键桥梁。它把高级结构翻译成低级指令，同时保持意义不变。这使编程越来越成为设计抽象，而不只是向硬件发出命令。不同语言体现了不同的计算理论：数值的、符号的、过程式的、函数式的、命令式的、结构化的、面向对象的，以及后来的声明式或逻辑式的。

这个时期也表明，记法并不是表面问题。一门编程语言会塑造问题如何被表示、分解和解决。“我们应该使用什么语言？”这个问题，常常其实是在问：哪些抽象应该变得自然，哪些错误应该变得难以表达。这通向了编程语言理论、形式语义、类型系统、编译器优化和软件工程。这里的教训是：CS 的进步，常常发生在人类获得了更好的计算描述层次之时。

1960s–1970s：软件危机与纪律化的必要

随着程序变得更大，一个新问题出现了。问题不再只是如何表达计算，而是如何长期可靠地构建大型软件系统。核心问题变成：复杂程序如何由人群共同开发、理解、测试、修改和维护？

这就是所谓软件危机的时期。硬件快速进步，但软件项目经常失败。它们延期、超预算、不可靠、难以维护，并且难以适应变化中的需求。问题不只是程序员会犯错。更深层的问题是，非正式的编程实践无法随着软件复杂性而扩展。

软件之所以困难，是因为它同时是形式的、不可见的、灵活的和社会性的。它是形式的，因为机器会遵循精确指令。它是不可见的，因为它的结构无法像桥梁或机器那样被直接检查。它是灵活的，因为几乎任何结构都能被编码，包括糟糕的结构。它是社会性的，因为大型软件由团队跨越时间编写，处在不断变化的目标和制度压力之下。

几种回应随之出现。结构化编程试图约束控制流，让程序行为更容易推理。模块化和信息隐藏主张，系统应被划分为具有稳定接口并隐藏实现决策的组件。软件工程试图把软件构建变成一门系统性学科，包含需求、设计、测试、文档、维护和项目组织。形式化方法则探索程序能否被形式化规约并证明正确。

这些运动背后的更深原则是依赖控制。大型系统在依赖关系隐藏、不稳定或失控时会失败。一个模块应该暴露他人需要的内容，隐藏他人不需要的内容。一个接口应该保护一个不变量。一个设计应该让局部推理成为可能。一个测试应该在变化中保存行为。因此，软件工程变成了一门让变化可以被承受的实践艺术。

这个时期改变了正确性的含义。一个小程序如果能对预期输入产生正确输出，就可以被认为是正确的。一个大型软件系统必须做更多。它必须在变化条件下保持可理解、可测试、可修改、可移植和健壮。这个时期留下的教训是：软件的中心敌人是不受控制的复杂性。

1960s–1980s：复杂性、可行性与高效计算的边界

可计算性理论已经表明，有些问题无法被任何通用算法解决。但在那些可以被解决的问题中，另一个问题变成中心：哪些问题能够被高效解决？ 这个区分改变了整个领域。一个问题原则上可能可计算，但在实践中不可能完成，因为它需要过多时间、内存、通信或能源。

这催生了现代复杂性理论。CS 需要一种有纪律的方式来讨论资源使用。说某个程序在某台机器上看起来比另一个程序快是不够的。这个领域需要一种方法来分析：随着输入规模增长，资源需求如何增长。它也需要一种方法来比较不同问题的困难程度。

关键概念是复杂性类和归约。问题可以根据解决或验证它们所需的资源被分组。归约允许一个问题被转换成另一个问题，从而建立一张相对困难程度的地图。NP 完全性理论尤其重要，因为它表明，许多看似无关的问题共享一种共同的困难形式。如果任何一个 NP 完全问题都能被高效解决，那么一大类问题都能被高效解决。

这使归约成为 CS 中最深刻的方法之一。归约不只是复用解法的方式。它是一种转移可解性、困难性和不可能性的方式。通过归约，CS 在问题之间建立依赖图。这就是为什么复杂性理论会影响纯理论之外的许多领域：算法、优化、密码学、验证、人工智能、数据库和运筹学。

方法论上的转变，是从局部性能测量转向结构性资源推理。成熟的算法分析会追问：一个方法如何扩展，它依赖什么假设，已知下界是什么，是否必须精确求解，以及近似、随机化、启发式或问题松弛是否更合适。这个时期确立了 CS 中最重要的区分之一：可计算不等于可行。

1960s–1980s：操作系统与资源治理

随着计算机变得共享、交互和多用户，下一个问题围绕资源治理展开。一台物理机器有处理器、内存、存储和设备。许多程序和用户可能想同时使用这些资源。核心问题变成：一台机器如何在保持隔离、公平和控制的同时，安全而高效地服务多个程序？

操作系统成为核心答案。它们引入了一系列抽象，使一台物理机器看起来比真实情况更有秩序。进程给程序一个执行上下文。虚拟内存给程序一种私有地址空间的幻觉。文件系统给持久数据一种命名结构。调度器共享 CPU 时间。系统调用控制对特权操作的访问。保护边界把用户级代码和内核权限分离开来。

这些抽象不只是便利工具。它们是可执行的契约。操作系统必须在压力之下维持这些幻觉：内存不能跨进程泄漏，文件必须保持一致，调度必须防止一个程序垄断机器，故障必须被隔离。在这个意义上，操作系统是一种受控抽象的实践理论。

操作系统也使并发不可避免。多个进程和线程可能交错执行或并行执行。它们可能共享资源、相互等待、死锁、竞争，或破坏共享状态。这迫使 CS 发展同步、调度、互斥、资源分配，以及后来的内存模型等工具。它也使性能成为系统属性，而不是孤立代码的属性。

操作系统留下的教训是：计算不只是执行。它也是对稀缺且有特权资源的治理。这种思维后来塑造了虚拟化、容器、云平台、沙箱、移动操作系统和安全执行环境。一个好的系统，是能够在有限、共享且容易失败的机器之上维持有用抽象的系统。

1970s–1990s：数据库与持久真相的问题

随着组织开始依赖数字记录，另一个问题成为中心：数据如何在时间中保持可靠、可查询和一致？ 程序负责计算，但机构需要记忆。银行、医院、大学、公司和政府都需要系统来保存事实、支持查询、处理并发更新，并在故障中存活下来。

在成熟数据库系统出现之前，应用通常通过文件和自定义格式来管理持久数据。这使数据访问变得脆弱且应用特定。存储布局的变化可能迫使应用逻辑发生变化。不同程序可能以不一致方式编码相关数据。并发和崩溃恢复很难被正确管理。

关系模型是决定性突破，因为它把数据的逻辑结构和物理表示分离开来。数据可以用关系来描述，用户可以用声明式方式对其提问。他们可以指定自己想要什么，而不必手动说明如何一步步取回它。这使数据库系统在某种程度上类似编译器：它们把高级意图翻译成高效执行计划。

事务同样重要。数据库系统必须在许多用户并发操作，甚至机器崩溃时保持一致性。事务抽象允许一组操作被视为一个连贯单元。这使持久数据的操作更安全，也让数据库成为机构计算的中心。

方法论转变指向声明式抽象和一致性保证。数据库设计会问：逻辑模型是什么，哪些不变量必须成立，查询应如何优化，并发操作应如何互动，系统应如何从故障中恢复。这把理论和系统连接到一起：关系代数、索引、查询优化、日志、并发控制和恢复，都成为一个整合领域的一部分。

数据库表明，存储不等于信息管理。数据库不只是存放字节的地方。它是在变化、并发和故障之下保存结构化真相的系统。这个思想后来成为搜索引擎、分析系统、分布式存储、数据仓库和机器学习流水线的核心。

1970s–1990s：网络与机器之间通信的问题

随着计算机数量增加，下一个问题是通信。单台机器可以依赖本地控制和共享硬件。网络化系统则不能。机器可能不同，链路可能失败，消息可能延迟，数据包可能乱序到达，而且没有任何一台机器控制整个环境。核心问题变成：独立机器如何在不可靠且异构的网络中可靠通信？

网络需要一种新的推理方式。仅仅把比特从一个地方发送到另一个地方是不够的。系统需要寻址、路由、重传、拥塞控制、命名、会话结构、应用协议，以及不同物理网络之间的互操作性。通信必须在部分知识下工作。没有节点能假定自己看见了整个系统。没有消息能被假定会即时且可靠地到达。

分组交换和互联网络是决定性的。不是为每次通信保留固定电路，而是把数据分成数据包，使其穿过网络并在目的地重新组装。这让网络更灵活，也更健壮。分层架构通过把不同责任分配给不同层次，使复杂性变得可管理：物理传输、本地链路、路由、传输可靠性，以及应用语义。

互联网模型也展示了最小共享标准的力量。网络的网络能够增长，是因为异构系统在足够多的共同协议结构上达成一致，从而可以互操作。端到端原则进一步塑造了思维，它指出某些功能最好在端点实现，而不是在网络核心内部实现。

网络使失败成为常态。消息可能丢失、重复、延迟、乱序或被拦截。因此，一个协议必须定义保存哪些状态，做出哪些假设，哪些不变量必须成立，以及如何恢复。这种推理方式后来成为分布式系统、云服务、点对点系统和安全通信的核心。

持久教训是：一旦计算跨越网络，不确定性就成为系统的一部分。网络不只是连接计算机。它通过迫使系统在没有中央确定性的情况下运行，改变了计算的性质。

1980s–1990s：人机界面与可用性问题

随着计算机从实验室和专业机构进入办公室、家庭和学校，另一个问题变得不可避免：计算如何被非计算机专家使用？ 早期系统通常要求命令语言、编程知识或机构训练。这限制了计算的社会触达范围。

困难在于，人类并不天然以机器术语思考。人通过视觉感知、通过身体行动，记忆并不完美，会犯错，通过反馈学习，并依赖上下文。一个技术上正确的系统，如果把错误的抽象暴露给用户，仍然可能在实践中不可用。

图形用户界面、指点设备、直接操控、窗口、图标、菜单和视觉隐喻，改变了人与计算机的关系。它们并没有让计算变得不那么形式化。相反，它们在形式机器操作和人类行动之间创造了一个表示层。用户可以操控可见对象，获得反馈，从错误中恢复，并形成对系统的心智模型。

这个时期扩展了 CS 的方法论。有些问题不能只靠证明、性能分析或形式规约来解决。它们需要观察用户、测试界面、研究认知、设计交互并评估无障碍。因此，人机交互把经验方法和设计导向方法带入 CS。

更深的教训是：界面不是装饰。它是计算系统意义的一部分。它决定哪些行动可见，哪些状态可理解，哪些错误可恢复，以及哪些用户能够参与。随着计算被更广泛使用，可用性成为技术成功的核心条件。

1980s–1990s：安全与对抗性计算的问题

随着计算机联网、共享，并在机构中变得重要，意外故障不再是唯一问题。有些行动者会故意误用系统。核心问题变成：计算如何在对抗性条件下保持可信？

安全引入了不同的故障模型。普通 bug 可能是偶然的。安全漏洞则会被主动寻找和利用。攻击者寻找抽象之间的缝隙：规范与实现之间、协议与部署之间、用户意图与界面行为之间、访问控制策略与实际执行之间。

密码学提供了保密性、完整性、认证、签名和密钥交换工具。访问控制规定谁可以做什么。安全操作系统设计强调隔离、权限分离和可信计算基。随着通信穿过不可信环境，网络安全变得必要。形式化协议分析表明，即使密码学原语本身很强，如果周围假设错误，它们也可能被组合成脆弱系统。

方法论转变是威胁建模。安全不只是问系统在预期使用下是否工作，还会问对手是谁、他们能观察什么、能修改什么、拥有哪些资源、信任边界在哪里，以及系统依赖哪些假设。安全还迫使设计者追问部分失陷之后会发生什么，因为完美预防很少现实。

这改变了正确性的含义。一个系统对诚实用户表现正确，仍然可能不安全。一个数学上优雅的协议，可能因为实现 bug、糟糕随机性、侧信道、糟糕密钥管理或混乱的用户流程而失败。教训是，安全是系统属性，而不仅是算法属性。一个系统如果不能抵御智能误用，就不能算健壮。

1980s–1990s：面向对象设计、复用与大型软件组织

随着软件系统变得更大、更具交互性，长期演化问题变得更加明显。核心问题变成：软件应如何组织，才能在扩展、复用和维护时不被自身依赖压垮？

结构化编程已经帮助控制了局部控制流，但大型系统需要更强的模型来组织行为和状态。软件不只是需要运行；它还需要变化。需求会变化，团队会变化，平台会变化，用户会发现新需求。一个曾经有效但抵抗修改的设计，会变成负担。

面向对象编程之所以有影响力，是因为它提供了一种围绕结合状态、行为和接口的单元来组织软件的方式。类、对象、封装、继承和多态，给程序员提供了建模领域和组织大型应用的工具。更深层的重要性并不在于每个系统都应该面向对象，而在于软件设计越来越关注封装、可替换性、稳定接口、局部责任，以及通过抽象实现复用。

这个时期也加强了人们对设计模式、框架、架构和基于组件组织方式的兴趣。程序员越来越需要推理：哪些概念应该成为模块，哪些责任应该放在一起，哪些依赖是可接受的，哪些接口需要长期稳定。

方法论转变是走向架构推理。在小程序中，人们常常可以直接思考执行。在大程序中，人们还必须思考演化。架构必须保留未来变化的可能，同时防止复杂性无限增长。这个洞见后来影响了面向服务架构、微服务、包生态、API 设计和平台工程。

持久教训是：在大型软件中，变化的结构和执行的结构一样重要。一个系统设计良好，并不只是因为它现在能工作。只有当它在增长、适应，并被后来者理解时仍能继续工作，它才算设计良好。

走向 Web：从联网机器到全球信息空间

到 1990 年代末，CS 的早期层次已经开始汇合。形式计算提供了模型和边界。体系结构和操作系统让机器能够作为受控资源环境使用。编程语言和软件工程给了人类表达和组织复杂性的方式。复杂性理论澄清了可行性。数据库让持久信息可以被管理。网络在不确定性下连接了机器。安全引入了对抗性推理。HCI 让人类可用性成为核心设计问题。

这些发展为一种新的问题范式奠定了基础。一旦机器被联网、变得可用、可编程，并嵌入机构之中，计算就可以成为一种全球信息媒介。下一个主要问题不再只是单台机器如何计算、一个程序如何编写，或两台机器如何通信。问题变成：数十亿文档、用户、服务、平台，以及最终模型，如何在一个共享计算环境中共存。

这一转变通向 Web、搜索、互联网规模系统、云计算、数据基础设施、深度学习、基础模型和社会技术治理。

Web 的兴起改变了计算机科学的重心。早期时期已经建立了基础：计算被形式化，机器被构造出来，编程抽象成熟，操作系统治理共享资源，数据库保存持久状态，网络连接机器，软件工程直面长期复杂性。Web 把这些早期成就组合进一个新环境：一个全球性的、开放的、面向用户的信息系统。

核心问题不再只是如何计算、存储或通信。它变成：信息如何在全球规模上被命名、链接、发现、信任、更新和使用？ 这把 CS 从研究孤立系统，转向研究大规模计算生态系统。网页、浏览器、服务器、搜索引擎、数据库、网络协议和用户界面不再是彼此分离的问题。它们成为一个不断扩展的信息环境的组成部分。

1990s–2000s：Web 与全球信息访问问题

Web 的早期重要性来自一组简单而强大的抽象。一个资源可以由 URL 命名。客户端可以通过 HTTP 获取它。文档可以通过 HTML 被结构化和链接。浏览器可以作为浏览这个空间的通用界面。这些抽象与许多早期系统相比技术上很简单，但它们的社会后果和架构后果极其巨大。

Web 解决的是一个既技术又组织的问题。在它之前，网络化信息已经存在，但分散在不同协议、机构、格式和访问系统中。Web 让发布和访问变得容易得多。任何人都可以创建一个文档，把它链接到其他文档，并使其对他人可用。系统不需要一个中央权威来批准每个新页面或新连接。这种开放性让 Web 快速增长。

关键问题变成全球信息访问。机器之间通信还不够。信息需要名称、地址、格式、链接和界面。用户需要一种方式穿过分布式信息空间，而不必知道每个服务器的物理位置或内部结构。浏览器成为通用客户端，超链接成为公共知识架构的基本单位。

这个时期也改变了软件的含义。软件不再只是安装在本地机器上的东西。它越来越多地成为通过网络访问的东西。一个网站可以从文档开始，但它可以变成应用。浏览器可以从查看器开始，但它可以变成运行时。服务器可以从文件提供者开始，但它可以变成分布式服务的一部分。这是从本地程序到网络化应用，再到云服务的漫长转变的开端。

Web 表明，当基本抽象简单、稳定且可组合时，一个计算系统可以在社会层面扩展。它也表明，开放性会创造新问题。一旦任何人都可以发布，系统就必须处理噪声、重复、错误信息、垃圾信息、滥用、断链、安全风险和可发现性。因此，Web 为下一个主要问题准备了地面：在一个巨大且快速变化的信息空间中找到有用信息。

1990s 后期–2010s：搜索与大规模相关性问题

随着 Web 增长，中心问题从访问转向发现。发布信息已经不够。用户需要在数十亿文档中找到相关信息。问题变成：一个系统如何判断什么对某个查询有用、权威、新鲜且相关？

这不是简单的数据库查找问题。数据库查询通常假设结构化数据和清晰语义。Web 搜索必须处理混乱、异构、不断变化的文档。一个页面可能包含正确词语，却仍然无用。另一个页面可能并不精确匹配查询，却更能满足用户意图。查询通常很短、含糊，并且依赖上下文。Web 中还存在操纵、重复、垃圾信息和过时材料。

因此，搜索变成一个整合性的 CS 问题。它需要爬取 Web、建立索引、排序文档、理解查询、对抗操纵、以低延迟提供结果，并评估用户是否满意。倒排索引是检索的核心，但排序需要的不只是词项匹配。链接结构、文本相关性、新鲜度、用户行为、权威信号，以及后来的机器学习，都成为搜索的一部分。

这个时期标志着方法论转向数据驱动评估。搜索引擎不能只用形式正确性来判断，因为往往没有唯一正确结果。它必须根据相关性、有用性和用户行为来判断。这使离线指标、人工评估、点击日志和在线实验变得重要。系统的改进不仅来自理论分析，也来自持续测量。

搜索改变了 CS，因为它使排序成为一种核心计算操作。早期系统通常从结构化数据中返回精确答案。搜索系统返回的是相关性的有序近似。这预示了许多后来的系统：推荐引擎、社交媒体信息流、广告平台、内容审核系统和 AI 助手。在所有这些系统中，系统并不只是取回一个已知对象。它估计应该展示、推荐、隐藏或生成什么。

更深的教训是：在大规模信息环境中，计算常常变成对不完美信号的推断。精确正确性在基础设施中仍然重要，但面向用户的结果可能是概率性的、排序的、上下文敏感的。这进一步把 CS 推向统计、机器学习、实验和以人为中心的评估。

2000s–2010s：互联网规模系统与持续运行问题

一旦 Web 服务吸引了数百万乃至数十亿用户，另一个问题成为主导：系统如何在巨大规模和持续变化下保持快速、可靠、安全和可维护？

这不同于构建一个能正确运行一次的程序。互联网规模服务总是在运行。它接收不可预测的流量，存储不断变化的数据，依赖其他服务，运行在许多机器之上，经历频繁部署，并面临持续安全威胁。它不能假设硬件可靠，也不能假设网络稳定。在足够大的规模上，失败不是例外。它是常态。

这个时期使分布式系统和运维工程成为日常软件实践的核心。大型服务需要复制、分片、负载均衡、分布式存储、缓存、异步处理、队列、监控、日志、追踪、部署自动化、回滚策略和事故响应。系统设计不仅要面向正常执行，也要面向降级运行、局部失败、过载和恢复。

云计算的出现也改变了软件的经济基础和架构基础。组织不再需要拥有自己使用的每一台物理机器。计算、存储、网络、数据库，以及后来的机器学习服务，都可以通过可编程接口租用。基础设施变得弹性化、抽象化，并由 API 驱动。这让构建大型系统更容易，但也创造了新的依赖层。

方法论转向运维系统思维。一个成熟服务不只由源代码定义。它由自己在生产环境中的行为定义。它能否从失败中恢复？它能否被观测？它能否安全部署？它能否处理负载峰值？工程师能否理解事故？安全补丁能否快速应用？成本能否被控制？

这改变了可靠性的含义。可靠性不再是实现完成后附加的最终属性。它变成一门持续纪律。系统必须被测量、运行、修复和演化。事故报告、服务级目标、容量规划和可观测性，成为现代 CS 实践知识结构的一部分。

这个时期的教训是：在互联网规模上，软件变成一个活系统。它从来不只是“完成”了。它会被部署、监控、更新、防御，并随时间重组。

2000s–2010s：平台与生态治理问题

随着互联网系统成熟，有些系统不再只是应用。它们变成了平台。平台不只是终端用户使用的工具。它是一个环境，其他用户、开发者、企业、广告商、创作者、机构和服务都在其中行动。这再次改变了中心问题：一个计算系统如何组织和治理一个生态？

平台包括操作系统生态、应用商店、社交网络、搜索平台、云平台、支付系统、开发平台和内容平台。它们的技术架构决定其他行动者能做什么。API 定义访问。权限系统定义权威。排序系统定义可见性。审核系统定义可接受行为。身份系统定义信任。应用审查系统定义分发。日志和分析定义什么可以被测量。

这个时期让技术设计和制度设计更难分开。平台的架构同时也是治理结构。速率限制不只是性能控制；它可能塑造市场进入。权限模型不只是安全机制；它决定哪些应用能够存在。推荐算法不只是优化系统；它塑造注意力和公共讨论。云接口不只是工程便利；它改变组织构建和运行软件的方式。

平台的困难在于平衡开放和控制。如果一个平台过于封闭，它可能无法吸引开发者或用户。如果它过于开放，它可能助长滥用、欺诈、隐私侵犯、垃圾信息、恶意软件或生态不稳定。这使信任边界、策略执行、开发者关系、安全审查和滥用检测成为平台设计的核心。

方法论转向作为治理的架构。在早期软件中，架构主要用于组织复杂性。在平台中，架构还组织权力。接口、权限、策略和默认设置的设计，决定行动者能做什么，以及哪些伤害更可能发生。

这也是现代 CS 越来越与法律、经济学、社会学、政治理论和伦理学交叉的原因之一。平台是计算系统，但它们的影响是社会性的。它们调解通信、商业、劳动、创造、知识和机构权威。教训是，大型软件系统不只是处理信息。它们结构化了人们行动的环境。

2010s：移动与泛在计算，以及语境问题

智能手机的兴起把计算从桌面带入口袋、家庭、街道、车辆和身体。核心问题变成：计算如何适应用户语境，同时尊重电池、隐私、注意力、连接性和身体移动这些约束？

移动设备并不只是更小的个人计算机。它们拥有传感器、摄像头、麦克风、触摸屏、GPS、加速度计、无线电、生物识别机制和持续网络连接。它们随用户移动，并收集语境数据。应用可以响应位置、运动、联系人、时间、通知和个人习惯。

这使移动计算既强大又危险。移动设备可以帮助导航、通信、支付、摄影、健康追踪、语言学习和工作。但它也可能暴露位置、行为、身份、联系人和私人内容。让应用有用的同一种语境感知能力，也提高了隐私敏感性。

移动系统需要整合许多 CS 领域：操作系统、网络、HCI、安全、数据库、分布式服务、云同步、传感器处理和机器学习。智能手机成为一个更大分布式系统中的客户端。许多移动应用只是一部分在本地运行；它们依赖云服务、身份系统、地图、搜索、推荐、推送通知和远程存储。

方法论转向语境感知设计。设计者不仅要问软件做什么，还要问它在哪里被使用，什么时候打断用户，感知什么数据，离线时能做什么，请求什么权限，什么延迟可以接受，以及它制造什么风险。这使用户体验、隐私和系统设计紧密连接。

移动计算也强化了计算的社会存在。它进入注意力、移动、记忆、社会关系、健康、商业和日常决策。教训是：当计算变得无处不在，语境就成为系统的一部分。一个系统不再只由代码和数据定义。它也由何时、何地、如何，以及被谁使用来定义。

2010s：深度学习与学习表征问题

2010 年代的一项重大转变，是深度学习的成功。核心问题变成：系统能否从数据中学习有用表示，而不是主要依赖人类设计的规则和特征？

早期 AI 已经包括符号推理、搜索、规划、专家系统、概率模型和统计学习。深度学习强化了统计和表征学习路径。许多任务很难通过显式规则编写来解决：图像识别、语音识别、翻译、推荐、游戏和自然语言理解。人类能完成这些任务，但很难精确描述必要规则。

深度学习重新框定了问题。工程师不再手动指定所有特征，而是训练模型，让模型通过优化学习内部表征。这需要大数据集、强大硬件、可微架构、更好的训练方法和软件框架。当这些条件对齐时，深度学习在视觉、语音、语言和强化学习中带来了巨大改进。

这改变了编程的角色。在传统编程中，开发者编写显式行为。在机器学习中，开发者设计数据流水线、模型类别、目标函数、训练过程、评估指标和部署环境。最终行为不是一行一行写出来的。它是通过优化从数据中诱导出来的。

这也改变了调试。一个学习系统可能因为有偏数据、标签噪声、分布偏移、目标不匹配、过拟合、泄漏、糟糕评估或部署漂移而失败。错误可能并不局限在某个函数中。它可能分布在数据、模型、训练过程和环境之间。

方法论转变，是从规则设计走向数据—目标—评估设计。这并没有消除 CS 基础的必要。它提高了对这些基础的需求。深度学习系统需要算法、数值计算、统计、分布式系统、硬件加速、软件工程、数据管理和安全。模型只是更大系统的一部分。

教训是：学习系统并没有消灭编程。它把编程重新安置到表示、数据、目标、优化和评估之中。

2010s–2020s：数据基础设施与数据生命周期问题

随着机器学习和分析变成核心，CS 不得不面对一个不那么光鲜但极其基础的问题：数据如何被收集、清洗、转换、治理、版本化，并在时间中可靠使用？

模型依赖数据，但数据不是一种天然存在的物质。它由仪器、用户、机构、平台、传感器、日志、标签和历史决策生产出来。它可能不完整、有偏、重复、过时、嘈杂、私密，或受到法律限制。它的意义依赖 schema、收集过程、定义和上下文。

这使数据工程成为现代计算的核心部分。一个可靠的数据系统需要抽取、转换、加载、验证、血缘追踪、访问控制、schema 管理、质量监控、隐私控制和可复现性。在机器学习中，数据生命周期还包括标注、特征构造、训练集构造、评估集设计、漂移检测和模型监控。

主要转变是从把数据视为输入，转向把数据视为基础设施。在成熟组织中，数据不只是被存储。它被治理。人们需要知道它来自哪里，谁能使用，如何被转换，是否新鲜，定义是否变化，是否包含敏感信息，以及分析是否可以复现。

这个时期还揭示，许多 AI 失败本质上是数据失败。模型表现差，可能是因为训练数据不具代表性。指标误导，可能是因为标签有缺陷。仪表盘错误，可能是因为定义变化。部署后的模型退化，可能是因为训练之后世界发生了变化。计算质量越来越取决于数据生命周期的完整性。

教训是，现代 CS 不只是以算法为中心。它也以流水线为中心。可信计算需要可信的数据过程。

2020s：基础模型与通用学习能力问题

进入 2020 年代，关注点从任务特定模型转向大型通用学习系统。核心问题变成：在海量数据上训练出的广泛模型，如何被适配、控制、评估，并整合进真实系统？

基础模型改变了用户与计算之间的接口。早期软件通常暴露具体功能。基础模型暴露的是灵活能力：写作、总结、翻译、编码、分类、解释、生成图像、回答问题、使用工具，以及跨模态转换信息。同一个基础模型可以通过提示、微调、检索、工具使用或系统集成来支持许多任务。

这创造了新的力量，也创造了新的不稳定性。模型可能生成流畅语言，却并不真实。它可能很好地解决一个任务，却在另一个任务上意外失败。它可能编码偏见、泄漏记忆信息、遵循误导性指令，或被对抗性提示操纵。它的行为是概率性的、上下文敏感的。提前指定所有预期和非预期用途可能非常困难。

主要突破来自 Transformer 架构、大规模预训练、大数据集、巨大计算量、指令微调、基于人类反馈的强化学习、检索增强、多模态建模，以及通过 API 和产品部署的结合。但更深的变化是架构性的。模型成为大型系统中的可复用能力层。

这使设计实践转向以模型为中心的系统设计。工程师现在要问：模型接收什么上下文，可以调用什么工具，可以访问什么数据，哪些输出需要验证，哪里应该使用确定性代码，哪里需要人类审查，失败如何被检测，以及风险如何随领域变化。基础模型应用不只是一个模型。它是一个由检索、提示、策略、界面、日志、评估、权限和 fallback 行为组成的系统。

基础模型也改变了编程教育和软件工作。AI 辅助编程可以加速编码，但也可能掩盖误解。开发者仍然需要理解需求、架构、测试、安全、性能和可维护性。模型可以生成代码，但它无法取消判断的必要。

教训是，基础模型并不会让 CS 基础过时。它们让这些基础更重要，因为更多行为变得间接、学习得来、概率化，并且难以检查。

2020s：AI 评估、安全与可信学习行为问题

随着 AI 系统变得更强、更广泛部署，下一个问题变成：当学习系统的行为无法被提前完全规定时，如何对其评估、约束、监控和治理？

传统软件通常从规约开始。人们可以为预期行为编写测试。AI 系统使这件事复杂化，因为它们的输出是概率性的、开放式的、上下文敏感的。一个模型可能通过基准，却仍然在部署中失败。它可能平均表现很好，却在罕见或高风险案例中严重失败。它可能对一个群体有用，却对另一个群体有害。它可能在错误时显得很自信。

这使 AI 评估成为一门核心纪律。现在的评估包括基准、人类审查、红队测试、对抗性测试、鲁棒性分析、校准、可解释性工作、监控、误用分析和部署后审计。挑战不只是最大化性能，而是理解能力与风险之间的关系。

这个时期的方法从性能优化转向能力—风险评估。一个强大的系统并不自动是一个好系统。它的价值取决于它在哪里使用、谁受影响、错误代价是什么、用户是否理解其边界、输出是否可验证、误用是否可能，以及是否存在问责机制。

AI 安全也迫使 CS 面对不完整规格。在许多领域，期望行为并不是纯技术问题。它涉及人类价值、制度规范、法律约束和语境判断。这并不意味着放弃技术严谨性。它意味着扩大技术设计必须尊重的约束集合。

教训是：对于强大的学习系统，成功不只是高能力。成功意味着在现实条件下具备受控、被评估、可问责的行为。

2020s：隐私、安全与敏感数据上的计算问题

随着数字系统收集更多数据，AI 系统也需要更多数据，隐私成为 CS 的中心问题。问题变成：如何在不制造不可接受的暴露、监视或推断能力的情况下进行有用计算？

早期安全通常关注保护系统免受未授权访问和恶意修改。隐私增加了另一种关注。即使是被授权的数据使用，也可能因为数据被聚合、保留、推断或重新利用而造成伤害。去掉姓名是不够的。位置轨迹、搜索历史、社交图谱、生物识别信号、写作模式和行为日志，都可能揭示敏感信息。不同数据集可以被结合起来，产生新的识别和预测形式。

这改变了隐私的技术含义。隐私不只是保密。它也是对推断的控制。一个系统可能从不泄露原始记录，但仍然通过聚合统计、模型输出、元数据或访问模式暴露信息。机器学习增加了另一层问题，因为模型可能记忆、泄漏或编码训练数据中的敏感信息。

几种技术路径变得更重要：差分隐私、联邦学习、安全多方计算、同态加密、可信执行环境、访问控制、数据最小化和隐私保护分析。没有一种是通用解决方案。每一种都在特定假设下减少某些类型的暴露。

方法论转向隐私设计优先。成熟系统会问：是否真的需要数据，能否收集更少数据，计算能否在本地发生，数据能否被安全聚合，保留时间能否限制，用户能否理解数据流，以及即使直接标识符被移除，是否仍可能发生敏感推断。

教训是，隐私是系统属性。它取决于架构、数据流、激励、界面、法律和机构实践。在现代 CS 中，保护数据意味着保护人免受有害推断和不平等权力的伤害。

2020s：信息物理系统、边缘系统与现实世界中的计算问题

计算也更深地进入了物理环境。核心问题变成：系统如何在物理约束下感知、决策并安全行动？

这包括机器人、自动驾驶汽车、无人机、智能家居、工业控制、医疗设备、可穿戴设备、传感器网络和边缘 AI。这些系统不同于普通软件，因为它们会在世界中行动。一次失败可能不只是产生错误输出。它可能造成物理损害、伤害、隐私损失或环境扰动。

信息物理系统必须处理嘈杂传感器、不确定环境、实时约束、有限能量、间歇连接、硬件故障和人类不可预测性。它们结合了嵌入式系统、操作系统、网络、控制理论、信号处理、计算机视觉、机器学习、安全工程，以及软硬件协同设计。

边缘计算变得重要，是因为并不是所有计算都能或应该发生在云端。有些任务需要低延迟、本地可靠性、隐私保护或减少带宽。设备可能需要在断网时仍能决策。这在本地计算和集中式基础设施之间创造了新的平衡。

方法论转向实时与安全感知设计。设计者必须追问：如果传感器失败，如果网络连接消失，如果模型不确定，如果执行器行为异常，或者如果人类介入，会发生什么。系统通常必须具备安全 fallback 状态。时间性成为正确性的一部分。

教训是：当计算在物理世界中行动时，抽象不能忽视具身性。延迟、能量、不确定性和安全都变成一等约束。

2020s 及以后：社会技术计算与治理问题

CS 最近的扩展关乎治理。计算系统现在塑造通信、教育、劳动、法律、金融、医疗、文化、公共行政和政治生活。核心问题变成：当计算系统组织社会现实时，它们应如何被设计和治理？

这并不与技术 CS 分离。排序系统、推荐系统、搜索引擎、身份系统、审核工具、欺诈检测器、招聘算法、教育平台、风险模型和 AI 助手，都是技术系统。但它们的效果是社会性的。它们影响人们看见什么、获得什么机会、机构如何做出决策，以及权力如何分配。

这创造了无法只靠更好算法解决的问题。人们必须追问谁受益、谁受害、谁可以申诉、谁理解系统、谁审计系统、谁控制数据、哪些错误可以容忍，以及哪些价值被嵌入设计之中。一个技术上准确的系统，在具体语境中仍然可能是不公正的、不合法的、不可访问的或有害的。

因此，CS 的方法论再次扩展。它必须包括公平性评估、可解释性、透明度、问责、隐私、人类参与审查、法律合规、制度设计和公共利益分析。这并不意味着技术严谨性变得不重要。它意味着技术严谨性必须在更宽的社会后果说明中运作。

社会技术计算也改变了责任的含义。一个系统的影响并不只由代码决定。它由部署语境、激励、用户、机构、反馈回路和治理结构共同塑造。推荐算法可能改变人们生产什么。审核系统可能改变言论规范。AI 助手可能改变人们如何学习或工作。风险模型可能改变对资源的访问。

教训是，现代 CS 不再只关心机器内部的计算。它也关心社会内部的计算。这就是为什么伦理、法律、政策和制度分析并不是外部装饰。它们成为理解计算系统实际做什么的一部分。

长弧线：CS 作为不断扩展的约束管理

纵观历史，CS 一再扩展自己必须处理的约束集合。最早的问题是形式可能性：究竟什么可以被计算？随后是物理实现：计算如何在机器上运行？然后是人类表达：人如何描述计算？接着是软件复杂性：大型系统如何维护？再然后是资源可行性：什么可以被高效完成？然后是共享基础设施：资源、数据和网络如何被治理？然后是全球规模：系统如何服务数十亿用户？然后是学习：系统如何从数据中获得行为？现在则是信任与治理：计算系统如何在社会内部保持安全、可问责和正当？

每个时代都会增加新层次，而不会移除旧层次。现代 AI 系统仍然依赖算法、数据结构、操作系统、数据库、网络、分布式系统、编程语言、安全和软件工程。云系统仍然依赖资源管理、抽象、隔离、可观测性和故障恢复。平台治理仍然依赖 API、权限、身份、排序和执行机制。社会技术责任仍然依赖技术理解。

因此，理解 CS 历史最连贯的方式，不是把它看作新主题替代旧主题，而是看作问题压力的积累。这个领域从表示和状态转移开始。随后它增加了抽象、组合、归约、不变量、资源边界、故障、不确定性、对手、规模、学习和治理。

这也是为什么一份 CS 路线图不应该只被组织成课程清单。它应该展示每个领域如何作为对某个核心问题的回应而出现。算法回应可行性。操作系统回应共享资源。数据库回应持久真相。网络回应不确定性下的通信。安全回应对抗性行为。HCI 回应人类可用性。分布式系统回应局部失败。机器学习回应过于复杂、难以手写规定的行为。AI 安全回应必须被约束和评估的强大学习系统。社会技术计算回应计算现在正在塑造机构和公共生活这一事实。

最深的连续性是：计算机科学是在不断扩展的约束下，构建可靠计算结构的学科。